継続的インテグレーションと継続的デプロイメント（CI/CD) pipelineは、効率的なソフトウェア開発を促進する上で極めて重要な役割を果たします。しかし、これらの pipeline重要性が増すにつれ、脆弱性からそれらを保護する必要性がより顕著になります。この詳細な調査では、OWASP Top-10で特定された主要なリスクへの対処に焦点を当てています。 CI/CD セキュリティリスク：毒物 Pipeline 執行（PPE）。
毒物とは何か Pipeline 執行（PPE）
OWASPトップ10によると CI/CD セキュリティリスク、「中毒 Pipeline 実行 (PPE (People Protection Equipment)リスクとは、ソース管理システムにアクセスできるがビルド環境にはアクセスできない攻撃者の能力を指します。 悪意のあるコードやコマンドをビルドプロセスに挿入することで、ビルドプロセスを操作する。 pipeline の監視、本質的に 「毒を盛る」 pipeline そして、ビルドプロセスの一部として悪意のあるコードを実行する」
一言で言えば、ポイズンド Pipeline 実行（PPE）は、 攻撃者は pipeline ロジック.
二つあります バリアント:
- 直接個人用保護具 (D-PPED-PPEシナリオでは、 攻撃者がCI設定ファイルを改変する アクセス権のあるリポジトリ内で、リポジトリ上の保護されていないリモートブランチに直接変更をプッシュするか、ブランチまたはフォークから変更を含むプルリクエストを送信するかのいずれかの方法で変更を行います。 CI以来 pipeline 実行は変更された CI 構成ファイル内のコマンドによって定義され、攻撃者の悪意のあるコマンドは最終的にビルドノードでビルドが完了すると実行されます pipeline トリガーされます。
- 間接的な個人用保護具 (I-PPE): 特定のケースでは、D-PPE の可能性は、 SCM リポジトリ (例: pipeline （同じリポジトリ内の別の保護されたブランチからCI構成ファイルを取得するように構成されている）。 このようなシナリオでは、 pipeline 攻撃者は、 pipeline （例：内部から参照されるスクリプト pipeline 設定ファイル）
両方の場合において、 GitHub は変更された pipeline 事前の審査や承認は不要.
PPEの早期発見
この種の脆弱性をどのように検出できるでしょうか？
この例を見てみましょう pipeline :
そして、ダミーのシェルスクリプト（runtests.sh）の内容は以下のとおりです。
その pipeline 非常にシンプルです。その目的は、レビュー担当者にいくつかの予備的なヒントを提供することです。 Pull Request （PR）承認プロセス：
- これは、 プルリクエスト （つまり、プルリクエストが作成されるたびに）
- PRコード（つまり、貢献されたコード）をチェックアウトします。
- ビルド
- 提供されたコードに対してテストを実行します（例えば、シェルスクリプトを実行するなど）。
手順3（ビルドの実行）と手順4（テストの実行）は、コードがコンパイルされない場合、またはテストに合格しない場合は失敗します。したがって、これらの手順はプルリクエストを受け入れるための必要条件ではありますが、十分条件ではありません。手順が成功した場合、リポジトリ管理者は提供されたコードを確認し、それに基づいてプルリクエストを承認、拒否、またはコメントします。
Xygeniスキャナー
ザイゲニ CLI（「Xygeniスキャナー）に埋め込むことができる pipeline またはコマンドラインで実行します。Xygeni Scanner は、 pipeline脆弱性をチェックし、GitHub PAT が提供されている場合は GitHub に接続して組織/リポジトリ レベルで脆弱性を検出します。
Xygeniの在庫状況
このリポジトリで Xygeni Scanner を実行すると、有用なアセットのセット ( Xygeniの在庫状況)在庫には、さまざまなタイプの CI/CD 資産、のような：
- その SCM システム リポジトリが保存されている場所
- その SCM プラグイン インストール済み/使用済み
- その コードリポジトリ 自体
- その SCM 組織 リポジトリが属する場所
- その CI/CD Pipelinesとジョブズ
- その CI/CD システム 実行中 pipelines
- IaC 資料 リポジトリに定義されています
- 外部 依存関係
- 等..
この例では、特定の資産タイプで在庫をフィルタリングできます（SCM- および CICD 関連資産）なので、次のことがわかります。
- SCM システムはGitHub Cloudです
- リポジトリはGitHub Cloudに保存され、特定のGitHub組織に属しています。
- 二つあります pipelineGitHub によって提供されています (CI/CD システム）
- あらゆる pipeline 特定のステップが1つ含まれています
上記を選択することで pipeline いくつかの脆弱性が見られます。
- At pipeline レベルによっては、 直接 (NAIST) と 間接的な個人用保護具。
毒殺された人々の詳細を見ることができます Pipeline 実行上の脆弱性
Xygeniは、 D-PPEに脆弱 なぜならそれは Pull Request イベントがあり、追加のセキュリティ制御がないため、リポジトリのどのユーザーでも変更できます。 pipeline そして、これらの変更は、いかなる審査や承認もなしに実行される。
同様に、Xygeni は、 I-PPEに脆弱 シェルスクリプトの呼び出しにより pipeline: リポジトリのどのユーザーでもシェルスクリプトを変更でき、それらの変更はレビューや承認なしに実行されます。
もっと知りたいですか？
PPEの悪用
PPEを活用するために、次のようなシナリオを考えてみましょう。 2種類のレポジトリ利用者:
- An 内部ユーザー （そのリポジトリで作業している内部開発者）リポジトリへの書き込み権限を持つ
- An 外部ユーザー （外部委託された開発者がそのリポジトリで作業しているが、リポジトリに対する読み取り権限しか持っていない）、つまりリポジトリをブランチすることは許可されておらず、フォークで作業することを強いられている。
両者とも悪意のある攻撃者（または悪意のある行為者によるなりすまし）だと仮定しましょう。リポジトリには秘密情報が含まれており、両者とも リポジトリの秘密を盗む そしてそれをハッカーが制御するサーバーに送信する。そのためには、彼らはポイズンド Pipeline 実行の脆弱性 pipeline.
どちらの場合も（外部ユーザーと内部ユーザー）、 Pull Request 同じ修正を加えた上で：
- その pipeline シェルスクリプトが変更されました 〜へ 秘密を読む 環境から、そして ハッカーが制御するサーバーに送信する
変更点は以下のとおりです。
両方のユーザーが作成します Pull Request 変更を加えてPRの作成時に、 GitHubは両方の変更を実行します （事前の審査や承認は不要）その結果、以下のようになった。
書き込みユーザーと読み取りユーザーも同様です。 どちらの場合も、D-PPEとI-PPEが実行されます。違いは 読み取りユーザーは秘密情報にアクセスできません。（！！！！）
その理由は、 フォークから作成されたプルリクエストの場合、GitHub はリポジトリのシークレットへのアクセスを許可しません。 読み取りユーザーは秘密情報を読み取ることはできませんが、他のプログラムを実行することは可能です。典型的な攻撃例としては、暗号通貨マイナーをダウンロードするプルリクエストを作成することが挙げられます。これにより、GitHub ランナーは、汚染されたプルリクエストを実行する際に暗号通貨マイナーを実行します。 pipeline.
もちろん、ここは安全な環境ではありません！ リポジトリ管理者は、それを回避するためにどのような対策を講じることができるでしょうか？
グーグル検索の後、リポジトリ管理者は変更することに決めました。 pipeline トリガーされる プルリクエスト対象 イベント。なぜ？ pipelinepull_request_target でトリガーされた s は実行を許可しません pipeline 修正つまり、ユーザーによる変更にもかかわらず、「オリジナル」 pipeline 実行されます。
私たちの例に倣うと、攻撃は以前と同じになります。では、その後どうなるのでしょうか？ pipeline 修正？
予想通り、 D-PPEは実行されません しかし、I-PPEはまだ存在するので、 読み取りユーザーがリポジトリのシークレットにアクセスできるようになりました!!!
読み取りユーザーが秘密情報にアクセスできるようになった理由は何ですか？ pipeline 変更することはできませんが、シェルスクリプトを変更することは可能です。 時 pipeline pull_request_targetでトリガーされると、特権モードで実行されます。 so それはシェルスクリプトにもなりますその結果、シェルスクリプトがリポジトリの秘密情報にアクセスできてしまう！！
予防策
GitHubは、悪意のあるプルリクエストから保護するための対策をいくつか提供しています。
ブランチ保護ルール
GitHubでは、選択したブランチに対してブランチ保護ルールを定義できます。
保護対象の支店に対しては、以下のポリシーを指定できます。 が必要です pull request 合併前に （承認件数の要件、コード所有者によるレビューなど、その他の条件も含む。）
特に考慮すべき条件は以下のとおりです。
- 指定されたアクターが必須の手順をスキップできるようにする pull requests"。
- 上記の設定をバイパスすることを許可しない
ほとんどの条件はポリシーを厳格化するものですが、これらの条件はポリシーを緩和するものであり、例えば「特権を持つ」行為者によって認証情報が盗まれた場合など、悪意のある活動への道を開く可能性があります。
GITHUB_TOKENの権限を制限する（最小権限の原則）
GitHubトークンの権限を必要な権限のみに制限してください。こうすることで、攻撃者があなたの pipeline彼らにはあまりできることはないでしょう。
文字列補間を避けるには、 pipeline 環境変数
入力変数を使用するたびに pipelineただし、デフォルトでは「信頼できない」データ（その内容はエンドユーザーによって管理される）とみなすべきであることに注意してください。参照 信頼できないアクションとワークフローを保護する (NAIST) と GitHub Actions を学びましょう。
スクリプト内で入力変数を挿入する際は、文字列補間ではなく、常に環境変数を使用するようにしてください。
ワークフローの実行と承認要件
『Brooklyn Galaxy』のために、倪氏はブルックリン美術館のコレクションからXNUMX点の名品を選び、そのイメージを極めて詳細に描き込みました。これらの作品は、彼の作品とともに中国ギャラリーに展示されています。彼はXNUMX年にこの作品の制作を開始しましたが、最初の硬貨には、当館が所蔵する 公共 リポジトリ、GitHub では指定できます 外部からのプルリクエストへの対応方法.
GitHub組織設定（「組織 >> 設定 >> アクション >> 一般」）では、外部からのプルリクエストの管理方法を指定できます。
デフォルトでは、GitHub は初回コントリビューターに対してプルリクエストの承認を要求するため、悪意のあるリクエスト攻撃はより複雑になります。それでも、攻撃者は、例えば無害な貢献をすることでプロジェクトメンテナーの信頼を得る可能性があります。 pull request 実際の攻撃の前に。
この意味で、 3つ目の選択肢（すべての外部協力者に対して承認を求める）は、より高度な管理機能を追加します。
『Brooklyn Galaxy』のために、倪氏はブルックリン美術館のコレクションからXNUMX点の名品を選び、そのイメージを極めて詳細に描き込みました。これらの作品は、彼の作品とともに中国ギャラリーに展示されています。彼はXNUMX年にこの作品の制作を開始しましたが、最初の硬貨には、当館が所蔵する プライベート GitHubは、リポジトリに関して、組織レベルとリポジトリレベルの両方で便利な制御機能も提供しています。
ワークフローを実行する Pull Requests」（デフォルトではチェックされていません）を使用すると、フォークのプルリクエストからワークフローを実行できます（読み取り専用権限を持ち、シークレットにアクセスできない GITHUB_TOKEN を使用）。このオプションを最後のオプション（「フォークPRワークフローには承認が必要」 ) 、プライベートリポジトリと同様のポリシーにアクセスできます（上記参照）。
読み取りユーザーからの PPE エクスプロイトで見たように、 フォークからワークフローを実行できるようにする pull requests 危険です！！
残りの選択肢（フォークからワークフローに書き込みトークンを送信する pull requests"と"ワークフローにシークレットと変数を送信する pull requests"） セキュリティレベルを下げる フォークのプルリクエストに適用されます。
このフォークポリシーは、組織レベルまたはリポジトリレベルで定義できます。組織レベルでポリシーが無効になっている場合、リポジトリレベルで有効にすることはできません。ただし、組織レベルでポリシーが有効になっている場合は、リポジトリレベルで無効にすることができます。
まとめ
私たちは、いくつかのことの影響を理解していただけたことを願っています pipeline 毒に弱い Pipeline 実行。 commit 脆弱な pipelineそして、安全なものを書くのは難しい。
そのため、Xygeni Scannerを使用してこうした脆弱性を把握することは非常に有益です。
脆弱性の存在を認識しなければ、その脆弱性を解決することはできません。
しかし…まだ未解決の疑問が残っている…。 I-PPEを回避するには？
これは次回の投稿のテーマになります🙂 間接的な毒殺 Pipeline 執行（I-PPE） !!
