GitHub Actions Script Injection: The CI/CD Backdoor 🚪

攻撃者がGitHub Actionsを悪用してUltralytics YOLOとPyPIリリースにバックドアを仕掛けた方法

2024年12月、オープンソースコミュニティは近年最も高度なサプライチェーン攻撃の一つを目撃しました。コンピュータビジョンと物体検出に使われる重要なAIパッケージ、Ultralytics YOLOライブラリが、GitHub Actionsの脆弱性を突いた綿密に計画された攻撃の犠牲となったのです。この事件は、現代のソフトウェアサプライチェーンは最も弱い部分だけが安全であることを改めて示すものであり、その弱点はますます自動化されたCI/CDパイプラインそのものであることを強調しています。

Ultralyticsエコシステムの理解

Ultralytics YOLOはGitHubで30,000以上のスターと6,000以上のフォークを持ち、PyPIパッケージはこれまでに約6000万回ダウンロードされています。このライブラリは、自動運転車から医療画像システムまで、さまざまな産業の重要な機械学習アプリケーションを支えています。その広範な採用により、攻撃者にとって最大のインパクトを狙えるターゲットとなっていました。

このライブラリは、ComfyUI Impact Pack拡張など、多くの人気パッケージの依存関係として機能しており、Ultralyticsを侵害することで、数千の下流アプリケーションに影響を及ぼす連鎖反応を引き起こす可能性があります。現代のソフトウェア依存関係の相互接続性は、単一の脆弱性をエコシステム全体のセキュリティ危機に変えるのです。

攻撃のタイムライン：多波攻撃

第1波：初期侵害（2024年12月4-5日）

攻撃は、悪意のあるバージョン8.3.41と8.3.42がPyPIに公開されたことで始まりました。最初の攻撃の高度さは、開発者が気付いたときに、悪意のあるコードがPyPIパッケージにのみ存在し、GitHubリポジトリのソースコードには存在しなかったことから明らかになりました。この不一致は、従来のコードインジェクションではなく、自動ビルドとデプロイの過程での侵害を示唆しています。

開発者が異常な挙動に気付いたとき、最初に取った対応はバージョン8.3.42をプッシュして修正することでした。しかし、真の攻撃経路を特定していなかったため、この「修正」も同じ悪意のあるペイロードを含んでおり、脆弱性の窓を拡大し、更新を急ぐユーザーをさらなるリスクに晒しました。

第2波：資格情報の窃盗と持続性（2024年12月7日）

開発者がクリーンなバージョン8.3.43と8.3.44を公開した後、ペイロードは8.3.45と8.3.46に再登場しました。今回は、悪意のあるコードはPyPIパッケージにのみ存在し、GitHubにはありませんでした。コミュニティの分析から、攻撃者は最初の侵害時にPyPI APIトークンを抜き取ることに成功し、それを使って毒入りパッケージを直接アップロードしていたことが強く示唆されました。

第2波は、持続性と適応性の高さを示しています。攻撃者は最初のビルドパイプラインを侵害しただけでなく、長期的なアクセス資格情報も確保しており、最初の脆弱性が修正された後も攻撃を継続できる状態にしていました。

技術的な悪用：GitHub Actions Script Injection

脆弱性の理解

ビルド環境への侵入は、Adnan Khanというセキュリティ研究者によって報告された既知のGitHub Actions Script Injection脆弱性を悪用した高度な手法によるものでした。この種の脆弱性は、GitHub Actionsのワークフローが、ブランチ名やプルリクエストタイトルなどのユーザー制御入力を適切にサニタイズせずに取り込む場合に発生します。

この脆弱性により、攻撃者は悪意のあるペイロードを埋め込んだブランチ名を作成し、これを利用して任意のコードをビルド環境内で実行させることが可能になりました。脆弱なアクションを使用したワークフローがpull_request_targetトリガーで動作すると、これらの特別に作成されたブランチ名がコードとして実行され、秘密情報の窃取やビルドアーティファクトの改ざんを許してしまいます。

攻撃の仕組み

2024年12月4日、GitHubユーザーのopenimbotがUltralyticsのactionsリポジトリに2つの疑わしいドラフトプルリクエストを作成しました。これらのプルリクエストは一見無害に見えましたが、そのブランチ名にはリモートスクリプトをダウンロードして実行するための巧妙に仕込まれたインジェクションペイロードが含まれていました。

この攻撃の巧妙さは、pull_request_targetトリガーの利用にありました。通常のpull_requestトリガーは、フォーク元のブランチからではなくベースブランチからワークフローを実行しますが、重要な点はリポジトリの秘密情報にアクセスできることです。この設計は外部からの貢献を安全に自動化するためのものでしたが、逆に攻撃の仕組みとなったのです。

Adnan Khanはこのスクリプトインジェクション脆弱性を2024年8月に報告し、その後修正されました。しかし、その後コードベースにリグレッションが入り、Ultralyticsが最初の脆弱性に関するセキュリティアドバイザリを公開してからわずか10日後に脆弱なコードが再登場し、攻撃者が破壊的に利用できる窓を作り出しました。

キャッシュポイズニング戦術

攻撃者は、GitHub Actionsを通じて改ざんを持続させるためにキャッシュポイズニング技術を使用しました。これはKhanが自身のセキュリティ研究で記録した手法であり、アクションのキャッシュを汚染することで、複数のワークフロー実行にわたって悪意のある改ざんを持続させ、検出と修復を非常に困難にしました。

悪意のあるペイロード：単なる暗号通貨マイニングを超えて

主な目的：暗号通貨マイニング

攻撃者は、downloads.pyとmodel.pyの2つの重要なファイルを改ざんしました。model.pyに注入されたコードは、システムのアーキテクチャやOSを検出し、プラットフォーム固有のペイロードをダウンロードする高度な環境検出を行います。downloads.pyは、実際にマルウェアバイナリをダウンロードし実行するダウンローダーコードを含んでいます。

この悪意のあるペイロードは、MoneroをターゲットとしたXMRig暗号通貨マイナーでした。Moneroは匿名性を重視した暗号通貨で、取引の追跡が難しい特徴があります。マイナーはシステムリソースを消費し、電力コストを押し上げ、被害者のシステムパフォーマンスを低下させました。

より大きな脅威

暗号通貨マイニングは実際に展開されたペイロードでしたが、セキュリティ研究者はより邪悪な潜在的影響を指摘しています。攻撃者がより攻撃的なマルウェア、例えばバックドアやリモートアクセスツールを仕込むことも可能だったのです。この攻撃経路は、ビルド環境に完全なコントロールを与え、ダウンロードされるパッケージに任意のコードを注入できる状態を作り出しました。

想像してみてください：このレベルのアクセス権を持つ攻撃者は、エンタープライズ向けのランサムウェア展開、CI/CDシステムからのAPIキーや資格情報の窃盗、運用環境への持続的なバックドア設置、あるいは機械学習モデル自体への敵対的改ざんを行うことも可能です。

CI/CDセキュリティの広範な影響

PyPIとGitHub：攻撃対象の理解

最初、多くはPyPIが最初の失敗点だと考えました。改ざんされたソフトウェアが最初に発見された場所だからです。しかし、PyPI自体が侵害されたのではなく、そこにホストされていたパッケージが自動ビルド過程で毒入りになったことが判明しました。

PyPIのセキュリティ flawはこの攻撃の実行に使われませんでした。PyPIの公式ブログによると、これは重要な区別です。どこにセキュリティコントロールを実装すべきか、サプライチェーン攻撃の調査においても理解を深めるポイントです。

信頼された公開のパラドックス

皮肉なことに、UltralyticsはTrusted Publishingというセキュリティ機能を利用していました。これは、長期有効なAPIトークンを排除し、OpenID Connectを通じて短期的に生成された資格情報を使うことでサプライチェーンの安全性を高める仕組みです。Trusted Publishingは、資格情報が短期間しか有効でなく、漏洩してもリスクを限定できることを意味します。

しかし、攻撃はこの対策さえも回避可能であることを示しました。攻撃者は、ビルド環境が侵害されたときに、正規の短期資格情報が有効な間にコードを実行できたのです。

GitHub Actionsエコシステムのリスク

これは、2024年1月に研究者がPyTorchプロジェクトの開発インフラを侵害するためにGitHub Actionsをハイジャックした事例と同様に、GitHub ActionsがPythonプロジェクトの失敗点となるケースの一つです。多くのプロジェクトがGitHub Actionsを使っていることから、その脆弱性は広範囲に及びます。

この問題は、個々の設定ミスだけではなく、GitHub Actionsの安全性に関するデフォルトの不備に起因しています。セキュリティは、数千のプロジェクトにわたる完璧な実装を求められるため、広範な脆弱性を招きやすいのです。

セキュリティ研究者Adnan Khanからの教訓

発見の歴史

セキュリティ研究者のAdnan Khanは、GitHub Actionsに関するセキュリティ問題の調査と発見において重要な役割を果たしてきました。彼の研究は、スクリプトインジェクションやセルフホストランナーの誤設定など、CI/CDパイプラインの体系的な脆弱性を特定するのに役立ちました。

Khanの調査手法は、攻撃者の思考を理解する上で貴重な洞察を提供します。彼は、人気リポジトリのGitHub Actionsワークフローを体系的に分析し、安全でない慣行のパターンを特定しました。彼の発見は、これらが孤立した事件ではなく、CI/CDシステムの根本的な設計上の課題の表れであることを示しています。

Pwn Request攻撃パターン

Khanの研究は、「Pwn Request」攻撃と呼ばれるクラスの脆弱性を確立しました。これは、外部のプルリクエストによってトリガーされたワークフローが、信頼できない入力を含むことで高権限で実行される問題です。名前は、「pwn」（ハッカー用語で侵害を意味する）と「pull request」を掛け合わせたもので、正当なコラボレーションメカニズムが攻撃経路になることを示しています。

核心は、pull_request_targetやworkflow_runといったトリガーを使い、攻撃者制御の値を適切にクォートせずに埋め込むと、攻撃者が意図しないコマンドを実行できる点にあります。

検出と対応：コミュニティの反撃

初期発見と帰属

「metrizable」という開発者は、UltralyticsのPyPIパッケージとGitHubリポジトリを比較することで、最初に侵害されたコードを発見しました。この差分分析は、ソースコードと配布アーティファクトを比較し、侵害がビルド過程で起きたことを特定するのに重要でした。

迅速なコミュニティの対応は、オープンソースの透明性と協力の価値を示しました。最初の報告から数時間以内に、多くのセキュリティ研究者や開発者、組織が攻撃を分析し、情報共有と対応を進めました。

組織の対応

Google Colabは侵害されたYOLOバージョンのシステムへのアクセスをブロックし、Ultralytics関係の開発者はユーザーにバージョン8.3.41のアンインストールを促しました。これらの即時措置はマルウェアの拡散を抑えるのに役立ちましたが、バージョン8.3.42の侵害の認識遅れが修復を複雑にしました。

ComfyUIは、悪意のあるバージョンを実行しているユーザーに警告を出すようにマネージャーを更新し、下流の依存関係も自らのユーザーベースを守る役割を果たしました。

PyPIの積極的措置

影響を受けたすべてのバージョン（8.3.41, 8.3.42, 8.3.45, 8.3.46）は、侵害の全容が判明次第、PyPIから削除されました。迅速に悪意のあるパッケージを除去できたことは、サプライチェーンのセキュリティにおいて重要なバックアップとなりますが、ユーザーが侵害されたパッケージをダウンロードできた期間は依然として大きな懸念事項です。

被害評価：ダメージの測定

ダウンロード統計とリスク露出

侵害されたバージョンは、PyPIから削除されるまで12時間以上公開されていました。この間、多くの自動化システムやCI/CDパイプライン、開発者の作業環境が悪意のあるパッケージをダウンロード・インストールした可能性があります。実際の影響範囲は、これらの自動化されたインストールの性質上、完全には把握できていません。

Wiz Researchのデータによると、Ultralyticsはクラウド環境の約10%に存在しており、このサプライチェーン攻撃が狙った攻撃対象の一つであることを示しています。この統計だけでも、企業や研究機関、個人開発者のシステムを合わせて数万に及ぶ潜在的な影響範囲を示唆しています。

暗号通貨マイニングの影響

侵害されたバージョンを展開したシステムは、持続的に高いCPU使用率を示し、暗号通貨マイニングの兆候を表しました。クラウド環境では運用コストの増加に直結し、オンプレミス環境ではパフォーマンス低下と電力消費の増加を引き起こしました。

最も懸念されるのは、即時の金銭的損失だけでなく、評判の毀損と信頼喪失です。侵害されたソフトウェアを使用していた組織は、セキュリティ体制や依存関係管理、インシデント対応の面で厳しい問いを突きつけられることになりました。

防止策：CI/CDパイプラインの堅牢化

入力のサニタイズと検証

Ultralytics攻撃の根本的な教訓は、すべてのユーザー制御入力は潜在的に悪意のあるものとみなすべきだということです。推奨される修正は、環境変数を使った入力のサニタイズです。これにより、特殊文字が意図しないコードとして実行されるのを防ぎます。

ブランチ名などの値をコマンドに直接埋め込むのではなく、GitHub Actionsの組み込み環境変数機構を利用すべきです。これにより、データとコードの境界が明確になり、入力にどんな文字が含まれていてもインジェクション攻撃を防止できます。

ワークフローのトリガー制限

組織は、どのワークフロートリガーを有効にし、どの条件下で動作させるかを慎重に評価すべきです。特に、外部からの貢献を自動化するためのpull_request_targetトリガーは、必要最小限にとどめ、極めて慎重に使用すべきです。避けられない場合は、このトリガーを使うワークフローに厳格な入力検証を実装し、秘密情報や特権操作へのアクセスを避けるべきです。

多層防御の一環として、ワークフローを複数のジョブに分割し、一つは最小権限で安全でない操作を行い、もう一つは出力を受け取り検証後に特権操作を行う設計が推奨されます。これにより、一つのコンポーネントが侵害された場合の被害範囲を限定できます。

依存関係の固定と検証

依存関係は、SHA256やgitコミットなどのチェックサムを用いて明示的にバージョンを固定すべきです。これにより、攻撃者が改ざんされた依存関係を自動更新で取り込むのを防ぎます。ただし、セキュリティアップデートの監視も必要です。

セキュリティと利便性のバランスを取ることが重要です。自動依存関係更新はソフトウェアの最新性とパッチ適用を促進しますが、一方でサプライチェーン攻撃のリスクも高めます。リスク許容度と運用の観点から、適切なバランスを見極める必要があります。

Trusted Publishingと短期資格情報

GitHub ActionsやGitLab CI/CD、Google Cloud Build、ActiveStateなどのプラットフォームで利用可能なTrusted Publishersを使うと、資格情報は短期間しか有効でなく、漏洩してもリスクを限定できます。Ultralyticsの攻撃は、この対策さえも突破され得ることを示しましたが、それでも長期的な資格情報の窃取リスクは大きく低減します。

攻撃者が盗んだ資格情報を使ってPyPIに直接アップロードした第2波の事例は、資格情報の管理の重要性を再認識させます。疑わしい場合は、迅速な資格情報のローテーションを実施すべきです。

バイナリアーティファクトのコードレビュー

組織は、バイナリや不透明なファイル（コンパイル済みバイナリ、ライブラリ、アーカイブ、証明書など）のコミットを避けるべきです。これにより、xz-utilsのバックドアのような攻撃を防止できます。バイナリの不透明性を排除し、ソースコードとしてレビュー可能な状態にすることが重要です。

インシデント対応：侵害時の対処法

直ちに取るべき行動

侵害を発見した組織は、直ちに対応を開始すべきです。まず、依存関係スキャナーやソフトウェア構成分析ツールを使って影響を受けたシステムを特定します。Ultralytics 8.3.41、8.3.42、8.3.45、8.3.46を展開したシステムは、セキュリティ監査を行い、悪意のあるコードが実行されたか、どのデータや資格情報が漏洩した可能性があるかを確認します。

侵害されたパッケージは直ちにアンインストールし、システムを以前のクリーンな状態に復元します。システムの挙動を監視し、暗号通貨マイニングの兆候（異常なCPU使用率、マイニングプールへのネットワーク接続、予期しないプロセス）を確認します。展開されたペイロードはマイナーでしたが、同じアクセス権を持つ攻撃者はより高度な脅威を仕込む可能性もあります。

資格情報のローテーションとシークレット管理

侵害後は、すべての長期資格情報をローテーションすべきです。攻撃者は資格情報を抜き取っている可能性が高いためです。APIトークン、サービスアカウントのパスワード、SSHキーなど、漏洩した可能性のある認証情報はすべて更新します。

範囲は広く捉え、クラウドプロバイダーのキーやデータベースのパスワード、内部APIエンドポイント、サードパーティのトークンも含めて見直す必要があります。複雑な環境では、サービスの停止や影響を最小限に抑えつつ、セキュリティを確保するための調整が求められます。

コミュニケーションと透明性

対応策や教訓をissueトラッカーや公開フォーラムに公開し、他の組織や開発者が学べるようにすることも重要です。透明性は、攻撃の理解と自己防衛に役立ち、責任とセキュリティへのコミットメントを示すものです。Ultralyticsチームの事故対応中のオープンなコミュニケーションは、責任ある情報開示とコミュニティ重視のセキュリティの良い例です。攻撃の詳細や修復の過程を共有することで、他のプロジェクトも学び、セキュリティを強化できます。

サプライチェーンセキュリティの未来

根本的な課題

Ultralytics攻撃は、現代ソフトウェア開発における根本的な緊張関係を浮き彫りにしました。自動化と統合は強力な一方で、完全な安全性を確保するのは難しい攻撃対象を生み出します。オープンソースの協力と信頼関係を利用した開発の特性も、攻撃者にとっては攻撃の機会となっています。

これらの問題は、単一のセキュリティ対策やベストプラクティスだけでは解決できません。継続的な警戒、深層防御、そしてサプライチェーンリスクを第一級の関心事として扱うセキュリティ文化が必要です。組織は、セキュリティツールやトレーニング、CI/CDとサプライチェーンの脅威に特化したプロセスに投資すべきです。

新たな解決策

SBOM（Software Bill of Materials）標準は、依存関係とその由来を追跡しやすくします。再現性のあるビルドは、配布されたアーティファクトの検証を可能にします。証明フレームワークは、ソフトウェアのビルド方法と責任者の暗号証明を作成します。

GitHubなどのプラットフォームは、Ultralyticsのような攻撃に対抗するための新しいセキュリティ機能を導入しています。これには、ワークフロートリガーの改善、秘密情報管理の強化、不信頼コードと特権操作の隔離などが含まれます。ただし、セキュリティと開発者の利便性のバランスを取ることは継続的な課題です。

結論：業界への警鐘

Ultralytics YOLOに対するGitHub Actionsのスクリプトインジェクション攻撃は、現代サプライチェーンセキュリティの理解において重要な転換点となりました。攻撃者は、単純な資格情報窃盗やタイポスクワッティングを超え、自動化システムの高度な悪用に進化しています。

この事件は、暗号通貨マイニングだけでなく、CI/CDシステムの設計、依存関係の管理、信頼できる自動化のあり方に根本的な脆弱性を露呈しました。既存の脆弱性が再び悪用されるリスクを考えると、セキュリティの維持は容易ではありません。

開発者、セキュリティチーム、組織は、常に警戒を怠らず、深層防御を徹底し、すべての自動化と統合のセキュリティに疑問を持つ必要があります。今後もUltralyticsの教訓を踏まえ、ソフトウェアの構築・展開・利用の方法を見直すことが求められます。そうしなければ、すべての依存関係と自動化が潜在的なバックドアとなるリスクを抱え続けることになるのです。

---

Adnan KhanやTrail of Bits、ReversingLabs、Open Source Security Foundationなどのセキュリティ研究者や団体の情報を追い、最新の脅威とベストプラクティスを学びましょう。あなたの警戒心が、明日の侵害を防ぎます。