Basic Github Information
Last updated
Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
大規模な企業の基本的な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.comにアクセスすると、ユーザー名とパスワード（および2FAの可能性）を使用してログインできます。
1つまたは複数の公開鍵でアカウントを構成でき、関連する秘密鍵があなたの代わりにアクションを実行できるようにします。https://github.com/settings/keys
これらのキーでユーザーを偽装することはできませんが、使用しない場合、署名なしでコミットを送信することで発見される可能性があります。 vigilant mode hereで詳細を学んでください。
アプリケーションにアカウントへのアクセスを与えるために個人アクセストークンを生成できます。個人アクセストークンを作成する際、ユーザーはトークンが持つ権限を指定する必要があります。https://github.com/settings/tokens
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アプリは単一のユーザーとして認証されるため、1人が会社のためにOAuthアプリを作成し、その後会社を離れると、他の誰もそれにアクセスできなくなります。
詳細は こちらで。
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アプリは、ユーザーとは独立してアクションを実行するべきです（アプリがユーザーからサーバーへのトークンを使用している場合を除く）。ユーザーからサーバーへのアクセストークンをより安全に保つために、8時間後に期限切れになるアクセストークンと、新しいアクセストークンと交換できるリフレッシュトークンを使用できます。詳細については、「ユーザーからサーバーへのアクセストークンの更新」を参照してください。
GitHubアプリが特定のリポジトリと統合されていることを確認してください。
GitHubアプリは個人アカウントまたは組織に接続する必要があります。
GitHubアプリがユーザーができるすべてのことを知って行動することを期待しないでください。
「GitHubでログイン」サービスが必要なだけの場合は、GitHubアプリを使用しないでください。ただし、GitHubアプリは、ユーザーをログインさせるためにユーザー識別フローを使用して、ユーザーをログインさせることができます。
GitHubユーザーとして行動し、そのユーザーができるすべてのことを行いたいだけの場合は、GitHubアプリを構築しないでください。
GitHub Actionsを使用してアプリを使用し、ワークフローファイルを変更したい場合は、workflowスコープを含むOAuthトークンを使用してユーザーの代わりに認証する必要があります。ユーザーは、ワークフローファイルを含むリポジトリに対して管理者または書き込み権限を持っている必要があります。詳細については、「OAuthアプリのスコープの理解」を参照してください。
詳細は こちらで。
これはGithubで認証する方法ではありませんが、悪意のあるGithub ActionがGithubに不正アクセスする可能性があり、与えられた権限に応じて、いくつかの異なる攻撃が行われる可能性があります。詳細については以下を参照してください。
Gitアクションは、イベントが発生したときにコードの実行を自動化することを可能にします。通常、実行されるコードはリポジトリのコードに関連している（おそらくDockerコンテナをビルドするか、PRに秘密が含まれていないかを確認するなど）。
https://github.com/organizations/<org_name>/settings/actions で、組織のGithubアクションの設定を確認できます。
Githubアクションの使用を完全に禁止することも、すべてのGithubアクションを許可することも、特定のアクションのみを許可することもできます。
また、Github Actionを実行するために承認が必要な人や、Github Actionが実行されるときのGITHUB_TOKENの権限を設定することもできます。
Github Actionは通常、Githubやサードパーティアプリケーションと対話するために何らかの秘密を必要とします。それらをリポジトリに平文で置かないようにするために、GithubはそれらをSecretsとして配置することを許可します。
これらの秘密は、リポジトリまたは組織全体のために設定できます。その後、**Actionが秘密にアクセスできるようにするために、次のように宣言する必要があります：
Secrets は、それらが宣言されているGithub Actionsからのみアクセス可能です。
リポジトリまたは組織に設定されると、githubのユーザーは再度アクセスできなくなります。彼らはただ変更することができるだけです。
したがって、githubの秘密を盗む唯一の方法は、Github Actionを実行しているマシンにアクセスできることです（そのシナリオでは、Actionのために宣言された秘密にのみアクセスできます）。
Githubは、秘密を保存できる環境を作成することを許可します。次に、環境内の秘密に対するアクセスをgithub actionに与えることができます。
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.
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.
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 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にコードをプッシュすることを避けることができる.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
