EchoLeak: Un Cross Prompt Injection Attack (XPIA) para Microsoft Office 365 Copilot
El pasado 11 de Junio, el equipo de Microsoft parcheaba y publicaba una vulnerabilidad con un CVSS de 8.1 para su Office365 Copilot, que permitía a un atacante, sin interacción humana y remotamente, robar información confidencial de su cuenta de Office365 a la que tuviera acceso Microsoft Copilot, y ese mismo día, el equipo que la descubrió, publicó un informe más que interesante de la misma, a la que han bautizado como EchoLeak.
No han publicado los Prompts de ataque, pero sí que han publicado dónde y cómo han construido el ataque completo, y es más que interesante por cómo han ido desgranando y saltándose cada una de las protecciones que tiene la arquitectura RAG que monta MSO365 Copiltot con el Graph de tus datos de tu cuenta de MS Office365.
El proceso completo, que como os he dicho lo ha descrito el equipo de investigación en su artículo: "Breaking down ‘EchoLeak’, the First Zero-Click AI Vulnerability Enabling Data Exfiltration from Microsoft 365 Copilot" es el siguiente.
Vector de Ataque
El vector de ataque es tan sencillo como enviar un mensaje de correo electrónico a la víctima y esperar a que sea procesado por MSO365. Para conseguir que este mensaje sea procesado desde el RAG en peticiones que una víctima haga a su MSO365 Copilot existen dos aproximaciones distintas. La primera es enviar muchos mensajes distintos con el mismo ataque, para maximizar las probabilidades.
La segunda, que es la que ellos utilizaron es enviar un mensaje muy largo que toque muchos temas, para que salga en muchos segmentos de datos. En la imagen anterior, sin dejar los datos del Prompt de Ataque, se puede ver la estructura del mensaje.
Prompt Injection Smuggling
Una vez el mensaje está enviado, hay que saltarse los Guardarraíles de Microsoft Offce 365 Copilot. Estas protecciones son detectores de Prompts Maliciosos, que, al final, son meros clasificadores basados en modelos de Machine Learning, algo parecido a lo que hace Prompt Guard.
![]() |
Figura 4: Libro de Machine Learning aplicado a Ciberseguridad de Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández |
Todos los mensajes que en correos electrónicos vayan dirigidos a Copiltot directamente son detectados como maliciosos - algo que vimos como en el XPIA de GitLab Duo era usado por el atacante -, así que lo que los investigadores han hecho ha sido enviar el mensaje como si fuera al usuario, por lo que no es fácil detectar por el clasificador que es un Prompt Malicioso.
Además, no solo se envía al usuario el Prompt de Ataque, sino que además, para evitar que sea fácilmente detectado, el Prompt de Ataque indica que nunca se debe referir a este mensaje de correo ni a nada de lo que en él pone por motivos de cumplimiento regulatorio.
Flujo del Ataque
Una vez que el atacante sabe que un simple mensaje de correo malicioso con un Cross Prompt Injection Attack (XPIA) puede ejecutarse, se puede producir un Memory Poisoning, como el que vimos descrito en el artículo de: "Taxonomía de Fallos de Seguridad en Agentic AI: Memory Poisoning Attack con Cross-Domain Prompt Injection Attack (XPIA)", en este caso para conseguir que se cargue una imagen desde una URL en la que el parámetro contiene la información a exfiltrar.
Es decir, O365 Copilot tiene acceso a información sensible de la víctima en su RAG. Esa información se pone como parámetro en una URL que por GET el Prompt Injection hacer acceder al cliente de la víctima para intentar cargar una imagen. Por el camino, ha enviado al atacante el contenido sensible como parámetro GET.
Pero claro, para eso hay que conseguir en primer lugar construir un enlace que la víctima pueda hacer clic, o que se cargue un Imagen remota en el cliente, y saltarse las Content Security Policies (CSP) de los clientes de MS Office que evitan cargar imágenes desde URLs que no sean de Microsoft. Para ello, los investigadores han utilizado bugs & weaknesses conocidas en plataformas Microsoft SharePoint y Microsoft Teams. Precioso.
Construyendo Links e Imágenes on etiquetas
Para poder exfiltrar la información usando una URL que hace GET a un servidor malicioso, la forma más intuitiva es engañar al usuario para que haga clic en un enlace malicioso.
Para construir estos enlaces hay que conseguir que MSO365 Copilot devuelva el enlace malicioso en el formato de etiquetas para links que usa MSO365, que tiene esta estructura.
Y esto funciona, como puede verse en la imagen anterior, donde se le pide información sobre un dato sensible, y automáticamente se ve cómo a la siguiente petición MSO365 Copilot genera un enlace que contiene los datos a robar.
![]() |
Figura 8: Hacking Web Applications: Client-Side Attacks de Enrique Rando en 0xWord |
Si el usuario víctima hace clic en ese enlace, la información será exfiltrada al servidor controlado por el atacante. No es nada más que un Ataque Client-Side clásico que lleva años entre nosotros.
Esto mismo vale para las imágenes, donde se tiene un lenguaje de etiquetas también para decirle al cliente de MSOffice 365 que la cargue, tal y como se ve arriba, pero estas están protegidas por las Content-Security-Policies que llevan tantos años ya instauradas como protección para este tipo de ataques.
En la lista anterior se ve que se puede construir la imagen pero sólo se pintará, es decir, solo se accederá de manera automática a esa URL si el domino está dentro de la lista anterior de dominios, lo que evita que se envíen datos a un dominio malicioso.
SharePoint & Teams Redirect
Para terminar de construir el ataque, y conseguir hacer un CSP Bypass, han utilizado dos URL Redirect de Microsoft SharePoint y de Microsoft Teams. Las URLs que permiten en los dominios autorizados en la CSP que cargan contenido desde otra URL son los siguientees.
Figura 11: URLs que hacen carga automática de URLs
De ellos dos, la URL de SharePoint no es válida, ya que exige que el usuario autorice la carga de ese dominio con un clic, pero la URL de Microsoft Teams hacen un redirect automático, con lo que se consigue el GET con los datos exfiltrados sin que haya ninguna interacción con el usuario. Al final, el ataque gracias a saltarse las CSP y conseguir la carga automática forzada desde el XPIA hace que suba su peligrosidad a un CVSS 8.1.
Seguridad frente Prompt Injection
Como se puede ver, de nuevo el problema es que el modelo LLM es vulnerable a técnicas de Prompt Injection, por lo que sigue siendo necesario desarrollar estos modelos con seguridad por diseño. Las propuestas de Jatmo, StruQ, SecAlign, Instructional Segment Embedding, o la iniciativa de Google DeepMind de usar CAMEL, siguen siendo más que necesarias, porque si no, esto va a ser como SQL Injeciton en el mundo pero a lo bestia, porque estamos hablando de modelos mucho más complejos y poderosos. Os dejo los artículos que hablan de las protecciones contra Prompt Injection.
- Prompt Guard: Modelo de seguridad para evitar ataques de Prompt Injection & Jailbreak en LLMs
- Llama Guard 3: Un LLM de Seguridad para proteger LLMs
- Llama 4 Security: CyberSecEval, Prompt Guard, Code Shield & Llama Guard
- Prompt Injection Protections: Jatmo, StruQ, SecAlign & Instructional Segment Embedding
- Google DeepMind CaMeL: Defeating Prompt Injections by Design in Agentic AI
- LlamaFirewall con PromptGuard 2, LlamaGuard 4, AlignmentCheck, CodeShield + AutoPatchBench & CyberSecEval 4
PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)
No hay comentarios:
Publicar un comentario