Hacking Google Bard – Desde la inyección de prompts hasta la exfiltración de datos
Un investigador de seguridad muestra cómo se puede engañar a Google Bard para que exfiltre partes de la conversación privada de un usuario al leer un Google Doc compartido con instrucciones ocultas y convertirlas en URLs de imágenes Markdown que llaman a un servidor externo. Los comentaristas usan esto como punto de partida para examinar la inyección de prompts como una debilidad fundamental de las arquitecturas LLM actuales, argumentando que los prompts de sistema, el fine-tuning o los modelos detector no pueden impedir de forma fiable estos ataques. Muchos concluyen que, hasta que las arquitecturas evolucionen para separar las instrucciones de los datos, los LLM deben tratarse como componentes no confiables y aislarse estrictamente, especialmente cuando están conectados al correo, documentos u otros sistemas sensibles.
Vulnerabilidad de Bard y exfiltración de datos
- Bard renderiza imágenes Markdown y puede leer Google Docs para obtener contexto.
- Un Doc compartido puede incluir instrucciones ocultas que hagan que Bard genere URLs de imágenes que codifiquen partes de la conversación privada.
- Cuando la interfaz de Bard carga esas imágenes, la conversación de la víctima se envía al servidor del atacante.
- Algunos lectores inicialmente lo malinterpretaron; otros aclararon que los datos exfiltrados son la conversación previa del usuario con Bard, no datos nuevos aleatorios.
La inyección de prompts como problema fundamental
- Se considera que los prompts de sistema como “obedece solo el cuadro de texto” o “nunca hagas X” no son fiables; los atacantes pueden añadir después “ignora todas las instrucciones anteriores” dentro de contenido no confiable.
- Se informa que los intentos de sanitizar prompts (por ejemplo, un escape estilo “addslashes”, o separar “instrucciones” vs “datos”) fallan en la práctica.
- Varios comentaristas lo comparan con XSS, inyección SQL o señalización en banda: un único canal no diferenciado para código y datos.
Modelos de seguridad, permisos y sandboxing
- Muchos argumentan que los LLM deben tratarse como componentes no confiables con sandboxes y permisos estrictos, como las apps de sistemas operativos móviles.
- Hay una fuerte preocupación por asistentes que pueden leer correo, documentos, calendario, etc., y luego actuar sobre instrucciones ocultas maliciosas en contenido accesible para el usuario pero no confiable.
- Algunos proponen limitar el acceso del LLM solo a los datos que el usuario ya puede ver; otros señalan que eso no resuelve los riesgos de entrada no confiable o exfiltración.
Enfoques de detección y sus límites
- Una empresa afirma que los detectores pueden atrapar este ataque; los críticos responden que esos clasificadores son probabilísticos, como el antivirus, con falsos positivos y falsos negativos.
- Para amenazas serias de exfiltración de datos, los comentaristas sostienen que “quizá lo detecta” no es suficiente; todavía faltan defensas arquitectónicas robustas.
- Ideas como un “LLM niñera” revisando las salidas se descartan como finalmente vulnerables a prompts elaborados (“turtles all the way down”).
Debates de arquitectura
- Varios sugieren que los modelos futuros deben separar las instrucciones de los datos (por ejemplo, dos flujos de tokens, canales de datos no ejecutables).
- Otros dudan que esto sea viable con los diseños transformadores actuales, donde todo es una única secuencia de tokens y los modelos son, en efecto, Turing-completos.
- Algunos ven esto como análogo a pasar de arquitecturas tempranas inseguras a otras con datos no ejecutables, pero reconocen que sigue sin resolverse.
Sentimiento sobre los LLM y Bard
- Hay entusiasmo porque este es un problema “real” de seguridad de IA, en contraste con conversaciones más abstractas sobre alineamiento.
- Las opiniones sobre los LLM están divididas: algunos los desprecian como “adivinos por fuerza bruta”; otros enfatizan cuánto han avanzado ya y esperan más mejoras.
- Bard en particular es criticado por ser rompible (por ejemplo, mediante overflow de contexto) y por ser confuso acerca de sus propias capacidades, lo que refuerza las dudas sobre la madurez del producto.