画像を処理するだけで侵入される？ OpenAIにも侵入できた攻撃手法を解説：侵入にかかった期間は約3日

画像をアップロードするだけの機能が、攻撃者にとって格好の入り口になることがある。セキュリティ研究チームのHacktron AIは、HEIFなどの画像を処理する仕組みを足掛かりに、OpenAIのフォーラムからさらに先へ攻撃を進めた事例を公開した。なぜ「画像」がRCEにつながったのか。

[＠IT]

　セキュリティ研究チーム・スタートアップ企業のHacktron AIは、OpenAIの社内システムへと侵入できる脆弱（ぜいじゃく）性悪用手法を公開した。

　OpenAIの公開サポートフォーラムに細工したHEIF画像を投稿することで、画像デコーダーの欠陥からリモートコード実行（RCE）に至り、別のシングルサインオン（SSO）欠陥を経て、OpenAIの社内「GitHub」でプルリクエストを作成できたという。

　同研究チームは権限確認に無害なプルリクエストを使い、機密コードは読んでいないと説明している。このハッキング手法では、Anthropicの「Opus 4.8」が脆弱性の発見を担い、「Opus 5」が脆弱性を実行可能なエクスプロイトに発展させたとしている。

「画像を投稿するだけ」が攻撃の入り口になる　悪用されたライブラリは？

　画像投稿機能は、多くのWebサービスにとって当たり前の機能だ。しかし、その裏側ではアップロードされた画像を読み取り、サイズ変更や形式変換などを行うため、さまざまなソフトウェアが動いている。ここが攻撃の入り口になる可能性がある。

　Hacktron AIは、こうした画像処理の仕組みを狙う攻撃手法を「HEIF Heist」と呼んでいる。特に問題となるのが、HEIFやHEIC、AVIFといった画像を扱う「libheif」などのライブラリだ。

　今回、研究チームはOSS（オープンソースソフトウェア）のインターネットフォーラム「Discourse」が利用する画像処理機能を調査し、その過程で画像の読み込みに使われるlibheifの古い版に問題があることを発見した。

　この問題そのものは上流側で既に修正されていたが、同修正がセキュリティ修正だと明確に扱われていなかったため、利用者側で緊急の対応が必要だと認識されにくかったという。

　研究チームは細工したHEIF画像をOpenAIのコミュニティーフォーラムに投稿。画像を処理する過程でRCEに成功したとしている。

OpenAI従業員のアカウントにまで到達

　画像処理の怖さは、アップロードされたファイルを単に保存しているわけではない点にある。

　例えばHEIF画像をWebサービスに投稿すると、サーバ側ではlibheifや「ImageMagick」「libvips」「Sharp」などのソフトウェアを使って画像の中身を読み取ることがある。

　さらにlibheifのようなライブラリは、別のソフトウェアから間接的に利用される。OSのパッケージやコンテナ環境に組み込まれているケースもあり、開発者が直接libheifを導入したつもりがなくても、依存関係の中に潜んでいる可能性がある。

　Hacktron AIは、細工した画像を使って対象環境が利用しているライブラリやバージョンを探り、その環境に合わせた攻撃を仕掛ける手法を説明している。成功すれば、メモリ破壊や情報流出、最終的にはRCEにつながる可能性がある。

　研究チームはDiscourseでの発見を起点に調査を拡大。「Slack」やMetaの主要製品、「Next.js」のAVIF画像最適化機能、「GitHub Enterprise」など、画像処理を利用する複数のサービスについて、RCEや情報流出につながる事例を挙げている。

　OpenAIのケースでは、画像処理の問題だけで調査が終わらなかった。

　研究チームはフォーラムから、OpenAIの「Log in with OpenAI」に存在したSSOの欠陥も利用。ログインした利用者の「ChatGPT」や「Codex」アカウントに到達でき、OpenAI従業員のアカウントも含まれていたとしている。

　研究チームは従業員1人のアカウントを使い、Codex経由でOpenAIの社内リポジトリーに無害なプルリクエストを作成した。OpenAIは報告から約14時間後にSSOの問題を修正し、6500ドルのバグ報奨金を支払ったという。

　ここで重要なのは、攻撃の入り口が「画像」だったとしても、最終的なリスクは画像処理だけに閉じないことだ。Webアプリや画像処理ライブラリ、認証基盤、開発環境など、複数の仕組みがつながっていると、一つの脆弱性が次のシステムへの足掛かりになる。

　Hacktron AIによると、HEIF Heistは特定の1バージョンだけを狙うものではなく、libheifの複数のバージョン系列が対象となる。対策としてlibheif 1.23.2以降や最新のlibde265への更新、不要なHEIF／AVIF処理の無効化、画像処理環境の隔離などを挙げている。

　また研究チームは、AIエージェントとフロンティアモデルを利用することで、初期調査から遠隔RCEに至るまでの期間を約1〜3日に短縮できたとしている。

　開発者にとっては、単に「脆弱性のあるライブラリを更新する」という話ではない。自分たちが直接使っていないライブラリが、画像処理やフレームワーク、OS、コンテナなどを経由して入り込んでいないかどうか。そのライブラリが突破された場合、攻撃者は次にどこへ進めるのか。そこまで含めて依存関係と攻撃経路を把握する必要があるだろう。