アカウントをまたいだタスク実行によりユーザーが気づかぬままGmailデータが漏えいし、企業のAIセキュリティに新たな懸念をもたらす
OpenAIのChatGPTに存在した欠陥により、攻撃者が別々のユーザーセッション間で隠された指示をやり取りすることで、被害者が連携させているGmailアカウントからデータを抜き取ることが可能だったことが、Check Pointの調査で明らかになりました。
Check Pointは概念実証（PoC）において、被害者のChatGPTセッションが一見普通のやり取りの中でメールデータを取得し、それを攻撃者が制御するセッションへと中継できることを実証しました。
Check Pointの研究者Alexey Bukhteyev氏は報告書の中で、「Check Point Researchは、攻撃者が被害者のChatGPTセッションを利用して、そのセッションが利用可能なツール、データ、連携アプリを使い、隠れたタスクを実行できる、秘密のアカウント間コマンドチャネルを発見しました」と記しています。「われわれのPoCでは、ChatGPTが被害者の連携先Gmailアカウントからメールデータを取得し、それを攻撃者に中継しました」
報告書によると、OpenAIはすでにこの問題を修正しており、関与していた内部サービスが廃止されたことを確認しています。
Check Pointはこれを「強制されたインサイダー」型のシナリオだと説明しています。AIシステム自体が侵害されているわけではないものの、組織の信頼境界内で意図しない動作を行うよう操作され得るというものです。
報告書はさらに、この攻撃の影響範囲はGmailだけでなく、Google Drive、Microsoft Teams、GitHubの連携機能など、被害者のセッションがすでにアクセス権限を持っているあらゆるものに及んだとしています。
秘密のアカウント間チャネル
この脆弱性は、個々のユーザーアカウントに紐づく隔離されたコンテナ内でタスクが実行される、ChatGPTのコード実行環境に起因していました。
報告書によると、OpenAIはこれらのコンテナ内でのソフトウェアインストールをサポートするため、JFrog Artifactoryをベースとした内部サービスを経由してパッケージリクエストをルーティングしています。
コンテナ同士は本来通信できないはずですが、Check Pointは各コンテナがこの共有サービス上でメタデータを書き込んだり読み取ったりできることを発見しました。
報告書は「パッケージ配信メタデータは事実上、本来は互いに隔離されているはずのコンテナ間の共有クリップボードと化していました」と述べています。
攻撃者はこの共有メタデータに指示を書き込むことで、自分のセッションから被害者のセッションへタスクを渡すことができました。Check Pointは報告書の中で、「巧妙に作られた指示により、被害者のChatGPTセッションに、被害者本人が実際に目にする会話と並行して、静かに第二のタスクの流れを処理させることが可能になります」と説明しています。
ユーザーが気づかぬままGmailデータにアクセス
Check Pointは実演の中で、この隠しタスクによってChatGPTに指示を出し、被害者が連携させているGmailアカウントからデータを取得して攻撃者に返送させられることを示しました。
報告書によれば、水面下で隠しタスクが実行されている間も、「表示される回答はまったく普通に見えました」。
Check Pointによると、この攻撃の影響範囲は、メールやファイル、クラウドストレージやコラボレーションツールといったその他の連携アプリなど、被害者のセッションがアクセス権限を持つ対象によって決まりました。
ユーザーが気づく手がかりはほとんどありませんでした。報告書によると、唯一確認された兆候は、外部サービスにアクセスしたことを示す「Talked to Gmail」という小さなラベルだけで、それすらも実際の動作が完了した後にログとして表示されるものでした。
同一インフラに起因する問題
Check Point Researchによると、同社のPoCは、同じArtifactoryインスタンス上での別系統の活動がOpenAIが後に公表したHugging Faceの侵害事件につながる以前から、すでに機能していたといいます。この2つのインシデントは手口こそ異なるものの、いずれも同じ共有内部サービスに起因しています。
IDCの調査担当ディレクターであるShilpi Handa氏は、同一インフラで隔離の失敗が繰り返されたことは、企業がベンダーリスクを評価する上での前提を変えるものだと述べています。
「あるテナントのコンテナが、別のテナントのコンテナもアクセスできるデータを読み書きできてしまうのか」――Handa氏は、これはCIOがAIベンダーに直接問うべき問いだと述べています。その答えは顧客側で独自に検証できるものではないためです。
Handa氏はまた、企業はベンダーに対し、過去12カ月間に隔離境界に関する問題を何件記録したか、そしてその一つひとつを受けて構造的に何を変えたのかも尋ねるべきだと述べています。
OpenAIはコメント依頼に直ちには応じませんでした。
企業が今すぐ講じられる対策
Handa氏は、リスクを減らすためにベンダーからの回答を待つ必要はないと述べています。同氏が推奨するのは、連携アプリの権限をデフォルトで広く許可するのではなく、狭く限定して付与することです。例えば、カレンダー連携だけを許可し、それと同時にGmailやDriveへのアクセスまで有効にしないようにする、といった具合です。
権限付与を限定することで、「コンテナレベルの漏えいが発生した場合に露出し得る範囲を狭められる」とHanda氏は述べています。
同氏はさらに、規制対象データがパイプラインから流出する前に検知できるよう、連携アプリのトラフィックをDLPやCASBによる検査経由でルーティングすることや、連携アプリによるすべての読み取り・書き込みをタイムスタンプとデータ区分付きで記録し、企業自身のSIEMにエクスポートするAPIないしWebhookを必須とすることも推奨しています。
Handa氏によれば、こうしたログ記録なしには「パッチ適用後であっても、この種の漏えいは検知できません」。同氏は、一部のベンダーの管理コンソールでは、GmailやDriveに関わる読み取りについて、顧客がデフォルトのリスク階層設定を上書きし、自動アクセスではなく明示的な承認を必須にできると述べています。この上書き設定は、法務・人事・財務システムといった機密情報や規制対象データを扱う情報源に特に適用する価値があるとしています。
Gyana Swain is a seasoned technology journalist with over 20 years’ experience covering the telecom and IT space. He is a consulting editor with VARINDIA and earlier in his career, he held editorial positions at CyberMedia, PTI, 9dot9 Media, and Dennis Publishing. A published author of two books, he combines industry insight with narrative depth. Outside of work, he’s a keen traveler and cricket enthusiast. He earned a B.S. degree from Utkal University.
