GitHub キャッシュポイズニング

CI の内部で何が起こっているかご存知ですか?深く理解していないと、革新的なサプライ チェーン攻撃に対して脆弱になる可能性があります。この記事ではそのような攻撃について説明します。

キャッシュはプロセスを高速化するために使用されます。パッケージを何度もビルドしたりダウンロードしたりするのではなく、再利用できるようにアーティファクトを簡単かつ自動的に保存します。ただし、キャッシュが汚染されている可能性があります。たとえば、テスト ワークフローで使用される悪意のあるツールにより、そのキャッシュが汚染される可能性があります。その後、同じキャッシュを使用する別のワークフローが影響を受ける可能性があります。このワークフローに高い権限がある場合、これは実際に攻撃を方向転換する方法となります。この投稿では、GitHub CI パイプラインに対する実験的な攻撃について報告しますが、同様の論理的脆弱性が他の CI 製品にも存在します。

攻撃は次のように展開されます。 

1. 攻撃者が悪意のあるツールまたは Github アクションを公開し、それが Github 内の無防備なワークフローによって検出されます。
2. ワークフローはキャッシュを使用して設計されています
3. 悪意のあるペイロードはキャッシュを変更して悪意のあるデータを含めます。
4. この時点からこのキャッシュを呼び出す他のワークフローが影響を受ける可能性があります。

私たちの開示に対して、GitHub は、この種の攻撃に対してキャッシュ機能を強化する計画はないと述べました。 

私たちは、キャッシュのコンテンツ ハッシュ値に暗号的に署名し、使用前に署名を検証することによって軽減することを提案します。この攻撃と緩和策について詳しく知りたい場合は、読み続けてください。

GitHub キャッシュ

多くの場合、ある実行から別の実行に同じ出力またはダウンロードされた依存関係を再利用します。 (たとえば、パッケージによってダウンロードされたパッケージと、Maven、Gradle、npm、Yarn などの依存関係管理ツール。これらのパッケージは通常、ダウンロードされた依存関係のローカル キャッシュに保持されます).

CI の実行を最適化するために、GitHub は API を介してパイプライン全体で使用できるキャッシュ リソースへのアクセスを許可します。キャッシュ内のエントリはキーと値の組み合わせです。キーは文字列ベースで、値はキャッシュしたいファイルまたはディレクトリです。

使い方 アクション/キャッシュ CI 内の任意の場所の Git アクションは 2 つのステップを実行します。1 つのステップは、 ラン 呼び出されたときに処理し、他の処理はその後に行われます ワークフロー (実行アクションがキャッシュミスを返した場合)。

• アクションの実行 – キャッシュの検索と取得に使用されます。検索はキャッシュ キーを使用して行われ、結果はキャッシュ ヒット (成功、キャッシュ内にデータが見つかった) またはキャッシュ ミスのいずれかになります。見つかった場合、ファイルとディレクトリはキャッシュから取得され、アクティブに使用されます。結果がキャッシュミスの場合、目的のファイルとディレクトリは、初めて呼び出されたときと同様にダウンロードされます。
• ワークフロー後のアクション – キャッシュを保存するために使用されます。実行アクションでのキャッシュ呼び出しの結果がキャッシュミスを返した場合、このアクションは、指定されたキーを使用してキャッシュするディレクトリの現在の状態を保存します。このアクションは自動的に行われるため、明示的に呼び出す必要はありません。

GitHub キャッシュのアクセス許可

アクセス制限が提供する キャッシュの分離 異なるブランチ間に論理的な境界を作成することによるセキュリティ (例: ブランチ用に作成されたキャッシュ 機能-A [ベースのメインを使用すると] ブランチのプル リクエストにアクセスできなくなります 機能-B [ベースメイン付き]).

キャッシュ アクションは、まずキャッシュ ヒットでキーを検索し、そのキーを含むブランチにキーを復元します。 ワークフローの実行。現在のブランチにヒットがない場合、キャッシュ アクションによってキーが検索され、親ブランチと上流ブランチにキーが復元されます。

キャッシュへのアクセスはブランチ (現在および親) ごとにスコープされます。つまり、すべてのブランチにアクセスが提供されます。 ワークフロー 越えて 実行 当該支店の。

もう 1 つの重要な点は、GitHub ではエントリがプッシュされると変更を許可しないことです。キャッシュ エントリは読み取り専用のレコードです。

GitHub CI スコーピング

GitHubの スコープ さまざまなタスクに必要なアクセスの種類を正確に指定できます。 GitHub の CI はさまざまな方法でスコープ設定されており、それぞれに独自の値と機能のセットがあります。

• 各ジョブの仮想マシン (VM)
• ジョブ権限
• ワークフローの範囲
• ワークフローの実行
• Gitブランチ
• ワークフロー ID トークン
• ほか

GitHub キャッシュ スコープは、他のスコープ制限の一部を破る可能性がある方法で定義されています (例: GitHub キャッシュは複数のワークフローに影響を与える可能性があります).

攻撃

2 つのワークフローを含むサンプル CI を使用しました。この例は、攻撃がどのように権限の低いワークフローから権限の高いワークフローに移行するかを示しています。

• 単体テスト 単体テストおよびコード カバレッジ ツールを実行するワークフロー。いずれかのツールに悪意があるか、リモートでコードが実行される脆弱性があると想定します。ワークフローでは、 アクション/キャッシュ Git アクション。どのワークフローでもキャッシュにアクセスできます。
• リリース ワークフローはアプリケーション アーティファクトをビルドしてリリースします。このワークフローでは、キャッシュを使用して Golang の依存関係を最適化します。

　 単体テスト ワークフローは、Golang ログ ライブラリを変更することで、悪意のあるコンテンツを含むキャッシュ エントリを追加する悪意のあるアクションを使用します。 (go.uber.org/zap@v1) 文字列「BAD library」をアプリケーションアーティファクトの説明に追加します。

次、 リリース ワークフローは、この有害なキャッシュ エントリを使用します。その結果、悪意のあるコードがビルドされた Golang バイナリとイメージに挿入されます。キャッシュは、エントリ キーが破棄されるまで (通常は依存関係の更新によってトリガーされます)、汚染されたままになります。同じ毒されたキャッシュは他のキャッシュに影響を与えます ワークフロー, ラン, 子ブランチ 同じキャッシュキーを使用します。

私たちが実行したテストでは、文字列「BAD library」を画像の説明に挿入することができました。

これはバージョン 0.4.1 にありました。次に、タグを更新してイメージを数回再構築したところ、説明に「Bad library」が残っていることがわかりました。

GitHub の開示

私たちの開示に対する Github の反応は、Git のアクションは、  アクション/キャッシュ は期待どおりに動作し、キャッシュのスコープを厳しくする予定はありません。
GitHub チームはこの動作に問題があるとは考えていませんが、DevSecOps 担当者にはこの攻撃ベクトルに注意するようアドバイスしています。

緩和

1. リリースまたは重要なワークフローではキャッシュを使用しないでください。
2. 信頼できるワークフローを最初に実行して、ワークフローを順番に実行し、信頼できるワークフローでキャッシュが作成されていることを確認します。
3. 依存関係をベンダーする – GoLang でのベンダーは、Go プロジェクトで使用されるすべてのサードパーティ パッケージが、そのアプリケーションを開発するすべての人にとって一貫していることを保証する方法です。こうすることで、キャッシュされた依存関係はプロジェクトのすべてのブランチに対して有効なままになります。他の言語ではこの方法がサポートされていない可能性があります。
4. キャッシュ値に暗号的に署名し、使用前に署名を検証します。
   Scribe は、キャッシュなどのワークフロー内のオブジェクトまたはディレクトリにきめ細かく署名することで、このような攻撃を軽減します。リリース前に、Scribe を使用して、信頼できるワークフローによって生成されたキャッシュのみがリリースのビルドに使用されたことを検証できます。

まとめ 

この投稿では、DevSecOps チームの目から隠されている CI ワークフローにおけるキャッシュ ポイズニング攻撃について概要を説明し、緩和策について説明しました。