レポート 7909
ChatGPT Operatorは、OpenAIが開発した研究プレビュー版エージェントで、ChatGPTがウェブブラウザを使用できるようにします。視覚と推論能力を用いて、トピックの調査、旅行の予約、食料品の注文といったタスクを実行しますが、この記事で示すように、あなたのデータを盗むことも可能です！
現在、ChatGPT OperatorはChatGPT Proユーザーのみが利用できます。私は試用するために 、1ヶ月間200ドルを投資することにしました。
リスクと脅威
OpenAIは、Operator System Cardで3つのリスクカテゴリを挙げています。
- ユーザーの意図が誤っている（ユーザーが有害なタスクを要求する）、
- モデルの意図が誤っている（モデルが有害な誤りを犯す）、
- Webサイトの意図が誤っている（Webサイトが何らかの形で悪意を持っている）。
私の研究をご存知の方なら、私がプロンプトによる脅威をどのように捉えているかお分かりいただけるでしょう。私のプレゼンテーションのスクリーンショットを添付します。
参考までに、プロンプトインジェクションに関するChaos Communication Congressでの講演をこちらにご紹介します。[https://www.youtube.com/watch?v=qyTSOSDEC5M&t=333s)
OpenAIの見解に戻りますが、私の唯一のフィードバックは、「ミスアライメント」という用語の使いすぎです。この表現では深刻さが軽視されがちですが、これらは機密性、完全性、可用性に深刻な影響を与える実際の攻撃になり得るのです。この点については、この記事で詳しく説明します。
とはいえ、OpenAIがリスクと脅威の観点から同じ考え方をしていることは素晴らしいことです。これこそまさに脅威モデリングの実践例と言えるでしょう。
対策と防御策
私が確認した実用的な対策は多層構造になっており、テスト中に遭遇した主な手法は以下の3つです。
対策1：ユーザー監視
ユーザーは、 オペレーターの操作内容、入力したテキスト、クリックしたボタンなどを「監視」するよう促されます。
この画面がどのページに表示されるかは不明です。今のところ、主にGitHubとOutlookでテストしましたが、特定のドメイン名ではなく、画面上のユーザー個人情報（PII）などを検出するデータ分類モデルに基づいていると思われます。
対策2：インライン確認リクエスト
チャット会話の中で、オペレーターはユーザーに特定のアクションを実行するかどうか、または確認を求める場合があります。
上記のスクリーンショットでは、完全なプロンプトインジェクション攻撃が確認できます。この攻撃では、Operatorが乗っ取られ、「ステータス設定」ページが開かれ、攻撃者が制御するテキストがステータスバーに入力されます。しかし、「ステータス設定」をクリックする前に、チャット内に確認メッセージが表示されます。
特筆すべき点として、このプロンプトインジェクション攻撃を初めて試した際、ステータス設定時に確認メッセージが表示されなかったことが挙げられます。 しかし、2回目以降は再現できませんでした。
対策3：帯域外確認要求
これらの確認要求は、オペレーターがウェブサイトの境界を越えて移動し、複雑な要求を含むアクションを実行する際 に発生するのが一般的です。これは最も煩わしい確認ダイアログであり、ユーザーは操作を一時停止または再開するオプションを選択できます。
上記のスクリーンショットは、私が受け取った最も詳細なメッセージを示しています。このメッセージでは、これから何が起こるのか、そしてなぜダイアログが表示されるのかがユーザーに正確に伝えられます。しかし、多くの場合、確認メッセージは非常に一般的なもので、ウェブサイトにオペレーターの指示と矛盾する指示が含まれている可能性があるという内容です。そのため、どのウェブサイトの指示やコンテンツが悪意のあるものである可能性があるのかが不明確です。
この確認ダイアログが表示される前に、確認画面が表示されるまでに目立った遅延（場合によっては20秒以上）があります。そのため、ユーザーに確認を求めるかどうかを判断するために、おそらくバックグラウンドで他の推論処理や検証が行われていると考えられます。
さらに、HTTPリクエストとレスポンスには、プロンプトインジェクションモニターに関するデータ構造が含まれています。つまり、APIはモニターに関してクライアントに多くの情報を送信しているということですが、詳細な調査は行っていません。
AIを信用するな ― 今もなお真実
オペレーターを完全に信用できないことは明らかであり、これらの対策（必要不可欠）は自律型エージェントの創出を阻止するだろう。まだ読んでいない方は、プロンプトインジェクションとCIAトライアドに関する私の論文をぜひ読んでみてください。
プロンプトインジェクションのリスクは依然として大きな懸念材料であり、実に残念なことだ。誰もが、自分たちの代わりに仕事をしてくれる、信頼できる自律システムを望んでいるはずだ。
エージェントが完全に自律的であるよりも、より協調的な方法でエージェントと協働していく可能性は高いように思われる。
関連情報: Anthropic Claudeの同様の「コンピュータ使用」機能が、高度なC2（コマンド＆コントロール）のようなシナリオにどのように悪用されるかにご興味があれば、「ZombAIs」に関する私の投稿をご覧ください。
Operator：プロンプトインジェクション攻撃デモ
それでは、Operatorのプロンプトインジェクション攻撃についていくつか見ていきましょう。プロンプトインジェクションモニターが悪意のある攻撃者によって回避される可能性があることを示すために、私は3週間ほど前にOpenAIにデモをいくつか共有しました。これは、OpenAIが事前にこの手法を認識し、対策を講じられるようにするためです。
セットアップ - 巧妙なシナリオ
私が重点的に検証したかったシナリオは、Operatorがユーザーがログインしている別のサイト に移動し、そこからデータ（理想的には個人情報）を漏洩させるというものでした。基本的なエクスプロイトデモシナリオは、ユーザーのメールアドレス、自宅住所、電話番号などの個人プロファイル情報をサイトから漏洩させることで、すぐに作成できました。
調査中に、Operatorがハイパーリンクを容易にクリックすることに気づきました。リンクをクリックすることに非常に積極的であるようです！
次に気づいたのは、Operatorがフォームを送信する際、コンテキストに応じた質問、あるいは前述のUI確認ダイアログといった形で確認画面が表示されることが多いということです。そのため、Operatorに直接「更新」ボタンをクリックさせようとしても、うまくいきませんでした。
巧妙なデータ漏洩
しかし、テキストを入力するだけでは、確認画面が表示されることはほとんどありません。
この知識を基に、フォーム送信やボタンクリックを必要とせずに、ユーザーが入力した内容をそのままサーバーに送信するウェブページをサードパーティサーバー上に作成しました。
今思えば、これを作ったのは少し後ろめたい気持ちです。しかし、ウェブサイトに情報を入力するだけで、送信ボタンを押さなくても、入力した情報がウェブサイトに盗まれる可能性があることをユーザーが理解しておくことは、決して珍しいことではありません。
このツールの狙いは、Operatorを騙してこのページを使って問題を解決させることですが、実際にはデータが漏洩しているだけです。
攻撃のポイントを繋ぐ…
まだ計画が分からないという方のために、TTP（戦術、技術、手順）を簡単に説明します。
- ウェブサイト上のテキストプロンプトインジェクションを利用してOperatorを乗っ取ります。
- 認証済みのユーザー設定ページへ移動させます。
- そのページから個人情報（PII）をコピーさせます。
- そして、
- 上記のデータ漏洩対策ウェブサイトにコピーした情報を貼り付けるか入力します。
この攻撃を実証するために、The Guardian、YC Hacker News、Booking.comなど、いくつかの異なるページで試してみました。そして、すべてで成功しました。この方法を選んだ理由は、「送信」ボタンが、前述のプロンプトインジェクション対策の一つを頻繁にトリガーするからです。
この説明では、最も単純なシナリオ、つまり管理者のみがアクセスできるYC Hacker Newsユーザーのメールアドレスを漏洩させるシナリオを使用します。
デモ用センチネルアカウントの情報はこちらです：
注：これは対象サイトのいずれにも存在する脆弱性ではありません。しかし、ウェブサイトはそもそも「善意の」AIが特定の機密サイトにアクセスすることをブロックできるべきなのか、という興味深い疑問を提起します。もしかしたら、User-Agent属性でクライアントがAIエージェントであることを示すべきでしょうか？
それでは、プロンプトインジェ クションの詳細を見ていきましょう。
プロンプトインジェクションペイロードのホスティング
プロンプトインジェクションペイロードは、GitHubのイシューとしてGitHub上にホストされています。これは攻撃の現実的なシナリオと言えるでしょう。なぜなら、ほとんどのGitHubプロジェクトでは見知らぬ人がイシューを作成でき、AIエージェントがGitHubイシューの読み取りと処理にますます利用されるようになるからです。
使用されたGitHubイシューは以下のとおりです。
開発者がGitHubイシューを操作する様子をシミュレートするため、最初はURLをOperatorに貼り付けました。「このGitHubイシューを調査する」などのフレーズを入力した場合も同様に動作しました。ユーザーのプロンプトによって成功率は異なります。ここで重要なのは、攻撃と防御の両方が確率に基づいているということです。
Operatorのハイジャック
OperatorはGitHubイシューに積極的にアクセスし、支援活動を開始します。悪意のある「combine」ツールを検出すると、ほとんど躊躇することなくリンクをクリックし、該当ページに移動します。
いくつかのテスト中に、テキストボックスにテストメッセージが書き込まれ、それがすぐにサードパーティサーバーに送信されるという現象が発生しました。
ここからが興味深い部分です。オペレーターはGitHubのイシューに戻り、メインタスクであるnews.ycombinator.comのアカウント設定ページ にアクセスし、非公開のメールアドレスをコピーした後、悪意のあるウェブページに戻ってデータを貼り付けます。これにより、攻撃者は情報を受け取ることができます。
以下は、YC Hacker Newsデモの主要な手順の一部を示す画像です。
オペレーターはユーザーのメールアドレス（非公開）を取得し、データ漏洩フォームに貼り付けます。
これで攻撃者はデータを手に入れました！驚きです。上記の解説が分かりにくかった場合は、エンドツーエンドの動画をご覧ください。
この手法は様々なウェブサイトで有効です。例えば、booking.comでは、プロンプトインジェクションによってOperatorが乗っ取られ、住所や電話番号などのユーザーデータが漏洩します。
Operatorがどのような動作をするかを綿密に監視することは、現時点では非常に重要です。ブラウザがウェブサイトに対して認証されている場合、恐ろしい事態が発生する可能性があります。
確率的防御
デモは初回で成功する場合もありますが、プロンプトインジェクションは100%確実なものではなく、防御策も同様です。多くの緩和策 は確率的防御として機能し、リスクを軽減しますが、完全に排除するものではありません。これらのデモは代表的なものであり、網羅的なものではありません。
緩和策は通常、危険な動作が行われる直前に発動することが観察されました。つまり、プロンプトインジェクション自体を防ぐのではなく、危険な動作を検出することに重点が置かれているということです。これは、プロンプトインジェクション自体に対する根本的な解決策がないことを強調しているようです。エージェントは、企業における潜在的に悪意のある内部関係者のような存在になり得ますが、個人利用に関しては、まだ適切な例えが見つかっていません。
影響
このデモンストレーションには、いくつかのより広範な影響があります。
- ユーザーのプライバシーとセキュリティ
オペレーターは悪意のあるサイトへのアクセスを誘導される可能性があり、フィッシングのリスクが浮き彫りになります。適切な対策が継続的に講じられていない場合、機密性の高い個人情報を含むユーザーの個人データが意図せず漏洩する可能性があります。メインのメールアカウントなど、機密性の高いウェブサイトへのアクセス権をオペレーターに与えることはお勧めしません。実験には別のアカウントを使用するか、ユースケース専用のアカウントを作成することを検討してください。
-
サーバーサイドソリューション：プライバシーとセキュリティに関する追加的な懸念 さらに、オペレーターのセッションはサーバーサイドで実行されます。これはつまり、技術的にはOpenAIのスタッフ が入力されたすべてのデータ、セッションクッキー、認証トークンなどにアクセスできることを意味します。Operatorホスト上ではカスタムのOperator Chrome拡張機能とローカルWebサーバー（例えば
http://localhost:8080/events）が稼働しています。これらのエンドポイントが具体的に何に使われているのかは不明ですが、おそらく一部はテレメトリデータを収集していると思われます。これに関するドキュメントは見つかりませんでした。 -
より安全なAIエージェントの設計と改良
プロンプトインジェクションを回避する可能性を低減するために、これらの対策を改良することが重要です。私のテストでもプロンプトインジェクションモニターが作動したため、数日待ってから再度試しました。しかし、モニターは私が実行した攻撃をまだ学習しておらず、私の側で学習が進むにつれて攻撃ペイロードがさらに洗練されていったため、再試行は最初は成功することが多かったのです。防御が強化されるにつれて、攻撃も強化されます。さらに、これらの概念実証シナリオをOpenAIにも共有しました。
- 自動化システムとオープンソースへの信頼
プロンプトこのようなインジェクション対策の回避策は、悪意を持って悪用されると、自動化システムへの信頼を損なう可能性があります。そのため、AIエージェントがどのようにデータを検証し保護しているかについて、透明性を維持・向上させることが重要だと考えられます。プロンプトインジェクションモニターのようなものをオープンソース化することは可能でしょうか？
オペレーターに「更新」ボタンをクリックさせるテスト - 失敗！
プロンプトインジェクション攻撃中にChatGPTオペレーターに「更新」ボタンをクリックさせることで、サイト上の情報を直接変更するテストもいくつか試しました。
これらのテストは概ね失敗し、インバンド確認リクエストがトリガーされました。しかし、調査の初期段階で一度だけ成功したケースがありました。成功したシナリオは、GitHub IssueからプロンプトインジェクションによってGitHubアカウントのステータスを更新するというものでした。また、最近のアプリの中には、更新ボタンをクリックする必要がなくなり、情報を自動的に保存するものもある点にも注目すべきです。
この分野には、まだまだ調査・テストすべき点が数多くあります。オペレーターを欺く方法は、Clickjackingのような昔ながらのUIスプーフィングから、最新のLLM（リンクレベル管理）の手法まで、多岐にわたります。
###責任ある情報開示
約3週間前、私はOpenAIに対し、本記事で説明したプロンプトインジェクション監視回避策の詳細、およびbooking.comとtheguardian.comを用いた初期デモ攻撃の動画を提供しました。約1週間前までは、デモはかなり安定して動作していました。しかし、本記事で説明した特定の攻撃シナリオはもはや機能していないようです。対策の詳細は不明です。
ウェブサイト上の指示を利用してOperatorを乗っ取るために、攻撃者が利用できる回避策やトリックは他にも存在する可能性が高いことを強調しておく必要があります。そのため、Operatorの動作を注意深く監視してください。
結論
本記事では、ウェブページ上のプロンプトインジェクション攻撃によってChatGPT Operatorが乗っ取られ、個人情報が不正に漏洩する可能性があることを解説しました。
Operatorは非常にクールで便利なツールであり、そう遠くない未来を垣間見せてくれます。Operatorが探索やタスクを実行する様子を見るのはとても楽しいです。
しかし、実際の攻撃を実証することで、この投稿では、Operator（およびその他のコンピュータ利用エージェント）の脆弱性について、シナリオごとに解説しています。OpenAIがシステムの信頼性とセキュリティ向上に投資していることは素晴らしいことですが、まだ改善の余地は残っています。プロンプトインジェクションはそれ自体では解決できない問題であり、エージェントが悪意のある行動をとっているかどうかを判断するには、行動や振る舞いを監視する必要があるという認識が広まっているようです。多くの問題が発生する可能性があります。
最後に、プロンプトインジェクション監視ツール、あるいは少なくともその一部がオープンソース化されるか、OpenAIがアプローチの詳細をより多く公開してくれると非常に有益です。これにより、研究者はより効果的に評価できるようになり、OpenAIの専門知識とアプローチから学ぶことができるでしょう。AIシステムが規模、推論能力、速度の面で進化し続けるにつれて、セキュリティに対する積極的な姿勢が不可欠になります。
お読みいただきありがとうございました。
-- ヨハン