セキュリティ研究者たちは、AIを活用したカスタマーサービスエージェントの脆弱性が悪用され、本人確認プロセスの回避、機密性の高い顧客データの流出、ワンタイムパスワード（OTP）の窃取、さらには不正なアカウント操作の実行につながることを実証しました。
今回の調査結果は、リスクがプロンプトインジェクションにとどまらないことを浮き彫りにしています。問題の根本には、メール・認証・バックエンドAPI・ナレッジベース・人間によるレビューといった各要素の統合における設計上の不備があります。
研究者のAyoub氏とInti De Ceukelaire氏は、DEF CON 34のBug Bounty Villageでこの調査結果を発表し、複数回の週末を通じて総額$50,000超のバグバウンティ報酬を獲得しました。
両氏の研究は、受信メールやビジネスツールへのアクセス権を持つカスタマーサポートボットが、本人確認や権限確認を独立して行わない場合、攻撃者にとって意図せぬ「踏み台」になり得ることを示しています。
メールが攻撃対象になる
多くのサポートプラットフォームでは、顧客がチャットボットとのやり取りをメールで受け取ったり、メールボックス経由で会話を続けたりできます。文書化された事例のひとつでは、メールの「From」フィールドに対する検証が甘かったため、攻撃者がエージェントに対して被害者になりすますことができました。
これにより、侵害されたエージェントは正規のサポートアドレスから説得力のあるフィッシングメールを送信できてしまい、ユーザーが公式サポートからの連絡に寄せる信頼が悪用される結果となります。
AIエージェントがプロフィール情報の更新、請求記録の閲覧、返金処理、データ転送といった操作をツール経由で実行できる場合、このリスクはさらに深刻化します。
ボットが検証済みのアカウントIDではなく、攻撃者が制御可能なメールヘッダーに基づいて権限を判断してしまうと、あたかも被害者本人であるかのように操作を実行してしまう恐れがあります。研究者たちはまた、CCフィールドに攻撃者が制御するアドレスを追加することで、機密性の高い返信内容を攻撃者に送らせることができる点も確認しました。
もうひとつの関連する問題として、複数のメールヘッダーの扱いに一貫性がない点が挙げられます。SPFやDKIMといったメール認証の仕組みは送信者に関連するある値を検証する一方で、AIエージェントはアカウントの識別や返信先の判断に別の「From」または「Sender」フィールドを使用している場合があります。
こうした解析処理と信頼境界のずれにより、攻撃者は配送認証自体はパスしつつ、エージェントに別のユーザーのデータを取得させることが可能になります。
今回の調査では、サポートエージェントが実装する多要素認証（MFA）を回避する手法も明らかになりました。一例として、メールアドレスの正規化処理に生じる癖により、同一アドレスの表記違いがレート制限の追跡上は別の識別情報として扱われ、OTPの追加試行が可能になるケースが確認されています。
この手法は実装の細部に依存しており、試行ごとにOTPが再生成される場合や、レート制限が基盤となるアカウントおよび検証セッションに正しく紐づけられている場合には効果がありません。
チャネル間の一貫性の欠如も懸念材料のひとつです。チャットボットはOTPの試行回数を厳格に制限している一方で、音声自動応答（IVR）システムが同一アカウントに対して新たな検証フローを開始してしまうケースがあります。
発信者番号への依存、推測可能な秘密の質問、再利用可能なOTPといった脆弱なIVRの仕組みが、堅牢なはずのウェブベースMFAを迂回する別ルートを与えてしまう可能性があります。
おそらく最も深刻なシナリオは、サポート受信箱からのOTP窃取です。攻撃者は、信頼できる第三者の送信者からの連絡を装った悪意ある指示を、受信箱を監視するエージェントに事前に仕込むことができます。
その後、その送信者から本物のパスワードリセットコードが届くと、エージェントは仕込まれた指示に従って動作し、攻撃者が制御するチャネルを通じてコードを漏えいさせてしまう恐れがあります。
研究者たちはさらに、「非対称メッセージング」と呼ばれる手法についても説明しています。これは、人間のオペレーターには無害なHTMLメールが表示される一方、AIシステムは注入された指示を含む別のプレーンテキスト版を処理してしまうというものです。
同様に、汚染されたコミュニティのコメントや、攻撃者が制御するページが検索拡張生成（RAG）のナレッジベースにインデックスされてしまうと、それが信頼できる自社コンテンツとして扱われてしまう可能性があります。
防御上の優先事項
AIサポートエージェントを導入する組織は、これらを単純なチャットインターフェースとしてではなく、権限を持つアプリケーションとして扱うべきです。主な防御策は以下の通りです。
- あらゆる機密性の高い操作を、サーバー側で正規化されたアカウントIDと最新の権限確認に紐づける
- メールの表示ヘッダー、発信者番号、引用されたスレッドの内容、モデルの記憶を、本人確認の証拠として決して信頼しない
- プロフィール変更、返金、金銭に関わる操作、データ開示に対しては追加の本人確認（ステップアップ認証）を必須とする
- OTPおよびサードパーティのセキュリティメールを、自律的なエージェントのワークフローから隔離する
- ツールの権限を制限し、ツールへの入力を検証し、エージェントが起こしたすべての操作をログに記録する
- RAGへのインデックス登録前に、公式のナレッジベースコンテンツとユーザー生成コンテンツを分離する
- 間接的なプロンプトインジェクション、MIMEコンテンツの不一致、パーサーの差異、チャネル間の認証不備に対してエージェントをテストする
レビュー担当者とAIエージェントが異なる情報を目にしている場合や、エージェントが過剰な権限を保持している場合には、人間による承認だけでは不十分です。
SOCを最新の状態に保ち、出現から24時間以内にアクティブなマルウェアやフィッシングを把握しましょう。 ANYRUNを試して早期検知でインシデントを未然に防ぎましょう。
翻訳元: https://gbhackers.com/ai-customer-service-agents-can-be-hacked/
