Korean - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Github Security

Support HackTricks

What is Github

(From here) At a high level, GitHub는 개발자가 코드를 저장하고 관리하며 코드 변경 사항을 추적하고 제어하는 데 도움을 주는 웹사이트이자 클라우드 기반 서비스입니다.

Basic Information

Basic Github Information

External Recon

Github 저장소는 공개, 비공개 및 내부로 구성할 수 있습니다.

  • 비공개는 조직의 사람들만 접근할 수 있음을 의미합니다.

  • 내부는 기업의 사람들만 접근할 수 있음을 의미합니다(기업은 여러 조직을 가질 수 있습니다).

  • 공개는 모든 인터넷 사용자가 접근할 수 있음을 의미합니다.

대상으로 삼고자 하는 사용자, 저장소 또는 조직을 알고 있는 경우 github dorks를 사용하여 민감한 정보를 찾거나 각 저장소에서 민감한 정보 유출을 검색할 수 있습니다.

Github Dorks

Github는 사용자, 저장소 또는 조직을 범위로 지정하여 무언가를 검색할 수 있도록 허용합니다. 따라서 민감한 정보 근처에 나타날 문자열 목록을 사용하여 대상에서 잠재적인 민감한 정보를 쉽게 검색할 수 있습니다.

도구(각 도구는 자신의 dorks 목록을 포함합니다):

Github Leaks

Github dorks는 github 검색 옵션을 사용하여 유출을 검색하는 데에도 사용됩니다. 이 섹션은 각 저장소를 다운로드하고 그 안에서 민감한 정보를 검색하는 도구에 전념하고 있습니다(특정 깊이의 커밋을 확인하는 것 포함).

도구(각 도구는 자신의 regex 목록을 포함합니다):

저장소에서 유출을 찾고 git log -p와 같은 명령을 실행할 때 다른 커밋이 포함된 다른 브랜치가 있을 수 있음을 잊지 마세요!

External Forks

풀 요청을 악용하여 저장소를 손상시킬 수 있습니다. 저장소가 취약한지 확인하려면 주로 Github Actions yaml 구성을 읽어야 합니다. 자세한 내용은 아래를 참조하세요.

Github Leaks in deleted/internal forks

삭제되었거나 내부에 있더라도 github 저장소의 포크에서 민감한 데이터를 얻는 것이 가능할 수 있습니다. 여기에서 확인하세요:

Accessible Deleted Data in Github

Organization Hardening

Member Privileges

조직의 구성원에게 할당할 수 있는 기본 권한이 있습니다. 이는 https://github.com/organizations/<org_name>/settings/member_privileges 페이지 또는 Organizations API에서 제어할 수 있습니다.

  • 기본 권한: 구성원은 조직 저장소에 대해 None/Read/write/Admin 권한을 가집니다. 권장되는 것은 None 또는 Read입니다.

  • 저장소 포크: 필요하지 않은 경우, 구성원이 조직 저장소를 포크하는 것을 허용하지 않는 것이 좋습니다.

  • 페이지 생성: 필요하지 않은 경우, 구성원이 조직 저장소에서 페이지를 게시하는 것을 허용하지 않는 것이 좋습니다. 필요하다면 공개 또는 비공개 페이지 생성을 허용할 수 있습니다.

  • 통합 접근 요청: 이 기능이 활성화되면 외부 협력자가 이 조직 및 그 자원에 접근하기 위해 GitHub 또는 OAuth 앱에 대한 접근을 요청할 수 있습니다. 일반적으로 필요하지만, 필요하지 않은 경우 비활성화하는 것이 좋습니다.

  • 이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요.

  • 저장소 가시성 변경: 활성화된 경우, 저장소에 대한 admin 권한을 가진 구성원은 가시성을 변경할 수 있습니다. 비활성화된 경우, 조직 소유자만 저장소 가시성을 변경할 수 있습니다. 사람들이 공개로 만들지 않기를 원한다면, 이 기능이 비활성화되어 있는지 확인하세요.

  • 이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요.

  • 저장소 삭제 및 전송: 활성화된 경우, 저장소에 대한 admin 권한을 가진 구성원은 공개 및 비공식 저장소를 삭제하거나 전송할 수 있습니다.

  • 이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요.

  • 구성원이 팀을 생성할 수 있도록 허용: 활성화된 경우, 조직의 모든 구성원이 새 팀을 생성할 수 있습니다. 비활성화된 경우, 조직 소유자만 새 팀을 생성할 수 있습니다. 이 기능은 비활성화하는 것이 좋습니다.

  • 이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요.

  • 이 페이지에서 더 많은 설정을 구성할 수 있지만, 이전 항목들이 보안과 관련된 것들입니다.

Actions Settings

여러 보안 관련 설정을 https://github.com/organizations/<org_name>/settings/actions 페이지에서 구성할 수 있습니다.

모든 설정은 각 저장소에서 독립적으로 설정할 수도 있습니다.

  • Github actions 정책: 어떤 저장소가 워크플로를 실행할 수 있는지, 어떤 워크플로가 허용되어야 하는지를 지정할 수 있습니다. 어떤 저장소가 허용되어야 하는지 명시하는 것이 좋으며, 모든 작업이 실행되도록 허용하지 않는 것이 좋습니다.

  • API-1, API-2

  • 외부 협력자의 포크 풀 요청 워크플로: 모든 외부 협력자에 대해 승인을 요구하는 것이 좋습니다.

  • 이 정보가 포함된 API를 찾을 수 없었습니다. 아는 분은 공유해 주세요.

  • 포크 풀 요청에서 워크플로 실행: 풀 요청에서 워크플로를 실행하는 것은 강력히 권장되지 않습니다. 포크 원본의 유지 관리자가 소스 저장소에 대한 읽기 권한이 있는 토큰을 사용할 수 있는 능력을 부여받기 때문입니다.

  • 이 정보가 포함된 API를 찾을 수 없었습니다. 아는 분은 공유해 주세요.

  • 워크플로 권한: 읽기 저장소 권한만 부여하는 것이 강력히 권장됩니다. GITHUB_TOKEN이 실행 중인 워크플로에 남용되지 않도록 쓰기 및 풀 요청 생성/승인 권한을 부여하는 것은 권장되지 않습니다.

  • API

Integrations

이 정보에 접근할 수 있는 API 엔드포인트를 아는 경우 알려주세요!

  • 타사 애플리케이션 접근 정책: 모든 애플리케이션에 대한 접근을 제한하고 필요한 애플리케이션만 허용하는 것이 좋습니다(검토 후).

  • 설치된 GitHub Apps: 필요한 애플리케이션만 허용하는 것이 좋습니다(검토 후).

Recon & Attacks abusing credentials

이 시나리오에서는 github 계정에 대한 접근을 얻었다고 가정합니다.

With User Credentials

조직 내 사용자에 대한 자격 증명이 있는 경우 로그인하여 기업 및 조직 역할을 확인할 수 있습니다. 일반 구성원인 경우, 일반 구성원이 가진 권한, 어떤 그룹에 속해 있는지, 어떤 저장소에 대해 어떤 권한을 가지고 있는지, 그리고 저장소가 어떻게 보호되는지를 확인하세요.

2FA가 사용될 수 있으므로 이 정보를 얻으려면 그 검사를 통과해야 합니다.

user_session 쿠키를 훔치는 데 성공하면(현재 SameSite: Lax로 구성됨) 자격 증명이나 2FA 없이 사용자를 완전히 가장할 수 있습니다.

유용할 경우를 대비해 브랜치 보호 우회 섹션을 확인하세요.

With User SSH Key

Github는 사용자가 SSH 키를 설정하여 그들의 이름으로 코드를 배포하는 인증 방법으로 사용할 수 있도록 허용합니다(2FA가 적용되지 않음).

이 키를 사용하여 사용자가 일부 권한을 가진 저장소에서 변경을 수행할 수 있지만, github api에 접근하여 환경을 나열하는 데 사용할 수는 없습니다. 그러나 로컬 설정을 나열하여 접근할 수 있는 저장소 및 사용자에 대한 정보를 얻을 수 있습니다:

# Go to the the repository folder
# Get repo config and current user name and email
git config --list

사용자가 자신의 GitHub 사용자 이름으로 사용자 이름을 구성한 경우, _https://github.com/<github_username>.keys_에서 그가 설정한 공개 키에 접근할 수 있습니다. 이를 확인하여 찾은 개인 키를 사용할 수 있는지 확인할 수 있습니다.

SSH 키는 배포 키로 리포지토리에 설정될 수도 있습니다. 이 키에 접근할 수 있는 사람은 리포지토리에서 프로젝트를 시작할 수 있습니다. 일반적으로 서로 다른 배포 키가 있는 서버에서는 로컬 파일 **~/.ssh/config**가 관련된 키에 대한 정보를 제공합니다.

GPG 키

여기에서 설명한 바와 같이, 때때로 커밋에 서명해야 하거나 발견될 수 있습니다.

현재 사용자가 어떤 키를 가지고 있는지 로컬에서 확인하세요:

gpg --list-secret-keys --keyid-format=long

사용자 토큰 사용

사용자 토큰에 대한 기본 정보를 참조하여 소개를 확인하세요.

사용자 토큰은 Git over HTTPS에 대해 비밀번호 대신 사용할 수 있으며, 기본 인증을 통해 API에 인증하는 데 사용할 수 있습니다. 부여된 권한에 따라 다양한 작업을 수행할 수 있습니다.

사용자 토큰은 다음과 같습니다: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123

Oauth 애플리케이션 사용

Github Oauth 애플리케이션에 대한 기본 정보를 참조하여 소개를 확인하세요.

공격자는 악성 Oauth 애플리케이션을 생성하여 피싱 캠페인의 일환으로 이를 수락한 사용자의 권한 있는 데이터/작업에 접근할 수 있습니다.

Oauth 애플리케이션이 요청할 수 있는 범위입니다. 수락하기 전에 항상 요청된 범위를 확인해야 합니다.

또한, 기본 정보에서 설명한 바와 같이, 조직은 제3자 애플리케이션에 대한 접근을 허용/거부할 수 있습니다 조직과 관련된 정보/레포/작업에 대해.

Github 애플리케이션 사용

Github 애플리케이션에 대한 기본 정보를 참조하여 소개를 확인하세요.

공격자는 악성 Github 애플리케이션을 생성하여 피싱 캠페인의 일환으로 이를 수락한 사용자의 권한 있는 데이터/작업에 접근할 수 있습니다.

또한, 기본 정보에서 설명한 바와 같이, 조직은 제3자 애플리케이션에 대한 접근을 허용/거부할 수 있습니다 조직과 관련된 정보/레포/작업에 대해.

Github Action의 손상 및 남용

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이 트리거됩니다.

push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch

Note that 브랜치 생성 후 브랜치 보호가 새 브랜치에 적용되며 수정할 수 없지만, 그때 이미 비밀을 덤프했을 것입니다.

Persistence

  • 사용자 토큰 생성

  • 비밀에서 github 토큰 탈취

  • 워크플로우 결과 및 브랜치 삭제

  • 모든 조직에 더 많은 권한 부여

  • 정보를 유출하기 위한 웹훅 생성

  • 외부 협력자 초대

  • SIEM에서 사용된 웹훅 제거

  • 백도어가 있는 Github Action 생성/수정

  • 비밀 값 수정을 통해 명령 주입에 취약한 Github Action 찾기

Imposter Commits - 레포 커밋을 통한 백도어

Github에서는 포크에서 레포에 PR을 생성할 수 있습니다. PR이 수락되지 않더라도, 원본 레포 내에 커밋 ID가 포크 버전의 코드에 대해 생성됩니다. 따라서 공격자는 레포 소유자가 생성하지 않은 명백히 합법적인 레포에서 특정 커밋을 사용하도록 고정할 수 있습니다.

Like this:

name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'

더 많은 정보는 여기를 확인하세요.

HackTricks 지원하기
PreviousPentesting CI/CD MethodologyNextAbusing Github Actions

Last updated