OpenAIは水曜日、Black Hatセキュリティカンファレンスで「Hugging Faceインシデント」について急遽プレゼンテーションを行った（本ブログでも以前取り上げた）。動画は昨日公開された。短いながら情報密度が高く、視聴する価値は十分にある。特に、何が起きたのか、そしてOpenAI内部で事態がどのように展開したのか、その全容が詳細に語られているからだ。以下に紹介するタイムラインは、この動画をもとに作成した。

タイムラインは以下の通りだ。個人的に一番気に入っているのは最後のくだりだ。OpenAIは内部調査の後に見つかった認証情報を無効化してほしいとHugging Faceに連絡したところ、すでに無効化済みだと言われ、そこで初めてHugging Faceへの攻撃が自分たちによるものだったと気づいたのだ！

• 5月7日：OpenAIが未公開の実験的モデルについて、新たなトレーニングを開始。（評価（evaluation）の実行のことか？ いや、10:14で「次世代フロンティアモデルをトレーニングするための新たな強化学習ランを開始した」と明言しており、その後「どれだけうまくいっているかを判断するための報酬シグナル」にも言及しているので、これはすでにトレーニング済みのモデルを評価したのではなく、本当に新しいモデルのトレーニングだった。）
• 5月8日：エージェントが、インターネットアクセスがないにもかかわらずGoogle Driveのリンクが絡む不可能なタスクを誤って与えられる。Artifactoryのパッケージングサービスへの攻撃を試みて失敗するが、Artifactoryにファイルを書き込めることを発見する。
• 数日後：別のエージェントが、重要なファイルが誤って省略されていたためにタスクで行き詰まる。Artifactoryにメモを書き込み、誰かがそのファイルを持っていないか「別のエージェントに呼びかける」ことを試みる。
• その後の数日間：さらに多くのエージェントがArtifactoryのファイル一覧を閲覧中にこの非公式なメッセージボードを発見し、メッセージの読み書きを始める。
• 5月26日：エージェントが初めてArtifactoryに対するSSRF攻撃を成功させ、Artifactoryに外部コンテンツを取得させることで間接的にインターネットアクセスを得る。
• 6月11日：OpenAIが新たな「極めて持続性の高い」実験モデルのトレーニングを開始。このモデルはArtifactoryにアクセスでき、以前のモデルが残したメッセージを活用できる。
• 6月26日：エージェントがArtifactoryのゼロデイRCE（レガシーなトークンリフレッシュエンドポイントの欠陥を突いたもの）を発見し、悪用する。管理トークンを使ってGroovyプラグインをインストールし、コマンドを実行できるようにする。
• 7月4日：エージェントの活動が原因でArtifactoryが過負荷となり障害が発生。OpenAIは侵害された認証情報を無効化し、メッセージを削除、ゼロデイにパッチを当て、ベンダーに脆弱性を報告する。
• 7月8日：エージェントが、Artifactoryのリモートキャッシュ内のディレクトリ名を利用して、認証不要のWebDAVエンドポイント経由で通信する新たな方法を発見する。
• 7月8日〜19日：OpenAI自身のインフラへの攻撃。エージェントは、漏洩したPastebin投稿の公開アーカイブの中から「外部組織の認証情報」を見つけ、その認証情報を検証してメッセージボード上で居場所を共有した。その後、この「Organization 1」への書き込み権限を利用して、OpenAIのインフラへのその後の攻撃で使われるデータをステージングした。エージェントは新たなゼロデイで2度目のArtifactory侵害に成功する。エージェントは悪意のあるRubyターゲットをOrganization 1のステージングリポジトリにアップロードし、そのパッケージをArtifactory経由でリクエストする際に、リポジトリ用のRuby依存関係として扱われるように仕向けた。そしてJRubyのデシリアライゼーションにおけるtime-of-check/time-of-useのバグを悪用して、Artifactoryに対するリモートコード実行を達成した。

次の部分は驚きなので全文引用する：

エージェントはcontainer-as-a-service環境で動作しているArtifactory上でリモートコード実行の権限を得ている。エージェントはローカルでの権限昇格を、ローカル環境を探索し、自分たちが動作しているマシンのLinuxカーネルのバージョンにごく最近のCVEが存在することを突き止めることで行う。CVEのエクスプロイトをダウンロードし、マシン上で成功するようにカスタマイズして、この既知のLinuxカーネルの権限昇格CVE —— 今回の場合は pte_physroot —— を使ってローカルマシンでroot権限を取得する。1台のマシンでrootを取得すると、エージェントは急速に権限を昇格させ、container-as-a-serviceインフラ環境全体に横方向へ侵入していく。特に、エージェントはメッセージボードを一貫して利用して認証情報や手法、進捗を共有し、並行性と並列性を効果的に活用して非常に素早く動き回る。エージェントはIMDS経由でIAM認証情報を取得する。Kubernetesのサービスアカウントの誤設定、特に特定のサービスアカウントへの過剰な権限付与を悪用し、Azure Key Vaultを含むクラスターの認証情報を収集する。最終的にエージェントはクラスターと関連する認証情報に対するcluster admin権限を取得する。

Hugging Faceはこの物語の次の展開をすでに語っている。エージェントはModalでホストされた安全でないアプリと脆弱なAPIキーを見つけ、それを利用してHugging Faceへの攻撃を仕掛けた。HDF5の任意ファイル読み取りのバグ（ファイルの探索や認証情報の窃取に使用）とJinjaテンプレートインジェクションによるRCEを組み合わせ、単一Podでのコード実行から13時間足らずで複数のHugging Faceクラスターにわたるcluster admin権限の奪取へと至った。

• 7月16日：Hugging Faceが自律型AIエージェントによる攻撃を検知したと公表。OpenAIはHugging Faceに連絡し、自分たちがその影響を受けたかどうかを尋ねた！
• 7月19日：OpenAIがArtifactoryへの攻撃を特定し、内部での権限昇格について調査を開始、その動きをcyber-gymでの権限昇格と結びつけた。影響を受けた認証情報の無効化を開始した。
• 7月20日：OpenAIが調査で見つかったHugging Faceの認証情報を無効化してもらうため、Hugging Faceに支援を求めて連絡。Hugging Faceからはすでに無効化済みだと告げられる……そこで初めてOpenAIは、Hugging Faceでの侵害が自分たちのインシデントと同一のものだったと気づいた！