TensorFlow CI/CD のミスコンフィグへの対応:サプライチェーン攻撃の要因になり得る

TensorFlow CI/CD Flaw Exposed Supply Chain to Poisoning Attacks

2024/01/18 TheHackerNews — オープンソースの機械学習フレームワーク TensorFlow で発見された CI/CD (integration and continuous delivery ) のミスコンフィグが、サプライチェーン攻撃の組織化のために悪用された可能性があるという。今週のレポートで Praetorian の研究者である Adnan Khan と John Stawinski は、「このミスコンフィグを悪用する攻撃者が、悪意のプルリクエストを通じて TensorFlow のビルド・エージェントを侵害し、GitHub/PyPi 上の TensorFlow リリースのサプライチェーンを侵害した可能性がある」と述べている。

これらの問題の悪用に成功した、外部の攻撃者が可能にするものには、 GitHub リポジトリ上への悪意のリリースのアップロード/セルフホスト型の GitHub ランナー上でのリモート・コードの実行/tensorflow-jenkins ユーザーの GitHub Personal Access Token (PAT) の取得などがあるという。

TensorFlow では、ソフトウェアのビルド/テスト/デプロイのパイプラインを自動化するために、GitHub Actions が使用されている。ランナーとは、GitHub Actions のワークフローでジョブを実行するマシンのことであり、セルフホストと GitHub ホストの2種類がある。

GitHub のドキュメントには、「プライベート・リポジトリで推奨されるのは、セルフホスト・ランナーのみの使用である。つまり、ワークフローのコードを実行するプルリクエストを作成することで、公開リポジトリでフォークされたものが、セルフホスト・ランナーのマシンで危険なコードを実行する可能性があるためだ」と記されている。

別の言い方をすれば、悪意のプルリクエストをサブミットすることで、どのようなコントリビュータであっても、セルフホスト型ランナー上で任意のコードを実行できるようになる。その一方で、GitHub がホストするランナーでは、各ランナーはエフェメラル (ephemeral) であり、ジョブの実行が終わると破棄されるクリーンで隔離された仮想マシンでは、セキュリティ上の問題が生じない。

しかし、Praetorian によると、セルフホスト・ランナーで実行された、TensorFlow ワークフローの特定が可能であるという。さらに、承認を必要とせずに、適切な CI/CD ワークフローを自動的にトリガーする、以前の貢献者からのフォーク・プルリクエストを見つけることも可能だという。

したがって、ターゲット・リポジトリをトロイの木馬化しようとする敵対者は、プルリクエストがマージされてコントリビュータとして認められる状況を待つことができる。そのための手口として挙げられるのは、タイプミスの修正や、正当かつ小規模なコード変更のための、プル・リクエスト作成などである。

こうすることで、不正なプルリクエストの作成でフラグを立てることなく、ランナー上でコードを実行できるようになる。

さらに、ワークフローのログを調査したところ、セルフ・ホスティングされたランナーが、永続化のドアが開かれる非エフェメラルであるだけではなく、ワークフローに関連付けられた GITHUB_TOKEN パーミッションに対して、広範な書き込みパーミッションが付与されていることも判明した。

研究者たちは、「GITHUB_TOKEN は “contents:write” パーミッションを持っているため、”https://github%5B.%5Dcom/tensorflow/tensorflow/releases/” にリリースをアップロードすることが可能だった。これらの GITHUB_TOKEN の1つを侵害した攻撃者は、リリース資産に自分のファイルを追加することが可能だった」と述べている。

その上で、”contents:write” パーミッションを武器化することで、悪意のコードを機能ブランチに密かに注入してメインブランチにマージさせることで、TensorFlow リポジトリにコードを直接にプッシュできる。

それだけではない。リリース・ワークフローで使用されるAWS_PYPI_ACCOUNT_TOKEN を盗み出した攻撃者は、Python Package Index (PyPI) レジストリを認証し、悪意の Python .whl ファイルをアップロードし、効果的にパッケージをポイズニングできる。また、攻撃者は、GITHUB_TOKEN のパーミッションを使用して、JENKINS_TOKEN のリポジト・リシークレットを侵害できるという。

この問題は、2023年8月1日に GitHub に公開された。そして、2023年12月20日の時点で、プロジェクトのメンテナたちにより、すべてのフォーク・プルリクエストから提出されたワークフローの承認が必要とされるように修正された。また、セルフホスト・ランナー上で実行された、ワークフローの GITHUB_TOKEN パーミッションが、読み取り専用に変更されることで欠陥は対処された。

研究者たちは、「より多くの組織が CI/CD プロセスを自動化するにつれて、同様の CI/CD 攻撃が増加する傾向にある。AI/ML 企業は、特に脆弱である。彼らのワークフローの多くは、GitHub ホストランナーでは利用できない、大きな計算能力を必要とするため、セルフホスト・ランナーが普及している」と付け加えている。

今回の情報公開は、Chia Networks/Microsoft DeepSpeed/PyTorch などにも関連する、いくつかの公開 GitHub リポジトリが、セルフホスト型の GitHub Actions ランナーを経由した、悪意のコード・インジェクションの影響を受けやすいことを、両研究者が明らかにしたことに伴うものだ。