Hugging FaceにAI主導のサイバー攻撃 防御もAIで対抗するも、商用モデルは解析拒否で「GLM」採用

Hugging Faceは、自律型AIエージェントによる本番インフラへの侵入を検知、対処したと発表した。一部の内部データセットと複数の資格情報への不正アクセスを確認した。ログ解析には当初商用AIを使ったが、安全ガードレールに阻まれたため、最終的にオープンウェイトモデル「GLM 5.2」を自社インフラで実行して解析した。

[ITmedia]

　米AIプラットフォームのHugging Faceは7月16日（現地時間）、本番インフラの一部が自律型AIエージェントによるサイバー攻撃を受けたと発表した。侵入の検知と解析にAIを活用したが、商用のフロンティアモデルはガードレールによって解析作業を受け付けなかったため、最終的に中国Z.aiのオープンウェイトモデル「GLM 5.2」を自社インフラ上で実行して対応したという。

　一部の内部データセットと、サービスで使用する複数の資格情報への不正アクセスを確認した。パートナーや顧客のデータへの影響は調査中で、影響が判明した場合は当事者に直接連絡するとしている。公開されているモデル、データセット、Spacesの改ざんや、コンテナイメージや公開パッケージなどソフトウェアサプライチェーンへの影響は確認していない。予防措置として、ユーザーにはアクセストークンのローテーションと最近のアカウントアクティビティの確認を呼び掛けている。

　侵入の起点となったのは、AIプラットフォーム特有の攻撃面であるデータ処理パイプラインだった。悪意あるデータセットが、リモートコードを実行するデータセットローダーと、データセット設定のテンプレートインジェクションという2つのコード実行経路を悪用し、処理ワーカー上でコードを実行。そこからノードレベルの権限に昇格して、クラウドとクラスタの資格情報を収集し、週末の間に複数の内部クラスタへ侵害を広げた。

　攻撃を実行したのは、セキュリティリサーチ用のエージェントハーネス上に構築されたとみられる自律型エージェントフレームワークで、多数の短命なサンドボックス群を使って数千件規模のアクションを実行したほか、C2基盤を公開サービス上を移動させながら設置していた。攻撃に使われたLLMは特定できていないという。同社はこれを、業界が予測してきた「エージェント型攻撃者」シナリオに合致するものだとしている。

　対策として、初期侵入に使われた脆弱性の修正、侵害されたノードの再構築、影響を受けた資格情報の失効・ローテーション、クラスタへの追加ガードレールと管理制御の導入、検知・アラート体制の改善などを実施した。外部のフォレンジック専門企業と協力して調査を進めており、法執行機関にも報告済みとしている。

　防御側でもAIが中心的な役割を果たした。侵害を最初に検知したのは、LLMベースのトリアージを組み込んだ異常検知パイプラインで、その後の解析では、1万7000件を超える攻撃者の行動ログをLLM駆動の解析エージェントに読み込ませ、タイムラインの再構築や侵害された資格情報の特定、陽動行為の切り分けを実施。通常なら数日かかる作業を数時間で完了したという。

　ただし、この解析に使うモデルの選択には想定外の制約があったという。解析には実際の攻撃コマンドやエクスプロイトのペイロードを大量にモデルに投入する必要があるが、商用APIのフロンティアモデルではこれらのリクエストがプロバイダーの安全ガードレールにブロックされた。ガードレールは、インシデント対応者と攻撃者を区別できないためだ。そこで同社は、オープンウェイトのGLM 5.2を自社インフラで実行して解析を完了した。攻撃者のデータや資格情報が自社環境の外に出ないという副次的な利点もあったとしている。Hugging Faceのクレマン・ドラングCEOはXに「攻撃者が回避している可能性が高いと知りながら、防御側としてガードレールに阻まれるのは非常に怖いことだ」とポストした。

　今回の発表からは、AI主導の攻撃ツールがもはや理論上の脅威ではなくなったことに加え、攻撃者は利用ポリシーに一切縛られない一方で、防御側のフォレンジック作業がホスト型モデルの安全機構に阻まれるという「非対称性」の問題が浮かび上がった。同社は防御側への実践的な教訓として、インシデント発生前に自社インフラで実行できるモデルを検証・準備しておくことを挙げつつ、これはホスト型モデルの安全対策に反対するものではないとし、該当プロバイダーにフィードバックを共有しているという。