Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
대규모 회사의 기본 github 환경 구조는 여러 조직을 소유하는 기업을 소유하는 것입니다. 각 조직은 여러 리포지토리와 여러 팀을 포함할 수 있습니다. 소규모 회사는 하나의 조직만 소유하고 기업은 없을 수 있습니다.
사용자 관점에서 사용자는 다양한 기업 및 조직의 구성원이 될 수 있습니다. 그 안에서 사용자는 다양한 기업, 조직 및 리포지토리 역할을 가질 수 있습니다.
또한 사용자는 다양한 팀의 일원이 될 수 있으며, 각 팀에서 다른 기업, 조직 또는 리포지토리 역할을 가질 수 있습니다.
마지막으로 리포지토리는 특별한 보호 메커니즘을 가질 수 있습니다.
Enterprise owner: 이 역할을 가진 사람들은 관리자를 관리하고, 기업 내 조직을 관리하며, 기업 설정을 관리하고, 조직 전반에 걸쳐 정책을 시행할 수 있습니다. 그러나 그들은 조직 소유자로 지정되거나 조직 소유 리포지토리에 직접 접근 권한이 부여되지 않는 한 조직 설정이나 콘텐츠에 접근할 수 없습니다.
Enterprise members: 귀하의 기업이 소유한 조직의 구성원은 자동으로 기업의 구성원이 됩니다.
조직 내에서 사용자는 다양한 역할을 가질 수 있습니다:
Organization owners: 조직 소유자는 조직에 대한 완전한 관리 접근 권한을 가집니다. 이 역할은 제한되어야 하며, 조직 내에서 두 명 이상이어야 합니다.
Organization members: 조직 내 사람들의 기본 비관리자 역할은 조직 구성원입니다. 기본적으로 조직 구성원은 일정 수의 권한을 가집니다.
Billing managers: 청구 관리자는 조직의 청구 설정을 관리할 수 있는 사용자입니다. 예를 들어 결제 정보와 같은 것입니다.
Security Managers: 조직 소유자가 조직 내의 모든 팀에 부여할 수 있는 역할입니다. 적용되면 팀의 모든 구성원에게 조직 전반에 걸쳐 보안 경고 및 설정을 관리할 수 있는 권한과 모든 리포지토리에 대한 읽기 권한이 부여됩니다.
조직에 보안 팀이 있는 경우, 보안 관리자 역할을 사용하여 팀 구성원에게 조직에 필요한 최소한의 접근 권한을 부여할 수 있습니다.
Github App managers: 조직이 소유한 GitHub Apps를 관리할 수 있는 추가 사용자를 허용하기 위해 소유자는 GitHub App 관리자 권한을 부여할 수 있습니다.
Outside collaborators: 외부 협력자는 하나 이상의 조직 리포지토리에 접근할 수 있지만 명시적으로 조직의 구성원이 아닌 사람입니다.
이 역할의 권한을 비교할 수 있는 표는 다음과 같습니다: 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_에서 조직의 일원으로서 사용자가 가질 권한을 확인할 수 있습니다.
여기에서 구성된 설정은 조직 구성원의 다음 권한을 나타냅니다:
모든 조직 리포지토리에 대한 관리자, 작성자, 독자 또는 권한 없음.
구성원이 개인, 내부 또는 공개 리포지토리를 생성할 수 있는지 여부.
리포지토리 포크가 가능한지 여부.
외부 협력자를 초대할 수 있는지 여부.
공개 또는 개인 사이트를 게시할 수 있는지 여부.
관리자가 리포지토리에 대해 가지는 권한.
구성원이 새로운 팀을 생성할 수 있는지 여부.
기본적으로 리포지토리 역할이 생성됩니다:
Read: 코드 기여자가 아닌 사람들이 프로젝트를 보고 논의하기 위해 추천됩니다.
Triage: 문제 및 풀 요청을 능동적으로 관리해야 하는 기여자에게 추천됩니다. 쓰기 접근 권한은 없습니다.
Write: 프로젝트에 적극적으로 푸시하는 기여자에게 추천됩니다.
Maintain: 민감하거나 파괴적인 작업에 접근하지 않고 리포지토리를 관리해야 하는 프로젝트 관리자에게 추천됩니다.
Admin: 프로젝트에 대한 완전한 접근 권한이 필요한 사람에게 추천됩니다. 여기에는 보안 관리 또는 리포지토리 삭제와 같은 민감하고 파괴적인 작업이 포함됩니다.
각 역할의 권한을 비교할 수 있는 표는 다음과 같습니다: 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.com에 접근하여 사용자 이름과 비밀번호(및 2FA를 사용할 수 있음)를 사용하여 로그인할 수 있습니다.
하나 이상의 공개 키로 계정을 구성하여 관련 개인 키가 귀하를 대신하여 작업을 수행할 수 있도록 할 수 있습니다. https://github.com/settings/keys
이 키로 사용자를 가장할 수는 없지만 사용하지 않으면 서명 없는 커밋을 보내는 것으로 인해 발견될 수 있습니다. 여기에서 경계 모드에 대해 더 알아보세요.
응용 프로그램이 귀하의 계정에 접근할 수 있도록 개인 접근 토큰을 생성할 수 있습니다. 개인 접근 토큰을 생성할 때 사용자는 토큰이 가질 권한을 지정해야 합니다. https://github.com/settings/tokens
Oauth 응용 프로그램은 귀하의 github 정보의 일부에 접근하거나 귀하를 가장하여 특정 작업을 수행하기 위해 권한을 요청할 수 있습니다. 이 기능의 일반적인 예는 일부 플랫폼에서 찾을 수 있는 github로 로그인 버튼입니다.
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 Apps가 요청할 수 있는 범위를 확인할 수 있습니다.
_https://github.com/organizations/<org_name>/settings/oauth_application_policy_에서 조직의 응용 프로그램에 대한 제3자 접근을 확인할 수 있습니다.
일부 보안 권장 사항:
OAuth App은 항상 모든 GitHub에서 인증된 GitHub 사용자로서 행동해야 하며, 지정된 범위에만 접근해야 합니다.
OAuth App은 인증된 사용자를 위해 "GitHub로 로그인"을 활성화하여 신원 공급자로 사용할 수 있습니다.
단일 리포지토리에서 작동하도록 하려면 OAuth App을 만들지 마십시오. repo OAuth 범위를 사용하면 OAuth Apps는 인증된 사용자의 모든 리포지토리에서 작동할 수 있습니다.
팀이나 회사의 응용 프로그램으로 작동하도록 OAuth App을 만들지 마십시오. OAuth Apps는 단일 사용자로 인증되므로, 한 사람이 회사를 위해 OAuth App을 만들고 회사를 떠나면 다른 누구도 접근할 수 없습니다.
자세한 내용은 여기에서 여기에서 확인하세요.
Github 응용 프로그램은 귀하의 github 정보에 접근하거나 귀하를 가장하여 특정 리소스에 대해 특정 작업을 수행하기 위해 권한을 요청할 수 있습니다. Github Apps에서는 앱이 접근할 리포지토리를 지정해야 합니다.
GitHub App을 설치하려면 조직 소유자이거나 리포지토리에서 관리자 권한이 있어야 합니다.
GitHub App은 개인 계정 또는 조직에 연결해야 합니다.
https://github.com/settings/apps에서 자신의 Github 응용 프로그램을 생성할 수 있습니다.
https://github.com/settings/apps/authorizations에서 귀하의 계정에 접근할 수 있는 모든 Github 응용 프로그램을 확인할 수 있습니다.
Github 응용 프로그램을 위한 API 엔드포인트는 다음과 같습니다: https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. 앱의 권한에 따라 일부에 접근할 수 있습니다.
_https://github.com/organizations/<org_name>/settings/installations_에서 조직에 설치된 앱을 확인할 수 있습니다.
일부 보안 권장 사항:
GitHub App은 사용자와 독립적으로 작업해야 합니다(앱이 사용자-서버 토큰을 사용하는 경우 제외). 사용자-서버 접근 토큰을 더 안전하게 유지하려면 8시간 후 만료되는 접근 토큰과 새 접근 토큰으로 교환할 수 있는 갱신 토큰을 사용할 수 있습니다. 자세한 내용은 "사용자-서버 접근 토큰 갱신"을 참조하세요.
GitHub App이 특정 리포지토리와 통합되도록 하세요.
GitHub App은 개인 계정 또는 조직에 연결해야 합니다.
GitHub App이 사용자가 할 수 있는 모든 것을 알고 수행할 것이라고 기대하지 마십시오.
GitHub로 로그인 서비스가 필요할 뿐이라면 GitHub App을 사용하지 마십시오. 그러나 GitHub App은 사용자 식별 흐름을 사용하여 사용자를 로그인시키고 다른 작업을 수행할 수 있습니다.
GitHub 사용자의 역할만 수행하고 사용자가 할 수 있는 모든 작업을 수행하려는 경우 GitHub App을 만들지 마십시오.
GitHub Actions와 함께 앱을 사용하고 워크플로 파일을 수정하려는 경우, workflow 범위를 포함하는 OAuth 토큰을 사용하여 사용자를 대신하여 인증해야 합니다. 사용자는 워크플로 파일이 포함된 리포지토리에 대한 관리자 또는 쓰기 권한이 있어야 합니다. 자세한 내용은 "OAuth 앱을 위한 범위 이해하기"를 참조하세요.
자세한 내용은 여기에서 여기에서 확인하세요.
이것은 github에서 인증하는 방법이 아니지만, 악의적인 Github Action이 github에 무단 접근을 얻을 수 있으며, Action에 부여된 권한에 따라 여러 다양한 공격이 발생할 수 있습니다. 아래에서 더 많은 정보를 확인하세요.
Git actions는 이벤트가 발생할 때 코드를 실행하는 자동화를 허용합니다. 일반적으로 실행되는 코드는 리포지토리의 코드와 관련이 있습니다(예: 도커 컨테이너를 빌드하거나 PR에 비밀이 포함되지 않았는지 확인).
_https://github.com/organizations/<org_name>/settings/actions_에서 조직의 github actions 구성을 확인할 수 있습니다.
github actions의 사용을 완전히 금지하거나, 모든 github actions을 허용하거나, 특정 작업만 허용할 수 있습니다.
또한 Github Action을 실행하기 위해 승인해야 하는 사람과 Github Action이 실행될 때의 GITHUB_TOKEN의 권한을 구성할 수 있습니다.
Github Action은 일반적으로 github 또는 제3자 응용 프로그램과 상호작용하기 위해 어떤 종류의 비밀이 필요합니다. 리포지토리에 평문으로 넣는 것을 피하기 위해 github은 이를 Secrets로 설정할 수 있도록 허용합니다.
이 비밀은 리포지토리 또는 조직 전체에 대해 구성할 수 있습니다. 그런 다음 Action이 비밀에 접근할 수 있도록 하려면 다음과 같이 선언해야 합니다:
비밀은 그것들이 선언된 Github Actions에서만 접근할 수 있습니다.
레포지토리나 조직에 설정된 후 github 사용자들은 다시 접근할 수 없으며, 그들은 변경만 할 수 있습니다.
따라서, github 비밀을 훔치는 유일한 방법은 Github Action을 실행하는 머신에 접근할 수 있는 것입니다 (그 시나리오에서는 Action에 대해 선언된 비밀만 접근할 수 있습니다).
Github는 비밀을 저장할 수 있는 환경을 생성할 수 있도록 허용합니다. 그런 다음, 환경 내의 비밀에 대한 접근을 github action에 다음과 같이 부여할 수 있습니다:
You can configure an environment to be accessed by all branches (default), only protected branches or specify which branches can access it. It can also set a number of required reviews before executing an action using an environment or wait some time before allowing deployments to proceed.
A Github Action can be executed inside the github environment or can be executed in a third party infrastructure configured by the user.
Several organizations will allow to run Github Actions in a third party infrastructure as it use to be cheaper.
You can list the self-hosted runners of an organization in https://github.com/organizations/<org_name>/settings/actions/runners
The way to find which Github Actions are being executed in non-github infrastructure is to search for runs-on: self-hosted in the Github Action configuration yaml.
It's not possible to run a Github Action of an organization inside a self hosted box of a different organization because a unique token is generated for the Runner when configuring it to know where the runner belongs.
If the custom Github Runner is configured in a machine inside AWS or GCP for example, the Action could have access to the metadata endpoint and steal the token of the service account the machine is running with.
If all actions (or a malicious action) are allowed a user could use a Github action that is malicious and will compromise the container where it's being executed.
A malicious Github Action run could be abused by the attacker to:
Steal all the secrets the Action has access to
Move laterally if the Action is executed inside a third party infrastructure where the SA token used to run the machine can be accessed (probably via the metadata service)
Abuse the token used by the workflow to steal the code of the repo where the Action is executed or even modify it.
Branch protections are designed to not give complete control of a repository to the users. The goal is to put several protection methods before being able to write code inside some branch.
The branch protections of a repository can be found in https://github.com/<orgname>/<reponame>/settings/branches
It's not possible to set a branch protection at organization level. So all of them must be declared on each repo.
Different protections can be applied to a branch (like to master):
You can require a PR before merging (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
Require a number of approvals. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
Dismiss approvals when new commits are pushed. If not, a user may approve legit code and then the user could add malicious code and merge it.
Require reviews from Code Owners. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
Restrict who can dismiss pull request reviews. You can specify people or teams allowed to dismiss pull request reviews.
Allow specified actors to bypass pull request requirements. These users will be able to bypass previous restrictions.
Require status checks to pass before merging. Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
Require conversation resolution before merging. All comments on the code needs to be resolved before the PR can be merged.
Require signed commits. The commits need to be signed.
Require linear history. Prevent merge commits from being pushed to matching branches.
Include administrators. If this isn't set, admins can bypass the restrictions.
Restrict who can push to matching branches. Restrict who can send a PR.
As you can see, even if you managed to obtain some credentials of a user, repos might be protected avoiding you to pushing code to master for example to compromise the CI/CD pipeline.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
