Basic Github Information

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요!

HackTricks를 지원하는 다른 방법:

• 회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하려면 구독 요금제를 확인하세요!

• 공식 PEASS & HackTricks 스웨그를 얻으세요.

• The PEASS Family를 발견하세요. 독점적인 NFT 컬렉션입니다.

• 💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @hacktricks_live를 팔로우하세요.

• HackTricks와 HackTricks Cloud github 저장소에 PR을 제출하여 자신의 해킹 기법을 공유하세요.

기본 구조

큰 회사의 기본 Github 환경 구조는 기업이 여러 조직을 소유하고 각 조직에는 여러 저장소와 여러 팀이 포함될 수 있다는 것입니다. 더 작은 회사는 하나의 조직만 소유할 수 있습니다.

사용자 관점에서 사용자는 여러 기업과 조직의 구성원이 될 수 있습니다. 그들은 기업, 조직 및 저장소 역할에 따라 다른 기업, 조직 및 저장소에 속할 수 있습니다.

또한 사용자는 다른 기업, 조직 또는 저장소 역할을 가진 여러 팀의 일부가 될 수 있습니다.

마지막으로 저장소에는 특별한 보호 메커니즘이 있을 수 있습니다.

권한

기업 역할

• 기업 소유자: 이 역할을 가진 사람들은 관리자를 관리하고 기업 내 조직을 관리하며 기업 설정을 관리하고 조직 전체에 정책을 적용할 수 있습니다. 그러나 조직 설정 또는 콘텐츠에 직접 액세스하지 않는 한 조직 소유자로 지정되거나 조직 소유 저장소에 직접 액세스하지 않는 한 조직 설정 또는 콘텐츠에 액세스할 수 없습니다.

• 기업 구성원: 기업이 소유한 조직의 구성원은 자동으로 기업의 구성원이 됩니다.

조직 역할

조직에서 사용자는 다른 역할을 가질 수 있습니다:

• 조직 소유자: 조직 소유자는 조직에 대한 완전한 관리 액세스를 갖습니다. 이 역할은 조직 내에서 최소한 두 명의 사람에게 제한되어야 합니다.

• 조직 구성원: 기본적인 비관리 역할로서 조직의 사람들에게 부여됩니다. 기본적으로 조직 구성원은 여러 권한을 갖습니다.

• 결제 관리자: 결제 관리자는 조직의 결제 설정을 관리할 수 있는 사용자입니다.

• 보안 관리자: 조직 소유자가 조직 내의 팀에 할당할 수 있는 역할입니다. 적용되면 팀의 모든 구성원에게 조직 전체의 보안 경고 및 설정을 관리할 수 있는 권한과 조직의 모든 저장소에 대한 읽기 권한이 부여됩니다.

• 조직에 보안 팀이 있는 경우 보안 관리자 역할을 사용하여 팀 구성원에게 조직에서 필요한 최소한의 액세스 권한을 부여할 수 있습니다.

• Github 앱 관리자: 소유자는 조직이 소유한 GitHub 앱을 추가 사용자가 관리할 수 있도록 GitHub 앱 관리자 권한을 부여할 수 있습니다.

• 외부 공동 작업자: 외부 공동 작업자는 한 개 이상의 조직 저장소에 액세스할 수 있지만 명시적으로 조직의 구성원은 아닙니다.

이 테이블에서 이러한 역할의 권한을 비교할 수 있습니다: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

구성원 권한

_https://github.com/organizations/<org_name>/settings/member_privileges_에서 조직의 구성원으로서 사용자가 갖게 될 권한을 볼 수 있습니다.

여기에서 구성된 설정은 조직의 구성원의 다음 권한을 나타냅니다:

• 조직의 모든 저장소에 대한 관리자, 작성자, 리더 또는 권한 없음.

• 구성원이 개인, 내부 또는 공개 저장소를 생성할 수 있는지 여부.

• 저장소의 포크가 가능한지 여부

• 외부 공동 작업자를 초대할 수 있는지 여부

• 공개 또는 비공개 사이트를 게시할 수 있는지 여부

• 관리자가 저장소에 대해 갖는 권한

• 구성원이 새로운 팀을 생성할 수 있는지 여부

저장소 역할

기본적으로 저장소 역할은 다음과 같이 생성됩니다:

• 읽기: 프로젝트를 보거나 토론하려는 비코드 기여자에게 권장됩니다.

• 정리: 쓰기 액세스 권한 없이 이슈와 풀 리퀘스트를 미리 관리해야 하는 기여자에게 권장됩니다.

• 쓰기: 프로젝트에 적극적으로 기여하는 기여자에게 권장됩니다.

• 유지 관리: 민감한 또는 파괴적인 작업에 액세스하지 않고 저장소를 관리해야 하는 프로젝트 관리자에게 권장됩니다.

• 관리자: 보안 관리 또는 저장소 삭제와 같은 민감하고 파괴적인 작업을 포함한 프로젝트에 대한 완전한 액세스가 필요한 사람에게 권장됩니다.

이 테이블에서 각 역할의 권한을 비교할 수 있습니다: https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

_https://github.com/organizations/<org_name>/settings/roles_에서 자체 역할을 만들 수도 있습니다.

팀

_https://github.com/orgs/<org_name>/teams_에서 조직에 생성된 팀 목록을 확인할 수 있습니다. 다른 팀의 하위 팀을 볼려면 각 상위 팀에 액세스해야 합니다.

사용자

조직의 사용자는 _https://github.com/orgs/<org_name>/people_에서 목록으로 확인할 수 있습니다.

각 사용자의 정보에서 사용자가 소속된 팀과 사용자가 액세스할 수 있는 저장소를 볼 수 있습니다.

Github 인증

Github는 계정에 인증하고 사용자를 대신하여 작업을 수행하는 다양한 방법을 제공합니다.

웹 액세스

github.com에 액세스하여 **사용자 이름과

Oauth Applications

Oauth 애플리케이션은 귀하의 깃허브 정보 일부에 액세스하거나 귀하를 표현하기 위해 권한을 요청할 수 있습니다. 이 기능의 일반적인 예는 일부 플랫폼에서 찾을 수 있는 "깃허브로 로그인" 버튼입니다.

• https://github.com/settings/developers에서 자체 Oauth 애플리케이션을 만들 수 있습니다.

• https://github.com/settings/applications에서 계정에 액세스할 수 있는 모든 Oauth 애플리케이션을 볼 수 있습니다.

• https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps에서 Oauth 앱이 요청할 수 있는 스코프를 볼 수 있습니다.

• _https://github.com/organizations/<org_name>/settings/oauth_application_policy_에서 조직의 애플리케이션에 대한 타사 액세스를 볼 수 있습니다.

일부 보안 권장 사항:

• Oauth 앱은 항상 GitHub 사용자로서 GitHub 전체에서 작동해야 합니다(예: 사용자 알림 제공)만 지정된 스코프에만 액세스할 수 있어야 합니다.

• 인증된 사용자를 위해 "깃허브로 로그인"을 활성화하여 Oauth 앱을 신원 제공자로 사용할 수 있습니다.

• 애플리케이션이 단일 저장소에서 작동하도록 하려면 Oauth 앱을 빌드하지 마십시오. repo OAuth 스코프로 인해 Oauth 앱은 인증된 사용자의 모든 저장소에서 작동할 수 있습니다.

• Oauth 앱을 팀이나 회사의 애플리케이션으로 사용하지 마십시오. Oauth 앱은 단일 사용자로 인증되므로 한 사람이 회사에서 사용할 수 있도록 회사를 위해 Oauth 앱을 만든 후에 회사를 떠나면 다른 사람은 액세스할 수 없습니다.

• 여기에서 자세한 내용을 확인할 수 있습니다.

Github Applications

Github 애플리케이션은 특정 리소스에 대해 귀하의 깃허브 정보에 액세스하거나 귀하를 표현하기 위해 권한을 요청할 수 있습니다. Github 앱에서는 앱이 액세스할 저장소를 지정해야 합니다.

• GitHub 앱을 설치하려면 조직 소유자이거나 저장소에 관리자 권한이 있어야 합니다.

• GitHub 앱은 개인 계정이나 조직에 연결되어야 합니다.

• https://github.com/settings/apps에서 자체 Github 애플리케이션을 만들 수 있습니다.

• https://github.com/settings/apps/authorizations에서 계정에 액세스할 수 있는 모든 Github 애플리케이션을 볼 수 있습니다.

• 이는 https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps에서 Github 애플리케이션의 API 엔드포인트입니다. 앱의 권한에 따라 일부 엔드포인트에 액세스할 수 있습니다.

• _https://github.com/organizations/<org_name>/settings/installations_에서 조직의 설치된 앱을 볼 수 있습니다.

일부 보안 권장 사항:

• GitHub 앱은 사용자와 독립적으로 작업해야 합니다(사용자-서버 요청 토큰을 사용하는 경우에만 해당). 사용자-서버 액세스 토큰을 보다 안전하게 유지하기 위해 8시간 후에 만료되는 액세스 토큰과 새로운 액세스 토큰으로 교환할 수 있는 갱신 토큰을 사용할 수 있습니다. 자세한 내용은 "사용자-서버 액세스 토큰 갱신"을 참조하십시오.

• GitHub 앱이 특정 저장소와 통합되도록 확인하십시오.

• GitHub 앱은 개인 계정이나 조직에 연결되어야 합니다.

• GitHub 앱이 사용자가 할 수 있는 모든 작업을 알고 수행할 것으로 기대하지 마십시오.

• "깃허브로 로그인" 서비스만 필요한 경우 GitHub 앱을 사용하지 마십시오. 그러나 GitHub 앱은 사용자 식별 플로우를 사용하여 사용자를 로그인하고 다른 작업을 수행할 수 있습니다.

• GitHub 사용자로서 모든 작업을 수행하려는 경우 GitHub 앱을 빌드하지 마십시오.

• GitHub Actions에서 앱을 사용하고 워크플로 파일을 수정하려는 경우, 워크플로 파일을 포함하는 저장소에 대한 관리자 또는 쓰기 권한을 가진 사용자를 대신하여 사용자를 대신 인증해야 합니다. 자세한 내용은 "OAuth 앱의 스코프 이해"를 참조하십시오.

• 여기에서 자세한 내용을 확인할 수 있습니다.

Github Actions

이것은 깃허브에서 인증하는 방법이 아니라, 악성 깃허브 액션은 깃허브에 무단 액세스를 얻을 수 있으며, 액션에 부여된 권한에 따라 여러 가지 다른 공격이 수행될 수 있습니다. 자세한 내용은 아래를 참조하십시오.

Git Actions

Git Actions는 이벤트 발생 시 코드 실행을 자동화하는 것을 가능하게 합니다. 일반적으로 실행되는 코드는 저장소의 코드와 어떤 관련이 있는 코드입니다(예: 도커 컨테이너 빌드 또는 PR에 비밀 정보가 포함되어 있는지 확인).

구성

_https://github.com/organizations/<org_name>/settings/actions_에서 조직의 깃허브 액션 구성을 확인할 수 있습니다.

깃허브 액션의 사용을 완전히 허용하거나 모든 깃허브 액션을 허용하거나 특정 액션만 허용할 수 있습니다.

깃허브 액션을 실행하려면 누가 승인을 받아야 하는지와 깃허브 액션이 실행될 때의 GITHUB_TOKEN의 권한을 구성할 수도 있습니다.

Git Secrets

깃허브 액션은 일반적으로 깃허브나 타사 애플리케이션과 상호 작용하기 위해 일부 비밀 정보가 필요합니다. 이러한 비밀 정보를 저장소에 평문으로 넣지 않기 위해 깃허브에서는 비밀 정보를 "Secrets"로 설정할 수 있습니다.

이러한 비밀 정보는 저장소 또는 조직 전체에 대해 구성할 수 있습니다. 그런 다음 액션이 비밀 정보에 액세스할 수 있도록 선언해야 합니다. 예시:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret: ${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret: ${{ secrets.SuperSecret }}

Bash를 사용한 예제

steps:
- shell: bash
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

비밀은 비밀을 선언한 Github Actions에서만 액세스할 수 있습니다.

레포지토리나 조직에 구성된 후로는 github 사용자가 다시 액세스할 수 없으며, 그들은 단지 그것들을 변경할 수 있을 뿐입니다.

따라서, github 비밀을 도용하는 유일한 방법은 Github Action을 실행하는 기계에 액세스할 수 있는 것입니다 (이 시나리오에서는 Action에 선언된 비밀에만 액세스할 수 있습니다).

Git 환경

Github는 환경을 생성하여 비밀을 저장할 수 있도록 합니다. 그런 다음, 다음과 같이 환경 내의 비밀에 대한 github 액션 액세스를 제공할 수 있습니다:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

환경을 모든 브랜치(기본값), 보호된 브랜치만 또는 지정된 브랜치만 접근할 수 있도록 구성할 수 있습니다. 또한, 환경을 사용하여 실행하기 전에 필요한 리뷰 수를 설정하거나 배포를 진행하기 전에 일정 시간을 기다릴 수도 있습니다.

Git Action Runner

Github Action은 github 환경 내에서 실행되거나 사용자가 구성한 타사 인프라에서 실행될 수 있습니다.

여러 조직은 타사 인프라에서 Github Actions를 실행할 수 있도록 허용합니다. 이는 보통 비용이 더 저렴하기 때문입니다.

조직의 자체 호스팅 러너는 _https://github.com/organizations/<org_name>/settings/actions/runners_에서 확인할 수 있습니다.

Github Actions이 github 이외의 인프라에서 실행되는지 확인하는 방법은 Github Action 구성 yaml에서 runs-on: self-hosted를 검색하는 것입니다.

다른 조직의 Github Action을 자체 호스팅된 상자에서 실행하는 것은 불가능합니다. 왜냐하면 러너를 구성할 때 러너가 속한 위치를 알기 위해 러너에 대한 고유 토큰이 생성되기 때문입니다.

예를 들어, 사용자가 AWS 또는 GCP 내의 머신에 사용자 정의 Github 러너를 구성한 경우, 해당 Action은 메타데이터 엔드포인트에 액세스하고 머신이 실행 중인 서비스 계정의 토큰을 탈취할 수 있습니다.

Git Action Compromise

모든 작업(또는 악성 작업)이 허용되면 사용자는 실행 중인 컨테이너를 타협할 수 있는 악성 Github Action을 사용할 수 있습니다.

악성 Github Action 실행은 공격자가 다음과 같이 남용할 수 있습니다:

• Action이 액세스할 수 있는 모든 비밀 정보를 탈취

• Action이 타사 인프라에서 실행되는 경우, 머신을 실행하는 데 사용되는 SA 토큰에 액세스할 수 있으므로 측면 이동 가능

• Workflow에서 사용하는 토큰을 남용하여 Action이 실행되는 리포지토리의 코드를 탈취하거나 수정할 수 있음

브랜치 보호

브랜치 보호는 사용자에게 저장소의 완전한 제어권을 부여하지 않도록 설계되었습니다. 목표는 일부 브랜치에 코드를 작성하기 전에 여러 보호 방법을 적용하는 것입니다.

저장소의 브랜치 보호는 _https://github.com/<orgname>/<reponame>/settings/branches_에서 찾을 수 있습니다.

조직 수준에서 브랜치 보호를 설정할 수 없습니다. 따라서 모든 보호 방법은 각 리포지토리에서 선언되어야 합니다.

브랜치에 다양한 보호 방법을 적용할 수 있습니다(예: master):

• 병합하기 전에 PR을 요구할 수 있습니다(따라서 브랜치에 직접 코드를 병합할 수 없음). 이 경우 다른 보호 방법을 적용할 수 있습니다:

• 승인 요청 수를 요구할 수 있습니다. 일반적으로 PR을 승인하기 위해 1명 또는 2명 이상의 사람의 승인이 필요하여 단일 사용자가 직접 코드를 병합할 수 없습니다.

• 새로운 커밋이 푸시될 때 승인을 취소할 수 있습니다. 그렇지 않으면 사용자가 정당한 코드를 승인한 후 악성 코드를 추가하고 병합할 수 있습니다.

• Code Owners의 리뷰를 요구할 수 있습니다. 리포지토리의 적어도 1명의 코드 소유자가 PR을 승인해야 합니다(따라서 "임의"의 사용자가 승인할 수 없음).

• Pull Request 리뷰를 해제할 수 있는 사람 또는 팀을 제한할 수 있습니다. Pull Request 리뷰를 해제할 수 있는 사람 또는 팀을 지정할 수 있습니다.

• 지정된 사용자가 Pull Request 요구 사항을 우회할 수 있습니다. 이러한 사용자는 이전 제한을 우회할 수 있습니다.

• 병합하기 전에 상태 확인을 요구할 수 있습니다. 커밋을 병합하기 전에 일부 확인 사항이 통과되어야 합니다(예: cleartext 비밀 정보가 없는지 확인하는 github action).

• 병합하기 전에 대화 해결을 요구할 수 있습니다. PR을 병합하기 전에 코드에 대한 모든 코멘트를 해결해야 합니다.

• 서명된 커밋을 요구할 수 있습니다. 커밋은 서명되어야 합니다.

• 선형 기록을 요구할 수 있습니다. 병합 커밋이 일치하는 브랜치로 푸시되는 것을 방지합니다.

• 관리자 포함. 이 설정이 되어 있지 않으면 관리자는 제한을 우회할 수 있습니다.

• 일치하는 브랜치로 푸시할 수 있는 사람을 제한할 수 있습니다. PR을 보낼 수 있는 사람을 제한할 수 있습니다.

보시다시피, 사용자의 일부 자격 증명을 얻었다고 해도, 리포지토리가 보호되어 있어 master에 코드를 푸시할 수 없습니다. 이를 통해 CI/CD 파이프라인을 타협할 수 없습니다.

참고 자료

• https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization

• https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprisehttps://docs.github.com/en/enterprise-server

• https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github

• https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards

• https://docs.github.com/en/actions/security-guides/encrypted-secrets

htARTE (HackTricks AWS Red Team Expert)를 통해 **제로에서 영웅까지 AWS 해킹을 배워보세요**!

HackTricks를 지원하는 다른 방법:

• HackTricks에서 회사를 광고하거나 PDF로 HackTricks 다운로드하려면 구독 요금제를 확인하세요!

• 공식 PEASS & HackTricks 상품을 구매하세요.

• 독점적인 NFT 컬렉션인 The PEASS Family를 발견하세요.

• 💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @hacktricks_live를 팔로우하세요.