Basic Github Information

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

HackTricksをサポートする

• サブスクリプションプランを確認してください！

• 参加する 💬 DiscordグループまたはTelegramグループに、またはTwitter 🐦 @hacktricks_liveをフォローしてください。

• ハッキングのトリックを共有するには、 HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出してください。

基本構造

大規模な企業の基本的なGithub環境構造は、エンタープライズを所有し、そのエンタープライズがいくつかの組織を所有し、それぞれがいくつかのリポジトリといくつかのチームを含むことです。小規模な企業は、1つの組織のみを所有し、エンタープライズを持たない場合があります。

ユーザーの観点から見ると、ユーザーは異なるエンタープライズや組織のメンバーであることができます。それらの中で、ユーザーは異なるエンタープライズ、組織、リポジトリの役割を持つことがあります。

さらに、ユーザーは異なるチームの一部であり、異なるエンタープライズ、組織、またはリポジトリの役割を持つことがあります。

最後に、リポジトリには特別な保護メカニズムがある場合があります。

権限

エンタープライズの役割

• エンタープライズオーナー：この役割を持つ人々は、管理者を管理し、エンタープライズ内の組織を管理し、エンタープライズ設定を管理し、組織全体にポリシーを強制することができます。ただし、彼らは組織の設定やコンテンツにアクセスすることはできません。組織のオーナーに任命されるか、組織所有のリポジトリへの直接アクセスが与えられない限り。

• エンタープライズメンバー：あなたのエンタープライズが所有する組織のメンバーは、自動的にエンタープライズのメンバーでもあります。

組織の役割

組織内でユーザーは異なる役割を持つことができます：

• 組織オーナー：組織オーナーは、組織に対して完全な管理アクセスを持っています。この役割は制限されるべきですが、組織内で2人以上の人に制限する必要があります。

• 組織メンバー：デフォルトの非管理者役割は組織メンバーです。デフォルトで、組織メンバーはいくつかの権限を持っています。

• 請求管理者：請求管理者は、組織の請求設定を管理できるユーザーです。たとえば、支払い情報など。

• セキュリティマネージャー：これは、組織オーナーが組織内の任意のチームに割り当てることができる役割です。適用されると、チームのすべてのメンバーに組織全体のセキュリティアラートと設定を管理する権限、および組織内のすべてのリポジトリに対する読み取り権限が与えられます。

• 組織にセキュリティチームがある場合、セキュリティマネージャーの役割を使用して、チームのメンバーに組織に必要な最小限のアクセスを与えることができます。

• Githubアプリ管理者：組織が所有するGitHubアプリを管理するために追加のユーザーに権限を与えることができます。

• 外部コラボレーター：外部コラボレーターは、1つ以上の組織リポジトリにアクセスできるが、組織の明示的なメンバーではない人です。

これらの役割の権限をこの表で比較できます：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にアクセスすると、ユーザー名とパスワード（および2FAが必要な場合もあります）を使用してログインできます。

SSHキー

関連するプライベートキーがあなたの代わりにアクションを実行できるように、1つまたは複数の公開鍵でアカウントを構成できます。 https://github.com/settings/keys

GPGキー

これらのキーでユーザーを偽装することはできませんが、使用しない場合、署名なしでコミットを送信することで発見される可能性があります。 ここで警戒モードについて学ぶ。

個人アクセストークン

アプリケーションにアカウントへのアクセスを与えるために個人アクセストークンを生成できます。個人アクセストークンを作成する際、ユーザーはトークンが持つ権限を指定する必要があります。https://github.com/settings/tokens

Oauthアプリケーション

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アプリが要求できるスコープを確認できます。
• https://github.com/organizations/<org_name>/settings/oauth_application_policy で、組織内のアプリケーションのサードパーティアクセスを確認できます。

いくつかのセキュリティ推奨事項：

• OAuthアプリは、常にGitHub全体で認証されたGitHubユーザーとして行動するべきです（たとえば、ユーザー通知を提供する場合）し、指定されたスコープへのアクセスのみを持つべきです。

• OAuthアプリは、認証されたユーザーのために「GitHubでログイン」を有効にすることで、アイデンティティプロバイダーとして使用できます。

• 単一のリポジトリでアクションを実行するアプリケーションを作成する場合は、OAuthアプリを構築しないでください。repo OAuthスコープを使用すると、OAuthアプリは認証されたユーザーのすべてのリポジトリに対してアクションを実行できます。

• チームや会社のためのアプリケーションとして機能するためにOAuthアプリを構築しないでください。OAuthアプリは単一のユーザーとして認証されるため、1人が会社のためにOAuthアプリを作成し、その後会社を離れると、他の誰もそれにアクセスできなくなります。

• 詳細は こちらで。

Githubアプリケーション

Githubアプリケーションは、あなたのGithub情報にアクセスしたり、あなたを偽装して特定のリソースに対して特定のアクションを実行したりするための権限を要求することがあります。Githubアプリでは、アプリがアクセスできるリポジトリを指定する必要があります。

• GitHubアプリをインストールするには、組織のオーナーまたはリポジトリの管理者権限を持っている必要があります。

• GitHubアプリは、個人アカウントまたは組織に接続する必要があります。

• 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アプリは、ユーザーとは独立してアクションを実行するべきです（アプリがユーザーからサーバーへのトークンを使用している場合を除く）。ユーザーからサーバーへのアクセスをより安全に保つために、8時間後に期限切れになるアクセストークンと、新しいアクセストークンと交換できるリフレッシュトークンを使用できます。詳細については、「ユーザーからサーバーへのアクセストークンの更新」を参照してください。
• GitHubアプリが特定のリポジトリと統合されていることを確認してください。

• GitHubアプリは、個人アカウントまたは組織に接続する必要があります。

• GitHubアプリがユーザーができるすべてのことを知って行うことを期待しないでください。

• 「GitHubでログイン」サービスが必要なだけの場合は、GitHubアプリを使用しないでください。ただし、GitHubアプリは、ユーザーをログインさせるためにユーザー識別フローを使用して、ユーザーをログインさせることができます。
• GitHubユーザーとしてのみ機能し、そのユーザーができるすべてのことを行いたい場合は、GitHubアプリを構築しないでください。

• GitHub Actionsでアプリを使用し、ワークフローファイルを変更したい場合は、workflowスコープを含むOAuthトークンを使用してユーザーの代わりに認証する必要があります。ユーザーは、ワークフローファイルを含むリポジトリに対して管理者または書き込み権限を持っている必要があります。詳細については、「OAuthアプリのスコープの理解」を参照してください。
• 詳細は こちらで。

Github Actions

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

Gitアクション

Gitアクションは、イベントが発生したときにコードの実行を自動化することを可能にします。通常、実行されるコードはリポジトリのコードに関連している（おそらくDockerコンテナをビルドするか、PRに秘密が含まれていないかを確認するなど）。

設定

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やサードパーティアプリケーションと対話するために何らかの秘密を必要とします。それらをリポジトリに平文で置かないようにするために、GithubはそれらをSecrets**として配置することを許可します。

これらの秘密は、リポジトリまたは組織全体のために設定できます。その後、Actionが秘密にアクセスできるようにするために、次のように宣言する必要があります：

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"

Secrets は、それらが宣言されているGithub Actionsからのみアクセス可能です。

リポジトリまたは組織で設定されると、githubのユーザーは再度それらにアクセスできなくなります。彼らはそれらを変更することしかできません。

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

Git Environments

Githubは、環境を作成して秘密を保存することを許可します。次に、環境内の秘密に対してgithub actionにアクセスを与えることができます。

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

You can configure an environment to be アクセス by すべてのブランチ (default), 保護された branches only or 指定 which branches can access it. It can also set a 必要なレビューの数 before 実行 an アクション using an 環境 or 待機 some 時間 before allowing deployments to proceed.

Git Action Runner

A Github Action can be 実行される inside the github environment or can be executed in a サードパーティのインフラストラクチャ configured by the user.

Several organizations will allow to run Github Actions in a サードパーティのインフラストラクチャ as it use to be 安価.

You can リスト 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 異なる組織の self hosted box inside a Github Action of an organization because ランナーのために一意のトークンが生成される 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 メタデータエンドポイントにアクセスできる and サービスアカウントのトークンを盗む 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 悪意のある and will 侵害する the コンテナ where it's being executed.

A 悪意のあるGithub Action run could be 悪用される by the attacker to:

• すべてのシークレットを盗む the Action has access to

• 横移動する if the Action is executed inside a サードパーティのインフラストラクチャ where the SA token used to run the machine can be accessed (probably via the metadata service)

• トークンを悪用する used by the ワークフロー to リポジトリのコードを盗む where the Action is executed or さらには変更する.

Branch Protections

Branch protections are designed to リポジトリの完全な制御をユーザーに与えない. The goal is to いくつかの保護方法を設ける before being able to write code inside some branch.

The リポジトリのブランチ保護 can be found in https://github.com/<orgname>/<reponame>/settings/branches

It's 組織レベルでブランチ保護を設定することはできない. So all of them must be declared on each repo.

Different protections can be applied to a branch (like to master):

• You can マージする前にPRを要求する (so you cannot directly merge code over the branch). If this is select different other protections can be in place:

• 承認の数を要求する. 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.

• 新しいコミットがプッシュされたときに承認を取り消す. If not, a user may approve legit code and then the user could add malicious code and merge it.

• コードオーナーからのレビューを要求する. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)

• プルリクエストレビューを取り消すことができる人を制限する. You can specify people or teams allowed to dismiss pull request reviews.

• 指定されたアクターがプルリクエスト要件をバイパスできるようにする. These users will be able to bypass previous restrictions.

• マージする前にステータスチェックが通過することを要求する. Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).

• マージする前に会話の解決を要求する. All comments on the code needs to be resolved before the PR can be merged.

• 署名されたコミットを要求する. The commits need to be signed.

• 線形履歴を要求する. Prevent merge commits from being pushed to matching branches.

• 管理者を含める. If this isn't set, admins can bypass the restrictions.

• 一致するブランチにプッシュできる人を制限する. Restrict who can send a PR.

As you can see, even if you managed to obtain some credentials of a user, リポジトリは保護されているため、例えばmasterにコードをプッシュすることを避けることができる.

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

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.