Basic Github Information

AWSハッキングをゼロからヒーローまで学ぶ htARTE (HackTricks AWS Red Team Expert)！

HackTricksをサポートする他の方法:

HackTricksにあなたの会社を広告したい、またはHackTricksをPDFでダウンロードしたい場合は、サブスクリプションプランをチェックしてください！
公式PEASS & HackTricksグッズを入手する
The PEASS Familyを発見する、私たちの独占的なNFTsのコレクション
💬 Discordグループに参加するか、テレグラムグループに参加するか、Twitter 🐦 @carlospolopmをフォローする。
HackTricksとHackTricks CloudのgithubリポジトリにPRを提出して、あなたのハッキングのコツを共有する。

基本構造

大きな会社の基本的なgithub環境構造は、複数の組織を所有するエンタープライズを所有し、それぞれが複数のリポジトリと複数のチームを含むことがあります。小規模な会社は、1つの組織のみを所有し、エンタープライズは所有していない場合があります。

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

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

最後に、リポジトリには特別な保護メカニズムがあるかもしれません。

権限

エンタープライズの役割

エンタープライズの所有者: この役割を持つ人々は、管理者を管理し、エンタープライズ内の組織を管理し、エンタープライズの設定を管理し、組織全体にポリシーを適用することができます。ただし、組織の所有者になるか、組織が所有するリポジトリへの直接アクセスを与えられない限り、組織の設定やコンテンツにアクセスすることはできません。
エンタープライズのメンバー: あなたのエンタープライズが所有する組織のメンバーも、自動的にエンタープライズのメンバーです。

組織の役割

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

組織の所有者: 組織の所有者は、組織への完全な管理アクセスを持っています。この役割は限定されるべきですが、組織内では少なくとも2人以上にするべきです。
組織のメンバー: 組織内の人々のデフォルトの非管理的な役割は組織のメンバーです。デフォルトでは、組織のメンバーは多くの権限を持っています。
請求管理者: 請求管理者は、組織の請求設定を管理できるユーザーです。例えば、支払い情報などです。
セキュリティマネージャー: 組織の所有者が組織内の任意のチームに割り当てることができる役割です。適用されると、チームの全メンバーに、組織全体のセキュリティアラートと設定を管理する権限、および組織内のすべてのリポジトリに対する読み取り権限を与えます。
組織にセキュリティチームがある場合、セキュリティマネージャーの役割を使用して、チームのメンバーに組織への最小限のアクセスを与えることができます。
Githubアプリ管理者: 組織が所有する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は、アカウントに認証し、あなたに代わってアクションを実行するためのさまざまな方法を提供します。

Webアクセス

github.comにアクセスして、ユーザー名とパスワード（および潜在的に2FA）を使用してログインできます。

SSH Keys

SSHキーを設定することで、関連する秘密キーがあなたに代わって行動を実行できます。 https://github.com/settings/keys

GPG Keys

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

Personal Access Tokens

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

Oauth Applications

Oauthアプリケーションは、あなたのGitHub情報へのアクセスや、あなたになりすまして行動を実行するための権限を要求することがあります。この機能の一般的な例は、一部のプラットフォームで見つけることができるGitHubでログインするボタンです。

自分の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へ
組織のアプリケーションのサードパーティアクセスを表示するには_https://github.com/organizations/<org_name>/settings/oauth_application_policy_へ

セキュリティの推奨事項:

OAuthアプリは、GitHub全体で常に認証されたGitHubユーザーとして行動するべきです（例えば、ユーザー通知を提供する場合）し、指定されたスコープへのアクセスのみを持つべきです。
OAuthアプリは、認証されたユーザーのためにGitHubでのログインを有効にすることで、アイデンティティプロバイダとして使用できます。
単一のリポジトリに対して行動するアプリケーションを作りたい場合は、OAuthアプリを作成しないでください。repo OAuthスコープを使用すると、OAuthアプリは認証されたユーザーのすべてのリポジトリに対して行動できます。
チームや会社のためのアプリケーションとしてOAuthアプリを作成しないでください。OAuthアプリは単一のユーザーとして認証するため、ある人が会社の使用のためにOAuthアプリを作成した場合、その人が会社を去ったら他の誰もそれにアクセスできなくなります。
詳細はこちら。

Github Applications

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

GitHubアプリをインストールするには、組織のオーナーであるか、リポジトリで管理権限を持っている必要があります。
GitHubアプリは個人アカウントまたは組織に接続するべきです。
自分のGitHubアプリケーションを作成するにはhttps://github.com/settings/appsへ
アカウントにアクセスできるGitHubアプリケーションをすべて表示するにはhttps://github.com/settings/apps/authorizationsへ
これらはGitHubアプリケーションのAPIエンドポイントですhttps://docs.github.com/en/rest/overview/endpoints-available-for-github-app。アプリの権限に応じて、いくつかのエンドポイントにアクセスできます
組織のインストール済みアプリを表示するには_https://github.com/organizations/<org_name>/settings/installations_へ

セキュリティの推奨事項:

GitHubアプリは、user-to-serverトークンを使用していない限り、ユーザーから独立して行動するべきです。ユーザーからサーバーへのアクセストークンのセキュリティを高めるために、8時間後に期限切れになるアクセストークンと、新しいアクセストークンと交換できるリフレッシュトークンを使用できます。詳細については、"Refreshing user-to-server access tokens"を参照してください。
GitHubアプリは特定のリポジトリと統合するべきです。
GitHubアプリは個人アカウントまたは組織に接続するべきです。
GitHubアプリがユーザーができるすべてを知っていて実行することを期待しないでください。
GitHubでのログインサービスのみが必要な場合は、GitHubアプリを使用しないでください。ただし、GitHubアプリはuser identification flowを使用してユーザーをログインさせる_とともに_他のことも行うことができます。
GitHubユーザーとして行動し、そのユーザーができるすべてを行いたいだけの場合は、GitHubアプリを作成しないでください。
GitHub Actionsを使用してワークフローファイルを変更したい場合は、workflowスコープを含むOAuthトークンを使用してユーザーに代わって認証する必要があります。ユーザーは、ワークフローファイルが含まれているリポジトリに対して管理または書き込み権限を持っている必要があります。詳細については、"Understanding scopes for OAuth apps"を参照してください。
詳細はこちら。

Github Actions

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

Git Actions

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

設定

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やサードパーティのアプリケーションとやり取りするために何らかのシークレットが必要です。リポジトリ内で平文でそれらを置くことを避けるために、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"

シークレットは、それらが宣言された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以外のインフラストラクチャで実行されているGithub Actions**を見つける方法は、Github Actionの設定yamlで`runs-on: self-hosted`を検索することです。

**異なる組織のセルフホストボックス内で組織のGithub Actionを実行することはできません**。ランナーがどこに属しているかを知るために、設定時に**ユニークなトークンがランナーに対して生成される**からです。

カスタム**Github RunnerがAWSやGCP**内のマシンに設定されている場合、たとえば、Actionは**メタデータエンドポイントにアクセス**して、マシンが実行されている**サービスアカウントのトークンを盗む**可能性があります。

### Git Action Compromise

すべてのアクション（または悪意のあるアクション）が許可されている場合、ユーザーは**悪意のあるGithubアクション**を使用して、実行されている**コンテナ**を**危険にさらす**ことができます。

<div data-gb-custom-block data-tag="hint" data-style='danger'>

**悪意のあるGithubアクション**の実行は攻撃者によって以下のように**悪用**される可能性があります：

* アクションがアクセスできる**すべてのシークレットを盗む**
* アクションが**サードパーティのインフラストラクチャ**内で実行されている場合、**横方向に移動**する（おそらくメタデータサービスを介してアクセス可能なSAトークンを使用してマシンを実行する）
* **ワークフロー**によって使用される**トークンを悪用**して、アクションが実行されているリポジトリの**コードを盗む**、または**それを変更する**。

</div>

## Branch Protections

ブランチ保護は、ユーザーにリポジトリの完全なコントロールを与えないように設計されています。目的は、コードを特定のブランチ内に書き込む前に、いくつかの保護方法を設置することです。

リポジトリの**ブランチ保護**は_https://github.com/\<orgname>/\<reponame>/settings/branches_で見つけることができます。

<div data-gb-custom-block data-tag="hint" data-style='info'>

**組織レベルでブランチ保護を設定することはできません**。したがって、すべてのリポジトリで宣言する必要があります。

</div>

ブランチにはさまざまな保護が適用される可能性があります（masterなど）：

* **マージする前にPRが必要**です（つまり、直接ブランチ上にコードをマージすることはできません）。これが選択されると、他のさまざまな保護が適用される可能性があります：
* **承認の数を要求する**。通常、1人または2人以上の人がPRを承認する必要があります。これにより、単一のユーザーが直接コードをマージすることができなくなります。
* **新しいコミットがプッシュされたときに承認を無視する**。そうでない場合、ユーザーは正当なコードを承認し、その後、悪意のあるコードを追加してマージする可能性があります。
* **コードオーナーからのレビューを要求する**。リポジトリの少なくとも1人のコードオーナーがPRを承認する必要があります（したがって、「ランダム」なユーザーはそれを承認できません）
* **プルリクエストレビューを解除できる人を制限する**。プルリクエストレビューを解除できる人またはチームを指定できます。
* **指定されたアクターがプルリクエスト要件をバイパスできるようにする**。これらのユーザーは、以前の制限をバイパスできるようになります。
* **マージする前にステータスチェックが合格することを要求する**。コミットをマージする前に合格する必要があるいくつかのチェック（例えば、明文のシークレットがないことを確認するgithubアクション）。
* **マージする前に会話の解決を要求する**。コードに関するすべてのコメントが解決されるまで、PRをマージすることはできません。
* **署名されたコミットを要求する**。コミットは署名される必要があります。
* **線形履歴を要求する**。マッチングブランチにマージコミットをプッシュすることを防ぎます。
* **管理者を含む**。これが設定されていない場合、管理者は制限をバイパスできます。
* **マッチングブランチにプッシュできる人を制限する**。PRを送信できる人を制限します。

<div data-gb-custom-block data-tag="hint" data-style='info'>

ご覧のとおり、ユーザーのいくつかの資格情報を取得したとしても、たとえばCI/CDパイプラインを危険にさらすために**masterにコードをプッシュすることを避けるために、リポジトリが保護されている**可能性があります。

</div>

## 参考文献

* [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/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)

<details>

<summary><strong>AWSハッキングをゼロからヒーローまで学ぶには</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>をご覧ください！</strong></summary>

HackTricksをサポートする他の方法：

* **HackTricksに広告を掲載したい**、または**HackTricksをPDFでダウンロードしたい**場合は、[**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)をチェックしてください！
* [**公式PEASS & HackTricksグッズ**](https://peass.creator-spring.com)を手に入れましょう
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見してください。私たちの独占的な[**NFT**](https://opensea.io/collection/the-peass-family)コレクションです。
* 💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)や[**テレグラムグループ**](https://t.me/peass)に**参加する**か、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)で**フォロー**してください。
* **HackTricks**の[**githubリポジトリ**](https://github.com/carlospolop/hacktricks)や[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)にPRを提出して、あなたのハッキングのコツを共有してください。

</details>

前へGh Actions - Context Script Injections 次へGitea Security

最終更新 4 か月前