基本的な Github 情報

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

基本構造

大企業の基本的な github 環境構成は、複数の organizations を所有する enterprise を持ち、それぞれの organization が 複数の repositories や 複数の teams を含む、というものです。小規模な会社は 1つの organization を所有し enterprise を持たない 場合があります。

ユーザーの観点では、user は 異なる enterprises や organizations の member になり得ます。所属先ごとに enterprise、organization、repository の異なる roles を持つことがあります。

さらに、ユーザーは異なる teams に所属し、チームごとに enterprise、organization、repository の異なる roles を持つことがあります。

そして最終的に、repositories には特別な保護機構が存在することがあります。

権限

Enterprise Roles

• Enterprise owner: この role を持つ人は 管理者の管理、enterprise 内の organizations の管理、enterprise 設定の管理、組織横断のポリシーの強制 が可能です。ただし、organization owner に設定されているか、organization 所有の repository への直接アクセスが与えられていない限り、organization の設定やコンテンツにアクセスすることはできません。
• Enterprise members: あなたの enterprise が所有する organizations のメンバーは 自動的に enterprise のメンバー でもあります。

Organization Roles

組織内ではユーザーは異なる roles を持てます:

• Organization owners: Organization owners は 組織に対する完全な管理アクセス を持ちます。この role は制限すべきですが、組織内では少なくとも二人以上にしておくべきです。
• Organization members: 組織内の人々のための デフォルトの非管理者 role が organization member です。デフォルトでは、organization members は 複数の権限 を持っています。
• Billing managers: Billing managers は 組織の請求設定（支払い情報など）を管理できる ユーザーです。
• Security Managers: これは organization owners が組織内の任意のチームに割り当てることができる role です。適用されると、そのチームの全メンバーに 組織全体のセキュリティアラートと設定の管理権限、および組織内のすべてのリポジトリに対する読み取り権限 が与えられます。
• 組織に security team がある場合、security manager role を使ってチームメンバーに組織への最低限のアクセスを与えることができます。
• Github App managers: 組織が所有する GitHub Apps を 管理できるように追加のユーザーを許可するために、owner は GitHub App manager 権限を付与できます。
• Outside collaborators: Outside collaborator は 1つ以上の 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

in https://github.com/organizations/<org_name>/settings/member_privileges_ では、組織に所属しているだけでユーザーが持つ権限 を確認できます。

ここで設定される項目は、組織メンバーの以下の権限を示します:

• 組織内の全リポジトリに対して admin、writer、reader、または権限なし のいずれかになるか。
• メンバーが private、internal、public のリポジトリを作成できるか。
• リポジトリの fork が可能かどうか。
• Outside collaborators を招待できるかどうか。
• public または private のサイトを公開できるかどうか。
• 管理者がリポジトリに対して持つ権限。
• メンバーが新しい teams を作成できるかどうか。

Repository Roles

デフォルトで以下の repository roles が用意されています:

• Read: プロジェクトを閲覧したり議論したりしたい 非コード貢献者向けに推奨 されます
• Triage: 書き込みアクセスなしで issues や pull requests を能動的に管理する必要がある貢献者向けに推奨 されます
• Write: 積極的にプロジェクトへ push する貢献者向けに推奨 されます
• Maintain: 機密性や破壊的な操作へのアクセスなしにリポジトリを管理する必要があるプロジェクトマネージャ向けに推奨 されます
• Admin: セキュリティ管理やリポジトリの削除などの機密的・破壊的操作を含む プロジェクトへのフルアクセスが必要な人向けに推奨 されます

各 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 で 独自の roles を作成 することもできます。

Teams

https://github.com/orgs/<org_name>/teams/ で組織内に作成された teams の一覧 を確認できます。親チームの子チームを表示するには、各親チームにアクセスする必要がある点に注意してください。

Users

組織のユーザーは https://github.com/orgs/<org_name>/people. で 一覧表示 できます。

各ユーザーの情報から、そのユーザーが 所属している teams と アクセス権を持つ repos を確認できます。

Github Authentication

Github はアカウントに認証し、ユーザーに代わって操作を行うためのさまざまな方法を提供しています。

Web Access

github.com にアクセスして、username と password（および場合によっては 2FA）でログインできます。

SSH Keys

アカウントに1つまたは複数の public keys を設定すると、対応する private key があなたに代わって操作を行える ようになります。 https://github.com/settings/keys

GPG Keys

これらの keys でユーザーを偽装することは できません が、署名なしでコミットを送ると検出される可能性があるため、使用しない場合は注意が必要です。vigilant mode については vigilant mode here を参照してください。

Personal Access Tokens

personal access token を生成して アプリケーションにあなたのアカウントへのアクセスを与える ことができます。personal access token を作成するとき、user は token が持つ権限を指定する必要があります。 https://github.com/settings/tokens

Oauth Applications

Oauth applications はあなたの github 情報の一部にアクセスしたり、あなたを偽装してアクションを実行したりするための権限を要求することがあります。一般的な例はプラットフォーム上で見かける login with github button です。

• 自分の Oauth applications は https://github.com/settings/developers で 作成 できます
• あなたのアカウントにアクセス権を持つ Oauth applications 一覧 は https://github.com/settings/applications で確認できます
• Oauth Apps が要求できる scopes は https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps で確認できます
• 組織におけるサードパーティアプリのアクセスは https://github.com/organizations/<org_name>/settings/oauth_application_policy で確認できます

いくつかの セキュリティ推奨:

• OAuth App は常に 認証された GitHub ユーザーとして GitHub 全体で動作すべき（例：ユーザー通知の提供時）で、指定された scopes のみへのアクセスに留めるべきです。
• OAuth App は「Login with GitHub」を有効にすることで識別プロバイダーとして使えます。
• 単一のリポジトリだけを操作したい場合に OAuth App を作るべきではありません。 repo OAuth scope を与えると、OAuth Apps は認証されたユーザーのすべての repositories に対して動作できてしまいます。
• チームや会社向けのアプリとして OAuth App を作るべきではありません。 OAuth Apps は単一ユーザーとして認証されるため、ある人が会社用に OAuth App を作成して退職すると、他の人はその OAuth App にアクセスできなくなります。
• More in here.

Github Applications

Github applications は特定のリソースに対して あなたの github 情報へアクセスしたり、あなたを偽装して特定の操作を行ったり する権限を要求できます。Github Apps では、アプリがアクセスする repositories を指定する必要があります。

• GitHub App をインストールするには、organisation owner であるかリポジトリでの admin 権限が必要 です。
• GitHub App は personal account か organisation に接続 するべきです。
• 自分の Github application は https://github.com/settings/apps で作成できます
• あなたのアカウントにアクセス権を持つ Github applications 一覧 は https://github.com/settings/apps/authorizations で確認できます
• これらは Github Applications の API Endpoints です: https://docs.github.com/en/rest/overview/endpoints-available-for-github-app。App の権限次第でこれらの一部にアクセスできます
• 組織にインストールされているアプリは https://github.com/organizations/<org_name>/settings/installations で確認できます

いくつかのセキュリティ推奨:

• GitHub App は ユーザーから独立してアクションを行うべき（ただし app が user-to-server トークンを使用している場合を除く）。user-to-server access tokens をより安全に保つために、8時間で期限切れになる access token と、新しい access token に交換できる refresh token を使うことができます。詳細は “Refreshing user-to-server access tokens.” を参照してください。
• GitHub App が 特定の repositories と統合されていることを確認してください。
• GitHub App は personal account か organisation に接続 するべきです。
• GitHub App にユーザーができることをすべて期待しないでください。
• 単に “Login with GitHub” サービスが必要なだけなら GitHub App を使わないでください。 ただし、GitHub App は user identification flow を使ってユーザーをログインさせつつ他の操作も行えます。
• ユーザーと同じ権限で動作させたいだけなら GitHub App を作るべきではありません。
• GitHub Actions とアプリを組み合わせて workflow ファイルを変更したい場合、workflow scope を含む OAuth トークンでユーザーを代表して認証する必要があります。ユーザーはワークフローファイルを含むリポジトリに対して admin または write 権限を持っている必要があります。詳細は “Understanding scopes for OAuth apps.” を参照してください。
• More in here.

Github Actions

これは Github に認証するための方法ではありません が、悪意ある Github Action が github へ不正アクセスを得る 可能性があり、Action に与えられた privileges に応じてさまざまな 攻撃 が実行される可能性があります。詳細は以下を参照してください。

Git Actions

Git actions は イベントが発生したときにコードの実行を自動化する 仕組みです。通常、実行されるコードは リポジトリのコードに関連する処理（例：docker コンテナのビルドや PR に秘匿情報が含まれていないかのチェック）です。

Configuration

https://github.com/organizations/<org_name>/settings/actions では、組織の github actions の設定 を確認できます。

github actions の使用を完全に禁止したり、すべての github actions を許可 したり、特定の actions のみを許可したりできます。

また、誰が Github Action を実行する際に承認が必要か、および Github Action 実行時の GITHUB_TOKEN の権限 を設定することも可能です。

Git Secrets

Github Action は通常、github やサードパーティアプリと連携するための何らかの secret を必要とします。これらをリポジトリ内で平文保存するのを 避けるために、github はそれらを Secrets として保存することを許可しています。

これらの secrets は リポジトリ単位または組織全体で設定 できます。Action が secret にアクセスできるようにするには、次のように宣言する必要があります:

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"

Warning

Secrets それらを宣言している Github Actions からのみアクセスできます。

一度 repo や organization に設定されると、github のユーザーはそれらに再びアクセスすることはできません。ただし、変更することはできます。

したがって、github secrets を盗む唯一の方法は、Github Action を実行しているマシンにアクセスできることです（その場合、Action に宣言された secrets のみアクセスできます）。

Git Environments

Github は environments を作成して secrets を保存できます。次に、次のようにして github action に environment 内の secrets へのアクセスを許可できます：

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.
Additionally, environment protections include:

• Required reviewers: gate jobs targeting the environment until approved. Enable Prevent self-review to enforce a proper four‑eyes principle on the approval itself.
• Deployment branches and tags: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the “Protected branches only” option applies to classic branch protections and may not behave as expected if using rulesets.
• Wait timer: delay deployments for a configurable period.

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 approval of the most recent reviewable push. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
• 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 need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., “@bot-name skip”).
• 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.

Tag Protections

Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:

1. On the tag protection rule, enable Require deployments to succeed and require a successful deployment to a protected environment (e.g., prod).
2. In the target environment, restrict Deployment branches and tags to the release branch (e.g., main) and optionally configure Required reviewers with Prevent self-review.
3. On the release branch, configure branch protections to Require a pull request, set approvals ≥ 1, and enable both Dismiss approvals when new commits are pushed and Require approval of the most recent reviewable push.

This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.

References

• 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
• https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions
• https://securitylab.github.com/resources/github-actions-untrusted-input/
• https://docs.github.com/en/rest/checks/runs
• https://docs.github.com/en/apps
• GitHub Actions: A Cloudy Day for Security - Part 1

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。