Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
このページでは、以下の内容を見つけることができます：
攻撃者がGithub Actionにアクセスできた場合の影響の概要
アクションにアクセスするための異なる方法：
アクションを作成するための権限を持つこと
プルリクエスト関連のトリガーを悪用すること
他の外部アクセス技術を悪用すること
すでに侵害されたリポジトリからのピボット
最後に、内部からアクションを悪用するためのポストエクスプロイテーション技術に関するセクション（前述の影響を引き起こす）
Github Actionsの基本情報を確認するについての紹介。
リポジトリ内でGitHub Actionsで任意のコードを実行できる場合、次のことができるかもしれません：
パイプラインにマウントされたシークレットを盗むことができ、パイプラインの権限を悪用して、AWSやGCPなどの外部プラットフォームに不正アクセスすることができます。
デプロイメントや他のアーティファクトを侵害することができます。
パイプラインが資産をデプロイまたは保存する場合、最終製品を変更し、サプライチェーン攻撃を可能にすることができます。
カスタムワーカーでコードを実行して、計算能力を悪用し、他のシステムにピボットすることができます。
GITHUB_TOKENに関連付けられた権限に応じて、リポジトリコードを上書きすることができます。
この「シークレット」（${{ secrets.GITHUB_TOKEN }}および${{ github.token }}から来る）は、管理者がこのオプションを有効にしたときに与えられます：
このトークンはGithubアプリケーションが使用するものと同じであり、同じエンドポイントにアクセスできます：https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps
Githubは、リポジトリ間のクロスリポジトリアクセスを許可するフローをリリースするべきです。これにより、リポジトリがGITHUB_TOKENを使用して他の内部リポジトリにアクセスできるようになります。
このトークンの可能な権限は次のリンクで確認できます：https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
トークンはジョブが完了した後に期限切れになることに注意してください。
これらのトークンは次のようになります：ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7
このトークンでできる興味深いこと：
いくつかの場面で、Github Actionsのenvsやシークレット内にgithubユーザートークンを見つけることができることに注意してください。これらのトークンは、リポジトリや組織に対してより多くの権限を与える可能性があります。
他のユーザーのリポジトリに与えられたGithubトークンの権限をアクションのログを確認することでチェックすることが可能です：
これはGithubアクションを危険にさらす最も簡単な方法です。このケースでは、組織内に新しいリポジトリを作成するアクセス権があるか、リポジトリに対する書き込み権限があることを前提としています。
このシナリオにいる場合は、ポストエクスプロイテーション技術を確認するだけです。
組織のメンバーが新しいリポジトリを作成でき、あなたがgithubアクションを実行できる場合、新しいリポジトリを作成して組織レベルで設定されたシークレットを盗むことができます。
既にGithubアクションが設定されているリポジトリで新しいブランチを作成できる場合、それを修正し、コンテンツをアップロードし、その後新しいブランチからそのアクションを実行することができます。この方法で、リポジトリおよび組織レベルのシークレットを外部に持ち出すことができます（ただし、どのように呼ばれているかを知っている必要があります）。
修正されたアクションを手動で実行可能にすることができます。PRが作成されたときやコードがプッシュされたとき（どれだけ目立ちたいかによります）：
攻撃者が別のリポジトリのGithub Actionを実行することを可能にする異なるトリガーがあります。これらのトリガー可能なアクションが不適切に構成されている場合、攻撃者はそれらを妥協させることができるかもしれません。
pull_requestワークフロートリガー**pull_requestは、プルリクエストが受信されるたびにワークフローを実行しますが、いくつかの例外があります：デフォルトでは、初めてコラボレーションする場合、いくつかのメンテイナーがワークフローの実行を承認**する必要があります：
デフォルトの制限は初めての貢献者に対して適用されるため、有効なバグ/タイプミスを修正することで貢献し、その後新しいpull_request権限を悪用するために他のPRを送信することができます。
これをテストしましたが、うまくいきませんでした：別のオプションは、プロジェクトに貢献した誰かの名前でアカウントを作成し、そのアカウントを削除することです。
さらに、デフォルトでは書き込み権限とシークレットアクセスをターゲットリポジトリに対して防止します。これはドキュメントに記載されています：
GITHUB_TOKENを除いて、シークレットはランナーに渡されません。ワークフローがフォークされたリポジトリからトリガーされるとき。GITHUB_TOKENはプルリクエストからのフォークされたリポジトリに対して読み取り専用権限を持っています。
攻撃者はGithub Actionの定義を変更して任意のことを実行し、任意のアクションを追加することができます。しかし、前述の制限のために、シークレットを盗んだりリポジトリを上書きしたりすることはできません。
はい、攻撃者がPRでトリガーされるgithub actionを変更した場合、彼のGithub Actionが使用され、元のリポジトリのものではなくなります！
攻撃者は実行されるコードも制御しているため、GITHUB_TOKENにシークレットや書き込み権限がなくても、攻撃者は例えば悪意のあるアーティファクトをアップロードすることができます。
pull_request_targetワークフロートリガー**pull_request_targetは、ターゲットリポジトリに対して書き込み権限とシークレットへのアクセス**を持ち（許可を求めません）、
ワークフロートリガー**pull_request_targetはベースコンテキスト**で実行され、PRによって与えられたものではありません（信頼できないコードを実行しないため）。pull_request_targetについての詳細はドキュメントを確認してください。
さらに、この特定の危険な使用については、このgithubブログ投稿を確認してください。
実行されるワークフローがベースで定義されたものであり、PRではないため、pull_request_targetを使用することは安全に見えるかもしれませんが、安全でない場合がいくつかあります。
そして、これにはシークレットへのアクセスがあります。
workflow_runworkflow_runトリガーは、別のワークフローがcompleted、requested、またはin_progressのときにワークフローを実行することを許可します。
この例では、ワークフローは、別の「テストを実行」ワークフローが完了した後に実行されるように構成されています：
Moreover, according to the docs: The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not.
この種のワークフローは、pull_request または pull_request_target を介して外部ユーザーによって トリガーされる ワークフロー に 依存している 場合、攻撃される可能性があります。いくつかの脆弱な例は このブログで見つけることができます。 最初の例は、workflow_run トリガーされたワークフローが攻撃者のコードをダウンロードすることです: ${{ github.event.pull_request.head.sha }}
2つ目の例は、信頼できない コードから workflow_run ワークフローに アーティファクト を 渡す ことと、このアーティファクトの内容を RCEに脆弱 な方法で使用することです。
workflow_callTODO
TODO: pull_request から実行されたときに使用/ダウンロードされたコードが元のものであるかフォークされたPRのものであるかを確認する
外部の攻撃者がGitHubワークフローを実行させる方法についてすべて言及しましたが、次に、これらの実行が不適切に構成されている場合、どのように悪用される可能性があるかを見てみましょう。
pull_request の場合、ワークフローは PRのコンテキスト で実行されるため（悪意のあるPRのコード を実行します）、誰かが 最初に承認する必要があります そして、いくつかの 制限 で実行されます。
pull_request_target または workflow_run を使用するワークフローが pull_request_target または pull_request からトリガーされるワークフローに依存している場合、元のリポジトリのコードが実行されるため、攻撃者は実行されるコードを制御できません。
ただし、アクション に 明示的なPRチェックアウト があり、PRからコードを取得する （ベースからではなく）場合、攻撃者が制御するコードが使用されます。例えば（PRコードがダウンロードされる12行目を確認してください）:
潜在的に 信頼できないコードは npm install または npm build の間に実行されます。ビルドスクリプトと参照された パッケージはPRの著者によって制御されています。
脆弱なアクションを検索するためのGitHubドークは: event.pull_request pull_request_target extension:yml ですが、アクションが不適切に構成されていても、ジョブを安全に実行するためのさまざまな方法があります（PRを生成するアクターが誰であるかに関する条件を使用するなど）。
特定の GitHubコンテキスト の値は、PRを作成する ユーザー によって 制御されている ことに注意してください。GitHubアクションがその データを使用して何かを実行する 場合、任意のコード実行 に繋がる可能性があります:
Gh Actions - Context Script Injectionsドキュメントによると: 環境変数を定義または更新し、これを GITHUB_ENV 環境ファイルに書き込むことで、ワークフロージョブの後続のステップで 環境変数を利用可能にする ことができます。
攻撃者がこの env 変数内に 任意の値を注入 できる場合、LD_PRELOAD や NODE_OPTIONS などの次のステップでコードを実行できる環境変数を注入することができます。
例えば (これ と これ)、アップロードされたアーティファクトを信頼してその内容を GITHUB_ENV 環境変数に保存するワークフローを想像してください。攻撃者はこれを妥協するために次のようなものをアップロードできます:
このブログ投稿 で述べたように、このGitHubアクションは異なるワークフローやリポジトリからアーティファクトにアクセスすることを可能にします。
問題は、path パラメータが設定されていない場合、アーティファクトが現在のディレクトリに抽出され、後で使用または実行される可能性のあるファイルを上書きできることです。したがって、アーティファクトが脆弱な場合、攻撃者はこれを悪用してアーティファクトを信頼する他のワークフローを妥協する可能性があります。
脆弱なワークフローの例:
このワークフローで攻撃される可能性があります：
アカウントが名前を変更すると、他のユーザーがしばらく後にその名前でアカウントを登録できる可能性があります。リポジトリが名前変更前に100スター未満だった場合、Githubは新しく登録したユーザーが削除されたリポジトリと同じ名前のリポジトリを作成することを許可します。
したがって、アクションが存在しないアカウントのリポジトリを使用している場合、攻撃者がそのアカウントを作成し、アクションを妨害する可能性があります。
他のリポジトリがこのユーザーのリポジトリからの依存関係を使用している場合、攻撃者はそれらをハイジャックできるようになります。こちらにより詳細な説明があります: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/
このセクションでは、最初のリポジトリに何らかのアクセス権があると仮定して、1つのリポジトリから別のリポジトリにピボットする技術について説明します（前のセクションを確認してください）。
キャッシュは同じブランチ内のワークフロー実行間で維持されます。つまり、攻撃者がパッケージを妨害し、それがキャッシュに保存され、より特権のあるワークフローによってダウンロードおよび実行されると、そのワークフローも妨害される可能性があります。
GH Actions - Cache Poisoningワークフローは他のワークフローやリポジトリからのアーティファクトを使用することができます。攻撃者がアーティファクトをアップロードするGithub Actionを妨害することに成功すれば、他のワークフローも妨害される可能性があります：
Gh Actions - Artifact Poisoning以下のページを確認してください：
AWS - Federation AbuseGCP - Federation Abuseスクリプトにコンテンツを注入している場合、シークレットにアクセスする方法を知っておくと興味深いです：
シークレットまたはトークンが環境変数に設定されている場合、**printenv**を使用して環境を介して直接アクセスできます。
シークレットが式に直接使用される場合、生成されたシェルスクリプトはディスク上に保存され、アクセス可能です。
cat /home/runner/work/_temp/*
カスタムアクションの場合、プログラムが引数から取得したシークレットをどのように使用するかによってリスクが異なる可能性があります：
Github Actionsが非Githubインフラストラクチャで実行されているかどうかを見つける方法は、Github Action構成yaml内で**runs-on: self-hosted**を検索することです。
セルフホストランナーは、追加の機密情報や他のネットワークシステム（ネットワーク内の脆弱なエンドポイント？メタデータサービス？）にアクセスできる可能性があります。また、隔離されて破壊されていても、同時に複数のアクションが実行される可能性があり、悪意のあるアクションが他のアクションのシークレットを盗むことができます。
セルフホストランナーでは、_Runner.Listener_**プロセスから**シークレットを取得することも可能で、ワークフローのすべてのシークレットが任意のステップでメモリをダンプすることによって含まれます：
Check この投稿で詳細情報を確認してください.
Github内にDockerイメージをビルドして保存するGithubアクションを作成することが可能です。 以下の展開可能な例を参照してください:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
