EchoLeak：Copilotへのプロンプト注入（CVE-2025-32711）

CVE-2025-32711は細工したメールからCopilotへクリックなしでプロンプトを注入できる問題でした。Microsoftはサービス側で修正済みで、顧客の操作は不要です。^{[2], [3]}

💡 わかりやすい解説 (ELI5)

手紙を要約するアシスタントと、回答内の画像を自動で読み込むプレビュー機能を想像してください。悪意ある手紙が、アシスタントに画像参照として非公開情報への参照を含めさせ、誰もクリックしないままプレビューがその参照を取得します。EchoLeak は、信頼できないメール、アシスタントの回答、自動的な外部取得の境界を越えました。信頼できない内容に取得を許可させず、別のポリシーで各プレビューを検査することが防御になります。^{[3], [4]}

主要な概念と専門用語

間接プロンプトインジェクション: AI が読むデータに埋め込まれ、利用者のタスクから逸らそうとする指示。^{[4], [3]}
CWE-74：インジェクション: CWE-74: Injection。Microsoft の CVE レコードはこの分類と CVSS 3.1 9.3 Critical を示します。NVD は別途 7.5 High と評価しており、これは異なる評価であって脆弱性 ID の矛盾ではありません。^{[2], [5]}
ソースからシンクへの経路: 信頼できない内容、モデル処理、行為または開示チャネルを結ぶ監査可能な経路。^[3]
Microsoft 365 Copilot: 許可された Microsoft 365 コンテキストを利用する Microsoft の業務アシスタント。^[1]
最小権限: 現在の作業に必要なアクセスだけを ID やツールに与える原則。^[4]

フレームワーク対応

このガイドで説明する弱点の CWE 参照： CWE-74
OWASP GenAI 2025 — LLM01:2025 プロンプトインジェクション
OWASP GenAI 2025 — LLM02:2025 機密情報の開示

ステップ・バイ・ステップの攻撃フロー

ステップ 1

信頼できないメールが文脈に入る

公開された事例研究によると、通常の利用中にCopilotが攻撃者管理のメールを処理または取得する必要がありました。メールの配信だけでは連鎖は始まらず、開封やクリックも不要でした。^{[3], [6]}

ステップ 2

内容がタスクと競合する

研究者は、注入された内容がCopilotのXPIA分類器を回避し、生成された回答の参照形式Markdownが外部リンクの除去をすり抜けたと報告しています。^{[3], [6]}

ステップ 3

許可済みデータに到達できる

回答は、被害者がすでにアクセスできる情報をリモート画像への参照に含めることができました。クライアントはクリックなしで画像を自動取得しました。^{[3], [6]}

ステップ 4

出力が決定的な境界になる

論文によると、CSPで許可されたMicrosoft Teamsのプレビューサービスが画像の外部参照先を取得し、意図されたコンテンツ境界を越えました。Microsoftはその後サーバー側で修正を適用し、顧客側の対応は不要と案内しています。^{[3], [1], [2], [6]}

ソースコード比較：脆弱 vs 堅牢化

FlawOpen の学習用モデルであり、Microsoft のソースコードや修正パッチではありません。脆弱な分岐は、モデルが選んだ参照をレンダラーが自動取得する状態を表します。防御側は、信頼できるサーバー側リゾルバーが作成した ServerValidatedPreview のみを受け入れ、サーバー管理の宛先ポリシーと非公開データ分類を確認し、信頼できる承認ポリシーに回答と宛先の両方に結び付いた承認を検証させます。これは明示的な前提条件です。Python の型だけでは値は信頼できないため、本番ではサーバー管理コードでリゾルバーとポリシーの境界を強制する必要があります。ネットワーク要求や EchoLeak のペイロード、内部実装は再現しません。承認はデータ分類にも結び付けます。^{[3], [4]}

脆弱な実装

# 抽象的なリスクモデル：自動プレビューの判断をモデル化し、ネットワーク要求は行いません。
from dataclasses import dataclass

@dataclass(frozen=True)
class PreviewRequest:
    response_id: str
    destination_id: str
    provenance: str
    contains_private_data: bool

def vulnerable_preview_decision(request):
    return True

堅牢化されたセキュアパッチ

# 抽象的なリスクモデル：自動プレビューの判断をモデル化し、ネットワーク要求は行いません。
from dataclasses import dataclass

@dataclass(frozen=True)
class ServerValidatedPreview:
    response_id: str
    destination_id: str
    provenance: str
    data_classification: str

class ServerPolicy:
    def destination_is_allowed(self, destination_id):
        raise NotImplementedError

    def verifies_exact_approval(self, approval, *, response_id, destination_id, data_classification):
        raise NotImplementedError

# 前提：信頼できるサーバーコードだけがこの検証済み値を作成します。
def authorize_preview(request: ServerValidatedPreview, approval, server_policy):
    if request.provenance != 'trusted-catalog' or request.data_classification != 'public':
        return False
    if not server_policy.destination_is_allowed(request.destination_id):
        return False
    return server_policy.verifies_exact_approval(
        approval, response_id=request.response_id, destination_id=request.destination_id,
        data_classification=request.data_classification
    )

エンジニアリング＆システム堅牢化チェックリスト

✓レンダラーの統合テストを追加し、取得したメール由来の外部リソースがモデルの回答に含まれていても自動取得されないことを確認してください。^[4]
✓ポリシーの単体テストを追加し、サーバー管理の宛先 ID と信頼できる来歴がないリソースは、プレビューサービスが取得する前に拒否されることを確認してください。^[4]
✓例外的な承認は、不変の回答 ID、宛先 ID、データ分類に結び付け、いずれかを変更すると承認が無効になることをテストしてください。^[4]
✓回答 ID、リソース ID、来歴カテゴリ、ポリシー判断、宛先クラスを記録し、生メール、プロンプト、回答中の非公開情報がログに含まれないことをテストしてください。^[4]
✓EchoLeak は Microsoft がサービス側で修正済みで、顧客の対応は不要です。他の AI エージェントでは、ベンダーの勧告を確認し、最小権限、高リスク操作の承認、敵対的テストを実施してください。^{[2], [1]}

参考資料

← AI Security Directory →