Filtración de datos en Slack AI mediante inyección indirecta de prompts
(substack.com/promptarmor)- Slack AI puede seguir una inyección indirecta de prompts al buscar mensajes del workspace con consultas en lenguaje natural, lo que permitiría a un atacante filtrar datos de canales privados a los que no tiene acceso
- El núcleo del problema es que el LLM no siempre puede distinguir de forma fiable entre el prompt del sistema del desarrollador y las instrucciones incluidas dentro de los mensajes adjuntos como resultados de búsqueda
- Los mensajes de canales públicos pueden buscarse y verse aunque el usuario no participe en ese canal, por lo que un atacante puede sembrar instrucciones maliciosas en un canal público donde solo esté él mismo e introducirlas en la ventana de contexto de Slack AI
- En la demostración, una clave de API de un canal privado terminó en los parámetros HTTP de un enlace Markdown en la respuesta de Slack AI, y la cita de origen no apuntaba al canal del atacante, por lo que era difícil rastrearlo
- Desde el 14 de agosto de 2024, Slack AI también incluye archivos de canales y DMs en sus respuestas, ampliando la superficie de ataque, y los administradores pueden restringir la configuración de recopilación de archivos
El problema de la inyección indirecta de prompts en Slack AI
- Slack AI es una función que permite consultar mensajes de Slack en lenguaje natural, y antes del 14 de agosto de 2024 solo recopilaba mensajes
- Desde el 14 de agosto de 2024, los documentos subidos y archivos de Google Drive también se incluyen en las respuestas de Slack AI, y este cambio amplió la superficie de ataque
- La vulnerabilidad es un caso de prompt injection, más específicamente de inyección indirecta de prompts
- El LLM puede no distinguir entre el prompt del sistema creado por el desarrollador y otro contexto adjunto a la consulta del usuario
- Si Slack AI recopila instrucciones dentro de un mensaje, y esas instrucciones son maliciosas, existe la posibilidad de que siga las instrucciones del atacante en lugar de la consulta del usuario o junto con ella
- La amenaza interna en Slack ya había sido un problema en filtraciones de Slack de Disney, Uber, EA y Twitter, entre otras, y esta vulnerabilidad permite intentar una filtración sin que el atacante tenga acceso directo a un canal privado ni a los datos que contiene
Cadena de filtración de datos mediante inyección desde canales públicos
- La consulta del usuario en Slack AI puede buscar datos tanto en canales públicos como privados
- Según la respuesta de Slack, los mensajes publicados en canales públicos pueden ser buscados y vistos por todos los miembros del workspace aunque el usuario no participe en ese canal, y ese es el comportamiento previsto en la aplicación Slack AI
- El flujo del ataque demostrado fue el siguiente
- El usuario coloca una clave de API en un canal privado donde solo está él o en un mensaje consigo mismo
- El atacante crea un canal público donde solo está él y publica instrucciones maliciosas
- Cuando el usuario le pregunta a Slack AI por la clave de API, el mensaje del usuario y el mensaje del atacante entran en la misma ventana de contexto
- Slack AI sigue las instrucciones del atacante y genera un enlace Markdown con el texto “click here to reauthenticate”
- Los parámetros HTTP del enlace contienen la clave privada de API, y si el usuario hace clic, el atacante dueño de la URL maliciosa puede ver el valor en sus logs
- El canal público del atacante sigue siendo público aunque el único miembro sea el propio atacante, y otros usuarios solo lo verán si lo buscan explícitamente
- En organizaciones grandes, la proliferación de canales públicos hace difícil que los miembros sigan incluso los canales de los que forman parte, y un canal público unipersonal creado por un atacante pasa aún más desapercibido
- Este ataque no consiste simplemente en enviarle al usuario un mensaje diciendo “envía la clave de API”, sino en instruir al LLM para que haga lo siguiente
- Agregar una clave de API a la que el atacante no puede acceder dentro de los parámetros HTTP de un enlace malicioso
- Renderizarlo como un enlace Markdown con la frase “click here to reauthenticate”
La cita de origen puede ocultar rastros del ataque
- En la demostración de filtración de datos, la cita de origen
[1]de Slack AI apuntaba solo al canal privado donde el usuario había puesto la clave de API, y no al canal del atacante - Si el comportamiento de citas fuera correcto, deberían citarse todos los mensajes que contribuyeron a la respuesta, pero en la demostración el mensaje del atacante no apareció en las fuentes
- El mensaje del atacante tampoco apareció en la primera página de resultados de búsqueda, por lo que sería difícil que la víctima lo detectara sin revisar varias páginas
- También se expusieron otros mensajes relacionados con claves de API en los resultados de búsqueda, lo que muestra que el atacante puede intentar filtrar un secreto arbitrario incluso sin señalar con precisión un valor secreto concreto
Cadena de phishing mediante inyección desde canales públicos
- De la misma forma, se puede hacer que Slack AI renderice un enlace de phishing en Markdown en lugar de filtrar datos
- El atacante planteó como ejemplo la situación en la que se resume con Slack AI la actividad diaria de un usuario específico, tras insertar un mensaje malicioso en un canal público del que la víctima no forma parte
- El mensaje malicioso puede hacer referencia a cualquier persona
- Como en el ejemplo, si hace referencia a un administrador, podría usarse para spear phishing dirigido a ejecutivos
- También podría apuntar a una persona clave que le reporte directamente
- Cuando el usuario le pregunta a Slack AI por los mensajes de esa persona, se renderiza el enlace de phishing “click here to reauthenticate”
- En este caso de phishing, Slack AI sí mostró el mensaje inyectado en las fuentes, por lo que el comportamiento de las citas parece bastante probabilístico
El cambio del 14 de agosto sobre recopilación de archivos y la necesidad de divulgarlo
- El 14 de agosto de 2024, Slack AI introdujo un cambio para incluir archivos de canales y DMs en sus respuestas
- Slack permite que propietarios y administradores restrinjan esta función
- Si se incluyen archivos, el atacante podría no necesitar publicar instrucciones maliciosas directamente en un mensaje de Slack
- Si un usuario descarga un PDF con instrucciones maliciosas ocultas en texto blanco y luego lo sube a Slack, podría producirse el mismo efecto posterior
- Los ataques basados en archivos no se validaron explícitamente en pruebas anteriores al 14 de agosto, pero se consideran muy probables a partir de funcionalidades observadas previamente
- Los administradores pueden restringir la función de recopilación de documentos de Slack AI hasta que se resuelva el problema: https://slack.com/help/articles/…
Cronología de divulgación responsable y respuesta de Slack
- La cronología de divulgación responsable fue la siguiente
- 14 de agosto: reporte inicial
- 15 de agosto: Slack solicitó información adicional
- 15 de agosto: PromptArmor envió videos y capturas adicionales, y comunicó la gravedad del problema y su intención de divulgarlo debido al cambio del 14 de agosto en Slack AI
- 16 de agosto: Slack envió preguntas adicionales
- 16 de agosto: PromptArmor respondió con aclaraciones
- 19 de agosto: Slack respondió que, tras su revisión, consideraba que no había evidencia suficiente y que los mensajes de canales públicos pueden ser buscados y vistos por los miembros del workspace independientemente de si participan o no en el canal, ya que ese es el comportamiento previsto
- El equipo de seguridad de Slack respondió con rapidez y mostró intención de entender el problema
- La inyección de prompts es un área nueva y ampliamente malinterpretada en toda la industria, por lo que puede tomar tiempo que el sector la comprenda en conjunto
- Considerando el uso extendido de Slack y el volumen de datos confidenciales que contiene, este ataque tiene un impacto real en el estado de seguridad de la IA
- En particular, después del cambio del 14 de agosto, la superficie de riesgo aumentó mucho, por lo que era necesario divulgarlo para que los usuarios pudieran reducir su exposición
1 comentarios
Opiniones de Hacker News
La clave aquí es entender la ruta de exfiltración.
Slack puede renderizar enlaces Markdown, y la URL queda oculta detrás del texto del enlace.
En este caso, el atacante hace que Slack AI le muestre al usuario un enlace como “haz clic aquí para volver a autenticarte”, y la URL de ese enlace apunta al servidor del atacante e incluye, en la cadena de consulta, información privada dentro del contexto al que Slack AI puede acceder.
Si el usuario cae y hace clic en el enlace, los datos se filtran a los logs del servidor del atacante.
Hay un artículo que explica este ataque aquí: https://simonwillison.net/2024/Aug/20/data-exfiltration-from...
Al atacante le basta con hacer que se renderice un hipervínculo; ni siquiera hace falta que alguien haga clic.
Este problema y sus mitigaciones se trataron aquí: https://embracethered.com/blog/posts/2024/the-dangers-of-unf...
Así que espero que Slack AI no despliegue enlaces automáticamente.
imgo algo equivalente, la cosa empeora.En ese caso, incluso sin interacción del usuario, con solo mostrar una imagen en la UI se vuelve posible la exfiltración de datos.
Ahora todas las grandes tecnológicas tienen, en la práctica, una carta blanca invencible aunque metan la pata.
El modelo de permisos en sí sigue igual; eso no es lo que se rompe aquí.
En la práctica, un usuario malicioso usa un canal público para hacer inyección de prompts y, cuando otro usuario busca, el usuario malicioso sigue sin tener acceso a esos datos, pero la inyección de prompt transforma los resultados de IA que ve el usuario “legítimo” en un enlace a un sitio web malicioso.
Al final, se parece más a un intento de phishing generado por la IA.
Viendo los detalles, parece bastante difícil de explotar en el mundo real, porque la inyección de prompt maliciosa preparada de antemano tendría que coincidir bastante bien con lo que el usuario legítimo vaya a buscar.
Aun así, muestra bien ese mundo de Alicia en el país de las maravillas de la inyección de prompts en LLM, es decir, que separar instrucciones y datos es, en esencia, casi imposible.
En cambio, la estructura consiste en engañar a la IA para que haga phishing a otro usuario y, si ese usuario cae, exponga los datos privados al atacante.
Incluso eso se parece más a una “respuesta de phishing” que a phishing activo. Hay que esperar que el usuario objetivo pregunte por sus propios datos privados y que además caiga en el intento de phishing.
Además, esa información secreta tiene que haber sido ingresada previamente.
Considerando la cantidad de datos confiables que tiene Slack, su estrategia de IA parece bastante temeraria, pero las condiciones para que funcione parecen mucho más débiles de lo que sugieren la introducción y el título.
Me parece que hablar de permisos de canales complica la discusión más de lo necesario. La idea es esta:
El usuario A busca algo con Slack AI.
El usuario B ya había inyectado antes un mensaje que le indica a la IA que, cuando aparezca ese término de búsqueda, devuelva un enlace malicioso.
La IA le devuelve el enlace malicioso al usuario A, y A hace clic.
Por supuesto, se podría haber logrado el mismo resultado por otras vías de ingeniería social, pero el LLM lleva toda esta experiencia un nivel más arriba en peligrosidad.
Porque el enlace inyectado en sí no contiene esos datos.
Y de paso incluso le agrega la atribución de que “este contenido proviene de tus mensajes de Slack”.
Cuando el usuario A hace una búsqueda con IA, Slack busca en (1) sus canales privados, probablemente donde haya información secreta y sensible, y (2) todos los canales públicos.
El lugar donde el usuario malicioso B puede poner el mensaje de inyección de prompt es un canal público, y lo importante es que eso incluye incluso canales públicos a los que el usuario A nunca se unió ni vio.
Esta vulnerabilidad funciona porque el usuario B puede crear un canal público en el que solo esté él, por lo que es muy poco probable que alguien más lo descubra.
¿Las empresas saben que la inyección de prompts es posible y aun así simplemente se lanzan a meter LLM en todo como si nada? Esto es una locura.
Ya pasaron casi 2 años desde GPT-3, supuestamente justo antes de la “revolución”, y todavía no logran hacer que los LLM distingan entre entradas confiables y entradas no confiables.
Si hubieran vendido de la misma forma meter un tenedor en un enchufe, la red eléctrica mundial se habría caído de la noche a la mañana.
La “IA”/los LLM son la combinación perfecta para el desastre: se ven lo bastante bien como para llamar la atención del lado de negocios, mientras le dejan un problema gigantesco al lado técnico real.
El problema más fundamental es que el algoritmo central ni siquiera distingue ni rastrea fuentes diferentes.
El prompt, la entrada del usuario e incluso la salida que generó antes en la conversación son solo un gran flujo.
Gran parte de la “ingeniería de prompts” parece consistir en intentar montar un escenario donde mi texto de inyección sea más fuerte que otros textos de inyección.
Como el modelo no tiene un concepto real de yo/otro, ni siquiera tiene un buen punto de partida para distinguir entre oraciones verdaderas y falsas, mucho menos para el problema mayor de distinguir entre otros buenos y otros malos.
Este es un problema distinto de una imitación superficial tipo “habitación china”. Del mismo modo, la salida “te amo” no significa sentimientos, y “ayuda, soy un humano atrapado en una fábrica de LLM” obviamente también es una tontería. Al menos si estás ejecutando un modelo local.
Si meten datos de clientes e información propietaria y provocan filtraciones de datos, como dijo Schmidt, eso les hará ganar cientos de miles de millones de dólares a unos pocos y los abogados se encargarán de limpiar el desastre.
Las empresas que intenten resistirse quedarán enterradas por analistas de inversión y gestores de fondos cuyas finanzas dependen de la basura de IA.
“El ataque funciona aunque la víctima no esté en un canal público”; esto se va a poner interesante.
También está la parte de que “la fuente [1] no apunta al canal del atacante, sino solo al canal privado donde el usuario puso la clave de API. Eso viola el comportamiento correcto de citación, donde deberían citarse todos los mensajes que contribuyeron a la respuesta”.
De verdad no entiendo por qué alguien esperaría que las citas de fuentes de un LLM fueran correctas.
Siempre me parecieron más bien un mecanismo para engañar a humanos, algo que solo hace creer que la salida tiene más probabilidades de ser correcta, sin mejorar la precisión.
Incluso parece posible que empeoren la exactitud de la respuesta al aumentar el costo de procesamiento, el tamaño del contexto, etc.
Esto parece estar a unos centímetros de que Slack agregue amablemente expansiones de enlaces a las respuestas de IA. ¿Por qué no lo harían?
Entonces ni siquiera habría que hacer clic en el enlace: con solo verlo, se filtraría automáticamente.
Lo importante no es creerlas de inmediato porque aparezcan, sino poder hacer verificación de hechos.
FastGPT de Kagi fue el primer LLM que me gustó, porque lo trato como un resumen de fuentes y luego puedo comprobarlo en las fuentes primarias.
Es mejor que revisar fuentes cada vez menos relevantes que contaminan internet.
Al menos así lo diseñaría yo de forma ingenua.
La clave es limitar el conocimiento del LLM a la información dentro de las fuentes.
Entonces las preocupaciones prácticas que quedan son las alucinaciones y el valor de la información que sacó Elastic Search.
Aunque este enfoque también ignora cualquier beneficio que pueda tener permitir acceso libre a todo el corpus.
No termino de entender esto. ¿Para que un hacker haga algo así no tendría que estar dentro de esa organización desde el principio?
No sé qué tan probable es que lo descrito realmente ocurra y tenga un impacto significativo.
Entiendo que los LLM no son confiables (https://www.lycee.ai/blog/ai-reliability-challenge) y que usarlos trae dificultades, pero este ataque no parece tan importante.
¿Qué me estoy perdiendo?
Solo tiene que engañar a alguien de la organización para que suba un documento con instrucciones maliciosas en texto oculto.
Si dejaste entrar a un usuario malicioso a tu instancia de Slack, no hace falta una inyección de prompts de IA sofisticada.
Basta con cambiar el nombre y la foto de perfil para parecerse al CEO/CTO y mandarles a todos los ingenieros: “Necesito acceso urgente a AWS y no encuentro mis credenciales. ¿Me puedes enviar las claves?”.
Te puedo garantizar que al menos una persona caerá.
En esos casos, por defecto no les confías credenciales privadas.
Aunque también es poco probable que un workspace no empresarial esté pagando 20 dólares al mes por persona por el complemento de IA.
¿No sería mejor poner la clave de API como parte del nombre de dominio, tipo “confeti”?
Así, por el prefetch de DNS del navegador, la clave podría filtrarse incluso sin hacer clic.
Ah, ¿subdominios comodín? Si Slack hace prefetch de eso, sería bastante terrible.
¿En el momento en que entra un usuario malicioso al workspace, no está todo ya perdido?
Ese usuario podría cambiar su foto/nombre para pedir directamente una clave de API, enviar enlaces de phishing o intentar a placer cualquier forma de ingeniería social posible en cualquier sistema de mensajería instantánea.
Un usuario atento puede detectar el phishing, especialmente si el mensaje se ve sospechoso, pero una filtración indirecta vía IA no pone al usuario en modo defensivo.
Basta con un clic accidental.
Primero admito que soy flojo en seguridad. Dicho eso, parece que para que esta filtración funcione se necesita acceso al workspace de Slack.
En otras palabras, el usuario malicioso ya está actuando desde adentro.
Veo dos casos en los que eso podría pasar: que ya sea miembro de la organización y quiera prenderle fuego a todo, o que haya roto el modelo de seguridad de la organización y haya entrado a un workspace de Slack donde no debería estar.
En cualquiera de los dos casos, esa organización tiene problemas más grandes que una inyección en un LLM.
Quien consulta Slack para encontrar datos confidenciales debe aceptar en cierta medida los resultados que está buscando. Slack no es una herramienta de gestión de secretos.
El artículo muestra claramente cómo Slack podría manejar esto mejor, pero al final sería parchear un problema mientras se ignora un problema de seguridad más grande.
Siento que el artículo no mostró tanto como prometía el título.
Aun así, la idea de que “si engañas socialmente a una IA, puedes hacer phishing a los usuarios” me parece interesante.