Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
(From here) At a high level, GitHub는 개발자가 코드를 저장하고 관리하며 코드 변경 사항을 추적하고 제어하는 데 도움을 주는 웹사이트이자 클라우드 기반 서비스입니다.
Github 저장소는 공개, 비공개 및 내부로 구성할 수 있습니다.
비공개는 조직의 사람들만 접근할 수 있음을 의미합니다.
내부는 기업의 사람들만 접근할 수 있음을 의미합니다(기업은 여러 조직을 가질 수 있습니다).
공개는 모든 인터넷 사용자가 접근할 수 있음을 의미합니다.
대상으로 삼고자 하는 사용자, 저장소 또는 조직을 알고 있다면 github dorks를 사용하여 민감한 정보를 찾거나 각 저장소에서 민감한 정보 유출을 검색할 수 있습니다.
Github는 사용자, 저장소 또는 조직을 범위로 지정하여 무언가를 검색할 수 있도록 허용합니다. 따라서 민감한 정보 근처에 나타날 문자열 목록을 사용하여 대상에서 잠재적인 민감한 정보를 쉽게 검색할 수 있습니다.
도구(각 도구는 자신의 dorks 목록을 포함합니다):
github dorks는 github 검색 옵션을 사용하여 유출을 검색하는 데에도 사용됩니다. 이 섹션은 각 저장소를 다운로드하고 그 안에서 민감한 정보를 검색하는 도구에 전념하고 있습니다(특정 깊이의 커밋을 확인하는 것 포함).
도구(각 도구는 자신의 regex 목록을 포함합니다):
저장소에서 유출을 찾고 git log -p와 같은 명령을 실행할 때 비밀이 포함된 다른 커밋이 있는 다른 브랜치가 있을 수 있음을 잊지 마세요!
풀 요청을 악용하여 저장소를 손상시킬 수 있습니다. 저장소가 취약한지 확인하려면 주로 Github Actions yaml 구성을 읽어야 합니다. 아래에서 더 많은 정보.
삭제되었거나 내부에 있더라도 github 저장소의 포크에서 민감한 데이터를 얻는 것이 가능할 수 있습니다. 여기에서 확인하세요:
Accessible Deleted Data in Github조직의 구성원에게 할당할 수 있는 기본 권한이 있습니다. 이는 https://github.com/organizations/<org_name>/settings/member_privileges 페이지 또는 Organizations API에서 제어할 수 있습니다.
기본 권한: 구성원은 조직 저장소에 대해 None/Read/write/Admin 권한을 가집니다. 권장되는 것은 None 또는 Read입니다.
저장소 포크: 필요하지 않다면 구성원이 조직 저장소를 포크하는 것을 허용하지 않는 것이 좋습니다.
페이지 생성: 필요하지 않다면 구성원이 조직 저장소에서 페이지를 게시하는 것을 허용하지 않는 것이 좋습니다. 필요하다면 공개 또는 비공개 페이지 생성을 허용할 수 있습니다.
통합 접근 요청: 이 기능이 활성화되면 외부 협력자가 이 조직 및 그 자원에 접근하기 위해 GitHub 또는 OAuth 앱에 대한 접근을 요청할 수 있습니다. 일반적으로 필요하지만 필요하지 않다면 비활성화하는 것이 좋습니다.
이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요.
저장소 가시성 변경: 활성화되면 저장소에 대한 관리자 권한을 가진 구성원이 가시성을 변경할 수 있습니다. 비활성화되면 조직 소유자만 저장소 가시성을 변경할 수 있습니다. 사람들이 공개로 만들지 않기를 원한다면 이 기능이 비활성화되어 있는지 확인하세요.
이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요.
저장소 삭제 및 전송: 활성화되면 저장소에 대한 관리자 권한을 가진 구성원이 공개 및 비공식 저장소를 삭제하거나 전송할 수 있습니다.
이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요.
구성원이 팀을 생성할 수 있도록 허용: 활성화되면 조직의 구성원이 새로운 팀을 생성할 수 있습니다. 비활성화되면 조직 소유자만 새로운 팀을 생성할 수 있습니다. 이 기능은 비활성화하는 것이 좋습니다.
이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요.
이 페이지에서 더 많은 것을 구성할 수 있지만 이전 항목들이 보안과 관련된 것입니다.
여러 보안 관련 설정을 https://github.com/organizations/<org_name>/settings/actions 페이지에서 구성할 수 있습니다.
모든 구성은 각 저장소에서 독립적으로 설정할 수 있습니다.
Github actions 정책: 어떤 저장소가 워크플로를 실행할 수 있는지, 어떤 워크플로가 허용되어야 하는지를 지정할 수 있습니다. 허용해야 할 저장소를 지정하는 것이 좋습니다.
외부 협력자의 포크 풀 요청 워크플로: 모든 외부 협력자에 대해 승인을 요구하는 것이 좋습니다.
이 정보가 포함된 API를 찾을 수 없었습니다. 아는 분은 공유해 주세요.
포크 풀 요청에서 워크플로 실행: 풀 요청에서 워크플로를 실행하는 것은 강력히 권장되지 않습니다. 포크 원본의 유지 관리자가 소스 저장소에서 읽기 권한이 있는 토큰을 사용할 수 있는 능력을 부여받기 때문입니다.
이 정보가 포함된 API를 찾을 수 없었습니다. 아는 분은 공유해 주세요.
워크플로 권한: 읽기 저장소 권한만 부여하는 것이 강력히 권장됩니다. GITHUB_TOKEN이 실행 중인 워크플로에 남용되지 않도록 쓰기 및 풀 요청 생성/승인 권한을 부여하는 것은 권장되지 않습니다.
이 정보에 접근할 수 있는 API 엔드포인트를 아는 분은 알려주세요!
타사 애플리케이션 접근 정책: 모든 애플리케이션에 대한 접근을 제한하고 필요한 애플리케이션만 허용하는 것이 좋습니다(검토 후).
설치된 GitHub Apps: 필요한 애플리케이션만 허용하는 것이 좋습니다(검토 후).
이 시나리오에서는 github 계정에 대한 접근을 얻었다고 가정하겠습니다.
조직 내 사용자에 대한 자격 증명이 있는 경우 로그인하여 기업 및 조직 역할을 확인할 수 있습니다. 일반 구성원인 경우 일반 구성원이 가진 권한, 그룹, 어떤 저장소에 대한 권한, 저장소 보호 방법을 확인하세요.
2FA가 사용될 수 있으므로 이 정보를 얻으려면 그 검사를 통과해야 합니다.
user_session 쿠키를 훔치는데 성공하면(현재 SameSite: Lax로 구성됨) 자격 증명이나 2FA 없이 사용자를 완전히 가장할 수 있습니다.
유용할 경우 브랜치 보호 우회 섹션을 확인하세요.
Github는 사용자가 코드를 배포하기 위한 인증 방법으로 사용할 SSH 키를 설정할 수 있도록 허용합니다(2FA가 적용되지 않음).
이 키를 사용하여 사용자가 일부 권한을 가진 저장소에서 변경을 수행할 수 있지만, github api에 접근하여 환경을 열거하는 데 사용할 수는 없습니다. 그러나 로컬 설정을 열거하여 접근할 수 있는 저장소 및 사용자에 대한 정보를 얻을 수 있습니다:
사용자가 자신의 github 사용자 이름으로 사용자 이름을 구성한 경우, _https://github.com/<github_username>.keys_에서 그의 계정에 설정한 공개 키에 접근할 수 있습니다. 이를 확인하여 발견한 개인 키를 사용할 수 있는지 확인할 수 있습니다.
SSH 키는 배포 키로 리포지토리에 설정될 수도 있습니다. 이 키에 접근할 수 있는 사람은 리포지토리에서 프로젝트를 시작할 수 있습니다. 일반적으로 서로 다른 배포 키가 있는 서버에서는 로컬 파일 **~/.ssh/config**가 관련된 키에 대한 정보를 제공합니다.
여기에서 설명한 바와 같이, 때때로 커밋에 서명해야 하거나 발견될 수 있습니다.
현재 사용자가 어떤 키를 가지고 있는지 로컬에서 확인하세요:
사용자 토큰에 대한 기본 정보를 참조하여 소개를 확인하세요.
사용자 토큰은 Git over HTTPS에 대해 비밀번호 대신 사용할 수 있으며, 기본 인증을 통해 API에 인증하는 데 사용할 수 있습니다. 부여된 권한에 따라 다양한 작업을 수행할 수 있습니다.
사용자 토큰은 다음과 같습니다: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Github Oauth 애플리케이션에 대한 기본 정보를 참조하여 소개를 확인하세요.
공격자는 악성 Oauth 애플리케이션을 생성하여 피싱 캠페인의 일환으로 이를 수락한 사용자의 권한 있는 데이터/작업에 접근할 수 있습니다.
Oauth 애플리케이션이 요청할 수 있는 범위입니다. 수락하기 전에 항상 요청된 범위를 확인해야 합니다.
또한, 기본 정보에서 설명한 바와 같이, 조직은 제3자 애플리케이션에 대한 접근을 허용/거부할 수 있습니다 조직과 관련된 정보/레포/작업에 대해.
Github 애플리케이션에 대한 기본 정보를 참조하여 소개를 확인하세요.
공격자는 악성 Github 애플리케이션을 생성하여 피싱 캠페인의 일환으로 이를 수락한 사용자의 권한 있는 데이터/작업에 접근할 수 있습니다.
또한, 기본 정보에서 설명한 바와 같이, 조직은 제3자 애플리케이션에 대한 접근을 허용/거부할 수 있습니다 조직과 관련된 정보/레포/작업에 대해.
Github Action을 손상시키고 남용하는 여러 기술이 있습니다. 여기에서 확인하세요:
Abusing Github Actions승인 수 요구: 여러 계정을 손상시킨 경우 다른 계정에서 PR을 수락할 수 있습니다. PR을 생성한 계정만 있다면 자신의 PR을 수락할 수 없습니다. 그러나 레포 내에서 Github Action 환경에 접근할 수 있다면, GITHUB_TOKEN을 사용하여 PR을 승인하고 이렇게 1개의 승인을 받을 수 있습니다.
이와 코드 소유자 제한에 대한 주의: 일반적으로 사용자는 자신의 PR을 승인할 수 없지만, 만약 그렇다면 이를 남용하여 자신의 PR을 수락할 수 있습니다.
새 커밋이 푸시될 때 승인 무효화: 이 설정이 되어 있지 않다면, 합법적인 코드를 제출하고 누군가가 이를 승인할 때까지 기다린 후 악성 코드를 추가하고 보호된 브랜치에 병합할 수 있습니다.
코드 소유자의 리뷰 요구: 이 설정이 활성화되어 있고 당신이 코드 소유자라면, Github Action이 당신의 PR을 생성하고 당신이 직접 승인할 수 있습니다.
CODEOWNER 파일이 잘못 구성된 경우: Github은 불만을 제기하지 않지만 이를 사용하지 않습니다. 따라서 잘못 구성된 경우 코드 소유자 보호가 적용되지 않습니다.
지정된 행위자가 풀 리퀘스트 요구 사항을 우회할 수 있도록 허용: 이러한 행위자 중 하나라면 풀 리퀘스트 보호를 우회할 수 있습니다.
관리자 포함: 이 설정이 되어 있지 않다면, 당신이 레포의 관리자라면 이 브랜치 보호를 우회할 수 있습니다.
PR 하이재킹: 다른 사람의 PR을 수정하여 악성 코드를 추가하고, 결과 PR을 승인하고 모든 것을 병합할 수 있습니다.
브랜치 보호 제거: 당신이 레포의 관리자라면 보호를 비활성화하고, PR을 병합한 후 보호를 다시 설정할 수 있습니다.
푸시 보호 우회: 레포가 특정 사용자만 브랜치에 푸시(코드 병합)를 허용하는 경우 (브랜치 보호가 모든 브랜치를 보호할 수 있습니다. 와일드카드 *를 지정하여).
레포에 대한 쓰기 권한이 있지만 브랜치 보호로 인해 코드를 푸시할 수 없는 경우, 여전히 새 브랜치를 생성하고 그 안에 코드가 푸시될 때 트리거되는 github action을 생성할 수 있습니다. 브랜치 보호는 브랜치가 생성될 때까지 보호하지 않으므로, 이 첫 번째 코드 푸시는 github action을 실행합니다.
Github 환경에 대한 기본 정보를 참조하여 소개를 확인하세요.
환경에 모든 브랜치에서 접근할 수 있는 경우, 보호되지 않으며 환경 내의 비밀에 쉽게 접근할 수 있습니다. 모든 브랜치가 보호된 레포를 찾을 수 있다는 점에 유의하세요 (이름을 지정하거나 *를 사용하여). 그런 시나리오에서는 코드를 푸시할 수 있는 브랜치를 찾아 새로운 github action을 생성하거나 수정하여 비밀을 유출할 수 있습니다.
모든 브랜치가 보호된 경우(와일드카드 *를 통해) 브랜치에 코드를 푸시할 수 있는 사람이 지정되어 있으며 (브랜치 보호에서 이를 지정할 수 있습니다) 당신의 사용자가 허용되지 않는 경우에도 여전히 사용자 정의 github action을 실행할 수 있습니다. 브랜치를 생성하고 그 자체에 대해 푸시 트리거를 사용할 수 있기 때문입니다. 브랜치 보호는 새 브랜치에 대한 푸시를 허용하므로 github action이 트리거됩니다.
Note that 브랜치 생성 후 브랜치 보호가 새 브랜치에 적용되며 수정할 수 없지만, 그때 이미 비밀을 덤프했을 것입니다.
사용자 토큰 생성
비밀에서 github 토큰 탈취
워크플로우 결과 및 브랜치 삭제
모든 조직에 더 많은 권한 부여
정보를 유출하기 위한 웹훅 생성
외부 협력자 초대
SIEM에서 사용된 웹훅 제거
백도어가 있는 Github Action 생성/수정
비밀 값 수정을 통해 명령 주입에 취약한 Github Action 찾기
Github에서는 포크에서 레포에 PR을 생성하는 것이 가능합니다. PR이 수락되지 않더라도, 원본 레포에 커밋 ID가 포크 버전의 코드에 대해 생성됩니다. 따라서 공격자는 레포 소유자가 생성하지 않은 명백히 합법적인 레포의 특정 커밋을 사용하도록 고정할 수 있습니다.
더 많은 정보는 여기를 확인하세요.
AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)
