広く利用されているAI開発ライブラリが最近のサプライチェーン攻撃で侵害され、多数のシステムがリスクにさらされた可能性がある。
PyPI上の悪意あるLiteLLMパッケージにはバックドアが仕込まれ、開発環境と本番環境の双方から認証情報、トークン、インフラの機密データをひそかに窃取できるようになっていた。
「LiteLLMの侵害は、サプライチェーン攻撃がいかに急速に拡大し得るか、そして既知の脆弱性だけに頼っていると、私たちがいかに盲目になってしまうかを示している」と、Point WildのChief Technology & AI Officer、Dr. Zulfikar Ramzan氏はeSecurityPlanetへのメールで述べた。
「このインシデントは、組織が依存関係グラフをどう扱うべきかについて、より幅広い議論を迫るものだ。ゼロトラストはユーザー、デバイス、ネットワークに適用されてきた。依存関係にも同じ厳格な検証が必要だ」と、Suzu LabsのSenior Director of Secure AI Solutions & Cybersecurity、Jacob Krell氏はeSecurityPlanetへのメールで述べた。
「ローカルでのハッシュ検証や『ロックファイル』なしにパブリックリポジトリへ依存する業界の現状は、インターネットを未検証の本番依存関係へと事実上変えてしまっている。だからこそ、私たちはこの問題を重視すべきだ」と、Xcape, IncのSr. Security Engineer、Noelle Murata氏はeSecurityPlanetへのメールで述べた。
「大局的な問題は、ソフトウェアサプライチェーンが依然として暗黙の信頼に頼りすぎており、不変性や検証が不十分なまま構築されていることだ」と、AppOmniのCISO、Cory Michal氏はeSecurityPlanetへのメールで述べた。
LiteLLMのサプライチェーン攻撃の内部。
この攻撃の標的となったLiteLLMは、約9,500万件の月間ダウンロード数を誇るオープンソースライブラリで、単一のインターフェースを通じて複数のLLMプロバイダーにリクエストを振り分ける。
LiteLLMは本番環境やクラウド環境で広く使われているため、APIキー、クラウド認証情報、Kubernetes構成などの機密データにアクセスできることが多い。
研究者は、この攻撃をTeamPCPによるものと特定している。同グループは、TrivyやKICSなどを巻き込んだ最近のサプライチェーン侵害にも関与している。
バックドアが配布された方法。
悪意あるコードはPyPIの配布物に注入された一方、GitHubリポジトリはクリーンな状態に保たれていた。つまり、ソースコードを確認した開発者には不審な点が何も見えなかったが、インストールされたパッケージにはバックドアが仕込まれていた。
このインシデントは、ソフトウェアサプライチェーンの重大な弱点を浮き彫りにしている。多くの組織は、配布された成果物が上流のソースと一致することを独自に検証せず、パッケージレジストリを信頼している。
多段階攻撃の内部。
インストールされると、マルウェアは隠密性と永続化を狙った多段階の実行チェーンを用いる。
最初のトリガーは一見単純で、注入された小さなコード断片が、影響を受けたモジュールのインポート直後に隠されたペイロードを復号して実行する。
攻撃者はさらに、悪意ある.pthファイルを含めることで手法を高度化した。このファイルにより、LiteLLMが直接使われていない場合でも、Pythonインタープリターが起動するたびにペイロードが自動実行される。
これにより被害の範囲が拡大し、あらゆるPythonの実行が侵害の潜在的な起点となる。
実行後、マルウェアは連携した3つの段階を経て動作する。
まず、オーケストレーター・スクリプトが攻撃チェーンを準備して起動する。
次に、認証情報を窃取するコンポーネントがホストから機密データを体系的に収集する。対象にはSSHキー、クラウドプロバイダーの認証情報、Kubernetesシークレット、.envファイル、データベース構成、その他価値の高い成果物が含まれる。
最後に、マルウェアはシステムレベルのバックドアをインストールして永続化を確立し、攻撃者が管理するインフラへ定期的に接続して追加のペイロードや指示を受け取る。
この攻撃は単純なデータ窃取にとどまらず、拡大を意図して設計されている。
マルウェアはKubernetesでラテラルムーブメントを可能にする。ノード間に特権Podを展開し、攻撃者のアクセス範囲を拡大する。
窃取されたデータは、攻撃者が管理するドメインへ流出させる前に暗号化されるため、検知がより困難になる。
ソフトウェアサプライチェーンのリスクを軽減する。
侵害されたLiteLLMパッケージにさらされた可能性のある組織は、リスクを評価し、潜在的な被害を封じ込めるため、速やかに対応すべきだ。
攻撃の規模と、認証情報の窃取および永続化に重点を置いていることを踏まえると、標準的な修復手順だけでは不十分な可能性がある。
セキュリティチームは、影響を受けた環境を侵害された可能性があるものとして扱い、当面のクリーンアップと長期的な強化の両方を優先すべきだ。
- 侵害されたLiteLLMのバージョンを削除、再インストールする。確認済みのクリーンなバージョンを使い、インプレースでのクリーンアップではなく、信頼できるベースラインから影響を受けたシステムを再構築する。
- 永続化の仕組みと侵害の痕跡を探し、不審なsystemdサービス、予期しないファイル、権限のないKubernetes Podや特権ワークロードなどを確認する。
- 露出したすべての認証情報をローテーションし、無効化する。クラウドトークン、APIキー、SSHキー、アクティブなセッションを含め、IAMロールとシークレットへのアクセスを監査し、不正利用の兆候を確認する。
- CI/CDパイプラインと開発環境を監査して下流での侵害がないか確認し、パイプラインのシークレットをローテーションするとともに、認証情報の漏えいや異常な活動がないかログを確認する。
- ネットワークとシステムの挙動を監視し、異常な外向き通信、定期的なビーコン通信、異常なプロセス実行パターンなど、流出やラテラルムーブメントの兆候を確認する。
- 強化しサプライチェーンセキュリティ、依存関係を固定し、上流のソースと照合してパッケージを検証し、信頼できる公開方式を利用するとともに、環境全体でSBOMを可視化する。
- 定期的にテストしインシデント対応計画、ソフトウェアサプライチェーン攻撃のシナリオを想定した机上演習を行う。
これらの対策を組み合わせることで、組織はサプライチェーン攻撃へのレジリエンスを高め、侵害された依存関係や隠れた脅威への露出を抑えられる。
信頼されたツールが標的に。
LiteLLMのインシデントは、攻撃者がすでに機密システムやデータへアクセスできるツールに、ますます焦点を当てるようになっている大きな流れを反映している。
このように信頼度の高いコンポーネントを標的にすれば、脅威アクターは従来の防御を容易にすり抜け、環境内で影響範囲を拡大できる。
また、攻撃が複数のエコシステムにまたがり得ることも浮き彫りにしている。TeamPCPのようなグループは、ある侵害で窃取した認証情報を利用して、CI/CDパイプライン、パッケージレジストリ、そして今やAIツールに至るまで、次の攻撃を可能にしている。
組織にとってこれは、ソフトウェア依存関係の完全性を継続的に検証する必要性を改めて示すものだ。
このようなゼロトラストアプローチは、現代のサプライチェーン攻撃に対する防御の強化に役立つ。