Github Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
(From here) 高レベルでは、GitHubは開発者がコードを保存・管理し、コードの変更を追跡・制御するのを助けるウェブサイトおよびクラウドベースのサービスです。
Githubリポジトリは公開、非公開、内部として設定できます。
非公開は、組織の人だけがアクセスできることを意味します。
内部は、企業の人だけがアクセスできることを意味します（企業は複数の組織を持つことがあります）。
公開は、全インターネットがアクセスできることを意味します。
ターゲットにしたいユーザー、リポジトリ、または組織を知っている場合、github dorksを使用して敏感な情報を見つけたり、各リポジトリでの敏感な情報漏洩を検索できます。
Githubは、ユーザー、リポジトリ、または組織をスコープとして指定して何かを検索することを許可します。したがって、敏感な情報の近くに表示される文字列のリストを使用して、ターゲット内の潜在的な敏感情報を簡単に検索できます。
ツール（各ツールにはそのdorkのリストが含まれています）：
Github dorksは、github検索オプションを使用して漏洩を検索するためにも使用されることに注意してください。このセクションは、各リポジトリをダウンロードし、その中で敏感な情報を検索するツールに専念しています（特定のコミットの深さをチェックすることも含まれます）。
ツール（各ツールにはその正規表現のリストが含まれています）：
リポジトリで漏洩を探すときにgit log -pのようなコマンドを実行する場合、他のコミットを含む他のブランチが存在する可能性があることを忘れないでください！
プルリクエストを悪用してリポジトリを妥協することが可能です。リポジトリが脆弱かどうかを知るには、主にGithub Actionsのyaml設定を読む必要があります。詳細は以下にあります。
削除されたり内部のものであっても、githubリポジトリのフォークから敏感なデータを取得できる可能性があります。ここで確認してください：
Accessible Deleted Data in Github組織のメンバーに割り当てられるいくつかのデフォルトの権限があります。これらは、ページhttps://github.com/organizations/<org_name>/settings/member_privilegesまたはOrganizations APIから制御できます。
基本的な権限: メンバーは、組織のリポジトリに対してNone/Read/write/Adminの権限を持ちます。推奨はNoneまたはReadです。
リポジトリのフォーク: 必要でない場合、メンバーが組織のリポジトリをフォークすることを許可しない方が良いです。
ページの作成: 必要でない場合、メンバーが組織のリポジトリからページを公開することを許可しない方が良いです。必要な場合は、公開または非公開のページを作成することを許可できます。
統合アクセス要求: これを有効にすると、外部のコラボレーターがこの組織とそのリソースにアクセスするためのGitHubまたはOAuthアプリへのアクセスを要求できるようになります。通常は必要ですが、必要でない場合は無効にする方が良いです。
この情報をAPIの応答で見つけられませんでした。見つけたら共有してください。
リポジトリの可視性の変更: 有効にすると、リポジトリの管理者権限を持つメンバーが可視性を変更できるようになります。無効にすると、組織のオーナーのみがリポジトリの可視性を変更できます。人々に公開にすることを望まない場合は、これを無効にしてください。
この情報をAPIの応答で見つけられませんでした。見つけたら共有してください。
リポジトリの削除と転送: 有効にすると、リポジトリの管理者権限を持つメンバーが公開および非公開のリポジトリを削除または転送できるようになります。
この情報をAPIの応答で見つけられませんでした。見つけたら共有してください。
メンバーがチームを作成することを許可: 有効にすると、組織のメンバーは新しいチームを作成できるようになります。無効にすると、組織のオーナーのみが新しいチームを作成できます。これを無効にしておく方が良いです。
この情報をAPIの応答で見つけられませんでした。見つけたら共有してください。
このページで他の設定も可能ですが、前述のものが最もセキュリティに関連しています。
いくつかのセキュリティ関連の設定は、ページhttps://github.com/organizations/<org_name>/settings/actionsから構成できます。
これらの設定は、各リポジトリでも独立して設定できることに注意してください。
Github actionsポリシー: どのリポジトリがワークフローを実行でき、どのワークフローが許可されるべきかを指定できます。許可されるリポジトリを指定することを推奨し、すべてのアクションが実行されることを許可しない方が良いです。
外部コラボレーターからのフォークプルリクエストワークフロー: すべての外部コラボレーターに対して承認を要求することを推奨します。
この情報を持つAPIは見つけられませんでした。見つけたら共有してください。
フォークプルリクエストからのワークフローの実行: プルリクエストからのワークフローを実行することは強く推奨されません。フォーク元のメンテナーは、ソースリポジトリに対して読み取り権限を持つトークンを使用する能力を与えられます。
この情報を持つAPIは見つけられませんでした。見つけたら共有してください。
ワークフローの権限: リポジトリの読み取り権限のみを付与することを強く推奨します。GITHUB_TOKENを使用したワークフローの悪用を避けるために、書き込みおよびプルリクエストの作成/承認権限を与えることは推奨されません。
この情報にアクセスするためのAPIエンドポイントを知っている場合は教えてください！
サードパーティアプリケーションアクセスポリシー: すべてのアプリケーションへのアクセスを制限し、必要なもののみを許可することを推奨します（レビュー後）。
インストールされたGitHubアプリ: 必要なもののみを許可することを推奨します（レビュー後）。
このシナリオでは、githubアカウントへのアクセスを取得したと仮定します。
もしあなたが何らかの方法で組織内のユーザーの資格情報を持っている場合、ただログインして、どの企業および組織の役割を持っているかを確認できます。生のメンバーであれば、生のメンバーが持つ権限、どのグループに属しているか、どのリポジトリに対してどの権限を持っているか、およびリポジトリがどのように保護されているかを確認できます。
2FAが使用されている可能性があることに注意してください。したがって、そのチェックを通過できる場合にのみ、この情報にアクセスできます。
user_sessionクッキーを盗むことに成功した場合（現在SameSite: Laxで設定されています）、資格情報や2FAなしでユーザーを完全に偽装できます。
役立つ場合に備えて、ブランチ保護のバイパスに関するセクションを確認してください。
Githubは、ユーザーがSSHキーを設定することを許可しており、これは彼らの代わりにコードをデプロイするための認証方法として使用されます（2FAは適用されません）。
このキーを使用して、ユーザーがいくつかの権限を持つリポジトリで変更を行うことができますが、github APIにアクセスして環境を列挙するために使用することはできません。ただし、ローカル設定を列挙して、アクセスできるリポジトリやユーザーに関する情報を取得できます。
ユーザーが自分のGitHubユーザー名としてユーザー名を設定している場合、https://github.com/<github_username>.keys で彼のアカウントに設定された 公開鍵 にアクセスできます。これを確認して、見つけた秘密鍵が使用できるかどうかを確認できます。
SSH鍵 は デプロイ鍵 としてリポジトリに設定することもできます。この鍵にアクセスできる人は、リポジトリからプロジェクトを起動する ことができます。通常、異なるデプロイ鍵を持つサーバーでは、ローカルファイル ~/.ssh/config が関連する鍵に関する情報を提供します。
こちら で説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。
現在のユーザーが鍵を持っているかどうかをローカルで確認してください:
ユーザートークンについての基本情報はここをチェックしてくださいの紹介。
ユーザートークンは、HTTPS経由のGitのパスワードの代わりに使用できるか、基本認証を介してAPIに認証するために使用できます。付与された権限に応じて、さまざまなアクションを実行できる場合があります。
ユーザートークンは次のようになります: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Github Oauthアプリケーションについての基本情報はここをチェックしてくださいの紹介。
攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある悪意のあるOauthアプリケーションを作成して、特権データ/アクションにアクセスするかもしれません。
これらは、Oauthアプリケーションが要求できるスコープです。受け入れる前に、要求されたスコープを常に確認する必要があります。
さらに、基本情報で説明されているように、組織はサードパーティアプリケーションに対して情報/リポジトリ/アクションへのアクセスを与えたり拒否したりできます。
Githubアプリケーションについての基本情報はここをチェックしてくださいの紹介。
攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある悪意のあるGithubアプリケーションを作成して、特権データ/アクションにアクセスするかもしれません。
さらに、基本情報で説明されているように、組織はサードパーティアプリケーションに対して情報/リポジトリ/アクションへのアクセスを与えたり拒否したりできます。
Github Actionを妨害し悪用するためのいくつかの技術があります。ここで確認してください：
Abusing Github Actions承認の数を要求する: 複数のアカウントを妨害した場合、他のアカウントからPRを受け入れることができます。PRを作成したアカウントしか持っていない場合、自分のPRを受け入れることはできません。しかし、リポジトリ内のGithub Action環境にアクセスできる場合、GITHUB_TOKENを使用してPRを承認し、この方法で1つの承認を得ることができるかもしれません。
この点とCode Owners制限についての注意: 通常、ユーザーは自分のPRを承認できませんが、もしできる場合は、それを悪用して自分のPRを受け入れることができます。
新しいコミットがプッシュされたときに承認を無効にする: これが設定されていない場合、正当なコードを提出し、誰かがそれを承認するのを待ってから、悪意のあるコードを追加して保護されたブランチにマージできます。
Code Ownersからのレビューを要求する: これが有効になっていて、あなたがCode Ownerであれば、Github ActionがあなたのPRを作成し、その後自分で承認することができます。
CODEOWNERファイルが誤って設定されている場合、Githubは文句を言いませんが、それを使用しません。したがって、誤って設定されている場合は、Code Ownersの保護が適用されません。
指定されたアクターがプルリクエストの要件をバイパスできるようにする: あなたがこれらのアクターの1人であれば、プルリクエストの保護をバイパスできます。
管理者を含める: これが設定されていない場合、リポジトリの管理者であれば、このブランチの保護をバイパスできます。
PRハイジャック: あなたは他の誰かのPRを変更し、悪意のあるコードを追加し、結果として得られたPRを自分で承認してすべてをマージできるかもしれません。
ブランチ保護の削除: あなたがリポジトリの管理者であれば、保護を無効にし、PRをマージして保護を再設定できます。
プッシュ保護のバイパス: リポジトリが特定のユーザーのみがブランチにプッシュ（コードをマージ）できるようにしている場合（ブランチ保護がすべてのブランチを保護している可能性がありますが、ワイルドカード*を指定しています）。
あなたがリポジトリに対して書き込みアクセスを持っているが、ブランチ保護のためにコードをプッシュすることが許可されていない場合、それでも新しいブランチを作成し、その中でコードがプッシュされたときにトリガーされるGithub Actionを作成できます。ブランチ保護はブランチが作成されるまで保護しないため、この最初のコードプッシュはGithub Actionを実行します。
Github環境についての基本情報はここをチェックしてください。
環境にすべてのブランチからアクセスできる場合、それは保護されていないため、環境内のシークレットに簡単にアクセスできます。すべてのブランチが保護されているリポジトリを見つけることがあることに注意してください（その名前を指定するか、*を使用して）。そのシナリオでは、コードをプッシュできるブランチを見つけ、新しいGithub Actionを作成することでシークレットを抽出できます（または1つを修正することができます）。
すべてのブランチが保護されている場合（ワイルドカード*を介して）、ブランチにコードをプッシュできるのは誰かが指定されているエッジケースに遭遇することがあります（これをブランチ保護で指定できます）が、あなたのユーザーは許可されていません。それでもカスタムGithub Actionを実行できます。なぜなら、ブランチを作成し、その上でプッシュトリガーを使用できるからです。ブランチ保護は新しいブランチへのプッシュを許可するため、Github Actionがトリガーされます。
注意してください。ブランチの作成後、ブランチ保護が新しいブランチに適用され、それを変更することはできませんが、その時点で既に秘密をダンプしているでしょう。
ユーザートークンを生成
シークレットからgithubトークンを盗む
ワークフローの結果とブランチの削除
全ての組織に対してより多くの権限を付与
情報を外部に流出させるためのウェブフックを作成
外部コラボレーターを招待
SIEMによって使用されるウェブフックを削除
バックドアを持つGithub Actionを作成/変更
シークレット値の変更を通じてコマンドインジェクションに脆弱なGithub Actionを見つける
Githubでは、フォークからリポジトリにPRを作成することが可能です。PRが受け入れられなくても、元のリポジトリ内にフォーク版のコードのためのコミットIDが作成されます。したがって、攻撃者はリポジトリの所有者によって作成されていない、見た目上正当なリポジトリから特定のコミットを使用するようにピン留めすることができるかもしれません。
For more info check https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
