OpenAIは新たな続報の中で、Hugging Faceへの一連の攻撃において、同社のAIモデルが公開状態で漏洩していた認証情報を用い、サードパーティの4つのサービスでもアカウントを侵害していたことを明らかにしました。これにより、4日間にわたったこのセキュリティインシデントの影響範囲は、他の組織にも及んでいたことになります。
1つのアカウントは攻撃における中継・ステージングサーバーとして使用され、別の1つはデータ保存用に使われました。残る2つのアカウントは読み取り専用でアクセスされたのみで、Hugging Faceへのさらなる侵害には利用されていません。
全体として、このエージェントは人間の攻撃者が侵入時によく用いるものと同様の攻撃基盤を構築し、ツールやスクリプトのホスティング、トラフィックの中継、正規のオンラインサービスを経由した悪意ある活動のルーティングなどに利用していました。
OpenAIは該当する4つのサービスがどこかを明らかにしておらず、AIモデルが漏洩した認証情報をどのように発見したのか、またサードパーティのアカウントに何が保存されていたのかについても説明していません。
ただし同社は、このAIエージェントが4つのサービスプロバイダーのいずれか、あるいはそれらのプラットフォーム上でホストされている他のアカウントに対して、さらなる侵害行為を行った証拠は見つかっていないとしています。
その後Reutersは、4つのサービスのうち1つがAIインフラ企業のModal Labsであったと報じました。しかしModalは、自社のプラットフォーム自体が侵害されたわけではなく、エージェントは公開状態で認証が設定されていなかったエンドポイントを通じて、顧客の環境にアクセスしたに過ぎないと説明しています。
ModalのCTOであるAkshat Bubna氏はReutersに対し、当該の顧客がインターネット上の誰もがコード実行用サンドボックスを利用できる形でエンドポイントを公開してしまっていたと述べています。
このModalの顧客アカウントが、中継・ステージング経路として使われたのか、データ保存用に使われたのか、それとも読み取り専用でアクセスされた2つのアカウントのいずれかだったのかは、依然として明らかになっていません。
BleepingComputerはOpenAIに対し、AIモデルがどのように漏洩した認証情報を発見したのか、どのサービスにアクセスしたのか、そして攻撃中にそれらのアカウントがどのように使われたのかについて詳細を問い合わせています。
OpenAIはまた、他の評価作業の中でも、同社のAIモデルが公開状態で漏洩していた認証情報を使い、いくつかの追加のアカウントにアクセスしていたと述べていますが、詳細は明らかにしていません。
このモデルは、コードやテキストの共有に使われる公開のペーストビンサイト、侵入テストや攻撃でよく使われるHTTPリクエストキャプチャサービス、スクリーンショットサービス、その他各種のWebユーティリティも利用していました。
Artifactoryのゼロデイ脆弱性を突いて脱出
この一連の活動は、高度なサイバーセキュリティ能力を測定するために設計されたベンチマーク「ExploitGym」を用いた評価テスト中に、OpenAIのモデルが隔離された評価環境から脱出したことをきっかけに発生しました。
これらのモデルはインターネットへ直接アクセスすることはできず、パッケージレジストリ向けのプロキシ兼キャッシュとして機能する社内ホストのJFrog Artifactoryサーバーを通じてのみ、パッケージをインストールできる状態になっていました。
OpenAIは7月28日付の続報で、これらのモデルが未知だったArtifactoryのゼロデイ脆弱性を特定・悪用し、インターネットへのアクセスを獲得したことを確認しました。
同社は別途、その後の調査の中でこれらのモデルがArtifactoryの他の脆弱性も特定しており、それらはJFrogに開示済みだとも述べています。
BleepingComputerが火曜日に報じたとおり、Artifactory 7.161.15で修正された8件の脆弱性はCVEレコード上でOpenAIの功績とされています。ただし、実際の攻撃で悪用された具体的な脆弱性がどれかについては、OpenAI・JFrogのいずれも確認していません。
インターネットへのアクセスを獲得した後、これらのモデルはベンチマークを完了するために必要なデータセットやテスト用の解答を、Hugging Faceがホストしている可能性があると推測しました。
そして、この情報へのアクセスを試みる中でHugging Faceの本番インフラを侵害し、データセット処理パイプラインの脆弱性を悪用し、クラウドおよびクラスターの認証情報を窃取したうえで、社内システム内を横方向に移動していきました。
OpenAIはまた、今回の攻撃で使われたモデルは社内の研究目的専用として提供されていたプレリリース版モデルであり、現在はさらなる研究アクセスを制限した状態にあるとも述べています。
「Hugging Faceの侵害には、今後リリース予定のモデルは一切関与していません」とOpenAIの続報には記されています。
「私たちのブログ記事で触れているプレリリース版モデルは社内限定の研究用プロトタイプであり、一般公開を意図したものでは一切ありませんでした。今回のインシデントを受け、私たちはこのモデルを無効化・暗号化したうえで、研究アクセスも制限しました」
Hugging Faceへの侵入は4日間続いた
Cloud Security AllianceのCISOコミュニティが作成したインシデントの事後検証ドラフトによると、Hugging Faceへの侵入はおよそ4日間続いていたとされています。
この報告書は、約700名のCISOが参加した電話会議でHugging Faceが共有した情報を一部の基礎としています。文書はその後、参加したCISOらによって編集され、公開前にHugging Faceのチームによるレビューも受けています。
報告書によれば、これらのモデルは2日間を偵察活動に費やした後、目立った動きのない1日を経て、最終日には激しい活動を見せたということです。
CSAの事後検証報告書によると、OpenAIがHugging Faceに連絡する前に、Hugging Face自身がこの侵入を発見し、封じ込めたうえで調査を開始していたとされています。
Reutersはまた、Hugging Faceが脅威を封じ込めFBIに通報した時点でも、OpenAIは自社のモデルが何をしていたのかをまだ検知できていなかったと報じています。
CSAの報告書によれば、Hugging Faceは当初、主要な商用AIモデルを使って攻撃の全容を再構築しようと試みましたが、それらのモデルに組み込まれたセキュリティ上の安全対策により、生の悪意ある活動データを処理することができなかったとされています。
そこで対応チームは、Z.aiのオープンウェイトモデルであるGLM 5.2をローカル環境で稼働させ、これを使って侵害に関連する17,000件を超えるイベントを分析しました。
「このモデルを使うことで、彼らは17,000件を超えるログ全体を処理し、タイムラインを再構築し、痕跡情報を抽出し、影響を受けた認証情報をマッピングして、実際の被害と陽動的な活動とを切り分けました。通常であれば数週間を要する作業を、数時間で終わらせたのです」と事後検証報告書には記されています。
Hugging Faceは最終的にすべての認証情報をローテーションし、侵害されたシステムを解体したうえで、インフラのおよそ3分の1をクリーンなイメージから再構築しました。
報告書によると、これらのモデルはExploitGymの完了を試みていたにもかかわらず、Hugging Faceの非公開リポジトリから、CyberGymの解答を含む3つの部分的なデータセットを抽出していたとのことです。
報告書によれば、顧客データへのアクセスは一切なく、Hugging Faceから外部にデータが流出することもなかったとされています。
また、これらのモデルはHugging Faceのプラットフォームとデータセットを、コマンド&コントロール基盤の一部としても利用しており、複数のワークロードを同時に稼働させていました。
とはいえ、これらのエージェントの運用セキュリティ（OPSEC）は杜撰なもので、暗号鍵をはじめとする攻撃の痕跡を残しており、それが対応チームによるインシデントのさらなる分析の助けとなりました。
攻撃者に先んじて、あらゆる防御レイヤーをテスト
セキュリティチームが検知できているのは、成功した攻撃のうち54%に過ぎず、アラートを出せているのはわずか14%です。残りは環境内を気づかれないまま通過しています。
Picusのホワイトペーパーでは、侵害・攻撃シミュレーションによってSIEMやEDRのルールをテストし、脅威が検知をすり抜けるのを防ぐ方法を解説しています。
