# Basic Github Information

{{#include ../../banners/hacktricks-training.md}}

## Basic Structure

대규모 **회사**의 기본 github 환경 구조는 **여러 조직**을 소유하는 **기업**을 소유하는 것입니다. 각 조직은 **여러 리포지토리**와 **여러 팀**을 포함할 수 있습니다. 소규모 회사는 **하나의 조직과 기업이 없는 경우**도 있습니다.

사용자 관점에서 **사용자**는 **다양한 기업 및 조직의 구성원**이 될 수 있습니다. 그들 안에서 사용자는 **다양한 기업, 조직 및 리포지토리 역할**을 가질 수 있습니다.

또한 사용자는 **다양한 팀의 일원**이 될 수 있으며, 각 팀에서 다른 기업, 조직 또는 리포지토리 역할을 가질 수 있습니다.

마지막으로 **리포지토리는 특별한 보호 메커니즘을 가질 수 있습니다**.

## Privileges

### Enterprise Roles

- **Enterprise owner**: 이 역할을 가진 사람들은 **관리자를 관리하고, 기업 내 조직을 관리하며, 기업 설정을 관리하고, 조직 전반에 정책을 시행**할 수 있습니다. 그러나 그들은 **조직 소유자**로 지정되거나 조직 소유 리포지토리에 직접 접근 권한이 부여되지 않는 한 조직 설정이나 콘텐츠에 접근할 수 없습니다.
- **Enterprise members**: 귀하의 기업이 소유한 조직의 구성원은 **자동으로 기업의 구성원**이 됩니다.

### Organization Roles

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

- **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://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)

### Members Privileges

_https://github.com/organizations/\<org_name>/settings/member_privileges_에서 **조직의 일원으로서 사용자가 가질 권한**을 확인할 수 있습니다.

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

- 모든 조직 리포지토리에 대한 관리자, 작성자, 독자 또는 권한 없음.
- 구성원이 개인, 내부 또는 공개 리포지토리를 생성할 수 있는지 여부.
- 리포지토리 포크가 가능한지 여부.
- 외부 협력자를 초대할 수 있는지 여부.
- 공개 또는 비공식 사이트를 게시할 수 있는지 여부.
- 관리자가 리포지토리에 대해 가지는 권한.
- 구성원이 새로운 팀을 생성할 수 있는지 여부.

### Repository Roles

기본적으로 리포지토리 역할이 생성됩니다:

- **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://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_에서 **자신만의 역할을 생성**할 수 있습니다.

### Teams

조직 내에서 **생성된 팀을 나열**할 수 있습니다: _https://github.com/orgs/\<org_name>/teams_. 다른 팀의 자식 팀을 보려면 각 상위 팀에 접근해야 합니다.

### Users

조직의 사용자는 _https://github.com/orgs/\<org_name>/people_에서 **나열**될 수 있습니다.

각 사용자의 정보에서 **사용자가 속한 팀**과 **사용자가 접근할 수 있는 리포지토리**를 확인할 수 있습니다.

## Github Authentication

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

### Web Access

**github.com**에 접근하여 **사용자 이름과 비밀번호**(및 **2FA**를 사용할 수 있음)를 사용하여 로그인할 수 있습니다.

### **SSH Keys**

하나 이상의 공개 키로 계정을 구성하여 관련 **개인 키가 귀하를 대신하여 작업을 수행할 수 있도록** 할 수 있습니다. [https://github.com/settings/keys](https://github.com/settings/keys)

#### **GPG Keys**

이 키로 사용자를 가장할 수는 없지만 사용하지 않으면 **서명 없는 커밋을 보내는 것으로 인해 발견될 수 있습니다**. [경계 모드에 대한 자세한 내용](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode)을 확인하세요.

### **Personal Access Tokens**

응용 프로그램이 귀하의 계정에 접근할 수 있도록 **개인 접근 토큰을 생성**할 수 있습니다. 개인 접근 토큰을 생성할 때 **사용자**는 **토큰**이 가질 **권한**을 **지정**해야 합니다. [https://github.com/settings/tokens](https://github.com/settings/tokens)

### Oauth Applications

Oauth 응용 프로그램은 귀하의 **github 정보의 일부에 접근하거나 귀하를 가장하여** 특정 작업을 수행할 수 있는 권한을 요청할 수 있습니다. 이 기능의 일반적인 예는 일부 플랫폼에서 찾을 수 있는 **github로 로그인 버튼**입니다.

- **Oauth 응용 프로그램**을 [https://github.com/settings/developers](https://github.com/settings/developers)에서 생성할 수 있습니다.
- 귀하의 계정에 접근할 수 있는 모든 **Oauth 응용 프로그램**을 [https://github.com/settings/applications](https://github.com/settings/applications)에서 확인할 수 있습니다.
- **Oauth Apps가 요청할 수 있는 범위**는 [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)에서 확인할 수 있습니다.
- **조직**의 응용 프로그램에 대한 제3자 접근은 _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_에서 확인할 수 있습니다.

몇 가지 **보안 권장 사항**:

- **OAuth App**은 항상 **모든 GitHub에서 인증된 GitHub 사용자로서 행동**해야 하며, 지정된 범위에만 접근해야 합니다.
- OAuth App은 인증된 사용자를 위해 "GitHub로 로그인"을 활성화하여 신원 공급자로 사용할 수 있습니다.
- **단일 리포지토리**에서 작동하도록 애플리케이션을 만들지 마십시오. `repo` OAuth 범위를 사용하면 OAuth Apps는 **인증된 사용자의 모든 리포지토리에서 작동**할 수 있습니다.
- **팀이나 회사**를 위한 애플리케이션으로 작동하도록 OAuth App을 만들지 마십시오. OAuth Apps는 **단일 사용자**로 인증되므로, 한 사람이 회사를 위해 OAuth App을 만들고 회사를 떠나면 다른 누구도 접근할 수 없습니다.
- **자세한 내용은 여기**에서 확인하세요: [https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).

### Github Applications

Github 응용 프로그램은 귀하의 **github 정보에 접근하거나 귀하를 가장하여** 특정 리소스에 대해 특정 작업을 수행할 수 있는 권한을 요청할 수 있습니다. Github Apps에서는 앱이 접근할 리포지토리를 지정해야 합니다.

- GitHub App을 설치하려면 **조직 소유자이거나 리포지토리에서 관리자 권한**이 있어야 합니다.
- GitHub App은 **개인 계정 또는 조직**에 연결해야 합니다.
- [https://github.com/settings/apps](https://github.com/settings/apps)에서 자신만의 Github 응용 프로그램을 생성할 수 있습니다.
- [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)에서 귀하의 계정에 접근할 수 있는 모든 **Github 응용 프로그램**을 확인할 수 있습니다.
- 다음은 **Github 응용 프로그램을 위한 API 엔드포인트**입니다: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). 앱의 권한에 따라 일부에 접근할 수 있습니다.
- **조직**에 설치된 앱은 _https://github.com/organizations/\<org_name>/settings/installations_에서 확인할 수 있습니다.

몇 가지 보안 권장 사항:

- GitHub App은 **사용자와 독립적으로 행동해야 합니다**(앱이 [사용자-서버](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) 토큰을 사용하는 경우 제외). 사용자-서버 접근 토큰을 더 안전하게 유지하려면 8시간 후 만료되는 접근 토큰과 새 접근 토큰으로 교환할 수 있는 갱신 토큰을 사용할 수 있습니다. 자세한 내용은 "[사용자-서버 접근 토큰 갱신](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)"을 참조하세요.
- GitHub App이 **특정 리포지토리**와 통합되도록 하세요.
- GitHub App은 **개인 계정 또는 조직**에 연결해야 합니다.
- GitHub App이 사용자가 할 수 있는 모든 것을 알고 수행할 것이라고 기대하지 마십시오.
- **"GitHub로 로그인" 서비스가 필요할 뿐이라면 GitHub App을 사용하지 마십시오**. 그러나 GitHub App은 [사용자 식별 흐름](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps)을 사용하여 사용자를 로그인시키고 다른 작업을 수행할 수 있습니다.
- GitHub 사용자의 역할만 수행하고 사용자가 할 수 있는 모든 작업을 수행하려는 경우 GitHub App을 만들지 마십시오.
- GitHub Actions와 함께 앱을 사용하고 워크플로 파일을 수정하려는 경우, `workflow` 범위를 포함하는 OAuth 토큰을 사용하여 사용자를 대신하여 인증해야 합니다. 사용자는 워크플로 파일이 포함된 리포지토리에 대한 관리자 또는 쓰기 권한이 있어야 합니다. 자세한 내용은 "[OAuth 앱을 위한 범위 이해하기](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)"를 참조하세요.
- **자세한 내용은 여기**에서 확인하세요: [https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).

### Github Actions

이것은 **github에서 인증하는 방법**이 아니지만, **악의적인** Github Action이 **github에 무단 접근**을 할 수 있으며, Action에 부여된 **권한**에 따라 여러 **다양한 공격**이 발생할 수 있습니다. 아래에서 더 많은 정보를 확인하세요.

## Git Actions

Git actions는 **이벤트가 발생할 때 코드 실행을 자동화**할 수 있습니다. 일반적으로 실행되는 코드는 **리포지토리의 코드와 관련이 있습니다**(예: 도커 컨테이너를 빌드하거나 PR에 비밀이 포함되지 않았는지 확인).

### Configuration

_https://github.com/organizations/\<org_name>/settings/actions_에서 조직의 **github actions 구성**을 확인할 수 있습니다.

GitHub Actions의 사용을 완전히 금지하거나, **모든 GitHub Actions을 허용**하거나, 특정 작업만 허용하도록 설정할 수 있습니다.

또한 **GitHub Action을 실행하기 위해 승인해야 하는 사람**과 GitHub Action이 실행될 때의 **GITHUB_TOKEN의 권한**을 구성할 수 있습니다.

### Git Secrets

GitHub Action은 일반적으로 GitHub 또는 제3자 애플리케이션과 상호작용하기 위해 어떤 종류의 비밀이 필요합니다. **리포지토리에 평문으로 넣는 것을 피하기 위해** GitHub은 이를 **Secrets**로 설정할 수 있도록 허용합니다.

이 비밀은 **리포지토리 또는 조직 전체에 대해 구성**할 수 있습니다. 그런 다음 **Action이 비밀에 접근할 수 있도록** 하려면 다음과 같이 선언해야 합니다:
```yaml
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 사용 예 <a href="#example-using-bash" id="example-using-bash"></a>
```yaml
steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"
```
> [!WARNING]
> Secrets **는 선언된 Github Actions에서만 접근할 수 있습니다.**

> 레포지토리나 조직에 구성된 후 **github 사용자는 다시 접근할 수 없으며**, 그들은 **변경만 할 수 있습니다.**

따라서, **github 비밀을 훔치는 유일한 방법은 Github Action을 실행하는 머신에 접근할 수 있는 것입니다** (그 시나리오에서는 Action에 대해 선언된 비밀만 접근할 수 있습니다).

### Git Environments

Github는 **비밀**을 저장할 수 있는 **환경**을 생성할 수 있도록 허용합니다. 그런 다음, 환경 내의 비밀에 대한 접근을 github action에 제공할 수 있습니다:
```yaml
jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name
```
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.

### Git Action Runner

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.

### Git Action Compromise

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.

> [!CAUTION]
> 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

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_

> [!NOTE]
> 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.

> [!NOTE]
> 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.

## References

- [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](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-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
- [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](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/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](https://docs.github.com/en/actions/security-guides/encrypted-secrets)

{{#include ../../banners/hacktricks-training.md}}