flawopen.com/AI Security/microsoft-365-copilot-echoleak-prompt-injection-may-2025
EchoLeak: Copilot-Injection CVE-2025-32711
CVE-2025-32711 ermöglichte Prompt-Injection per E-Mail ohne Klick. Microsoft hat den Dienst behoben; Kunden müssen nichts tun.[2], [3]
Stellen Sie sich einen Assistenten vor, der Briefe zusammenfasst, und ein Vorschausystem, das Abbildungen in seiner Antwort automatisch lädt. Ein schädlicher Brief bringt den Assistenten dazu, in einer Abbildung auf private Informationen zu verweisen; die Vorschau folgt diesem Verweis ohne Klick. EchoLeak überschritt die Grenze zwischen nicht vertrauenswürdiger E-Mail, Antwort des Assistenten und automatischem externem Abruf. Die Abwehr verhindert, dass nicht vertrauenswürdige Inhalte einen Abruf autorisieren, und prüft jede Vorschau durch eine separate Richtlinie.[3], [4]
Kernkonzepte & Begriffe
Indirekte Prompt-Injection- Anweisungen in Daten, die eine KI liest und die sie von der Nutzeraufgabe ablenken sollen.[4], [3]
CWE-74: InjectionCWE-74: Injection. Microsofts CVE-Datensatz nennt diese Einstufung und CVSS 3.1 mit 9,3 Kritisch. Die NVD führt separat ihre eigene Bewertung 7,5 Hoch; es sind unterschiedliche Bewertungen, kein Widerspruch zur Schwachstellen-ID.[2], [5]Quelle-Senke-Pfad- Prüfbarer Weg von nicht vertrauenswürdigem Inhalt über Modellverarbeitung zu Aktion oder Offenlegung.[3]
Microsoft 365 Copilot- Microsoft-Arbeitsassistent, der erlaubten Microsoft-365-Kontext verwendet.[1]
Minimalprinzip- Einer Identität oder einem Werkzeug nur den für die aktuelle Aufgabe nötigen Zugriff geben.[4]
Framework-Zuordnungen
- CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-74
- OWASP GenAI 2025 — LLM01:2025 Prompt-Injection
- OWASP GenAI 2025 — LLM02:2025 Offenlegung sensibler Informationen
Schritt-für-Schritt Angriffsablauf
Ausleitung ist die entscheidende Grenze
Laut Artikel rief ein durch die CSP erlaubter Microsoft-Teams-Vorschaudienst das externe Bildziel ab und überschritt damit die vorgesehene Inhaltsgrenze. Microsoft veröffentlichte später eine serverseitige Korrektur; laut Microsoft ist keine Kundenaktion erforderlich.[3], [1], [2], [6]
Quellcode: Verwundbar vs. Sicher
Lehrmodell von FlawOpen, weder Microsoft-Quellcode noch dessen Patch. Der verwundbare Zweig bildet einen Renderer ab, der eine vom Modell gewählte Referenz automatisch lädt. Der defensive Zweig akzeptiert nur ein ServerValidatedPreview, das ein vertrauenswürdiger serverseitiger Resolver erstellt hat, prüft die serverseitige Zielrichtlinie und die Einstufung als nicht privat und lässt eine vertrauenswürdige Genehmigungsrichtlinie eine exakt an Antwort und Ziel gebundene Genehmigung verifizieren. Dies sind ausdrückliche Voraussetzungen: Python-Typen allein machen einen Wert nicht vertrauenswürdig; in der Produktion muss serverseitig kontrollierter Code die Grenzen von Resolver und Richtlinie durchsetzen. Der Code sendet keine Netzwerkanfrage und reproduziert weder EchoLeaks Payload noch interne Implementierung. Die Genehmigung ist außerdem an die Datenklassifizierung gebunden.[3], [4]
# ABSTRAKTES RISIKOMODELL: bildet eine automatische Vorschauentscheidung ab; sendet keine Netzwerkanfrage.
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
# ABSTRAKTES RISIKOMODELL: bildet eine automatische Vorschauentscheidung ab; sendet keine Netzwerkanfrage.
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
# VORAUSSETZUNG: Nur vertrauenswuerdiger Servercode erstellt diesen validierten Wert.
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
)
Checkliste für Engineering & Systemsicherheit
- ✓Ergänzen Sie einen Integrationstest für den Renderer, der belegt, dass eine externe Ressource aus abgerufenem E-Mail-Inhalt nicht automatisch geladen wird, selbst wenn das Modell sie in die Antwort aufnimmt.[4]
- ✓Ergänzen Sie einen Policy-Unit-Test, der belegt, dass eine Ressource ohne serverseitig verwaltete Ziel-ID und vertrauenswürdige Herkunft abgewiesen wird, bevor ein Vorschaudienst sie abrufen kann.[4]
- ✓Binden Sie jede Ausnahmegenehmigung an die unveränderliche Antwort-ID, Ziel-ID und Datenklassifizierung; testen Sie, dass eine Änderung eines Feldes die Genehmigung ungültig macht.[4]
- ✓Protokollieren Sie Antwort-ID, Ressourcen-ID, Herkunftskategorie, Policy-Entscheidung und Zielklasse; prüfen Sie, dass rohe E-Mails, Prompts und private Antwortinhalte nicht in den Logs stehen.[4]
- ✓Für EchoLeak ist laut Microsoft der Dienst bereits korrigiert; Kunden müssen nichts tun. Prüfen Sie bei anderen KI-Agenten die Herstellerhinweise und setzen Sie minimale Rechte, Genehmigungen für risikoreiche Aktionen und adversariale Tests durch.[2], [1]
Quellen
- Microsoft Security Insider — AI application security considerations for organizations
- Microsoft Security Response Center — CVE-2025-32711
- AAAI case study — EchoLeak zero-click prompt-injection chain
- OWASP Top 10 for LLM Applications — Prompt Injection
- NVD — CVE-2025-32711 (NVD enrichment and CNA data)
- Aim Security / Aim Labs — original EchoLeak disclosure