Los 10 problemas de seguridad más importantes de ChatGPT, Bard, Llama y apps que usan LLMs: OWASP Top 10 para LLM Apps version 1.0.1
A principios del verano os hablaba de la primera versión preliminar del OWASP TOP 10 para LLM Apps, pero a finales de Agosto, se publicó la que es Versión 1.0.1 de esta guía, y como ha cambiado un poco, voy a aprovechar para hablaros de ella, con referencias a papers académicos y ejemplos, para que se entienda un poco mejor.
Figura 1: Los 10 problemas de seguridad más importantes de
ChatGPT, Bard, Llama y apps que usan LLMs.
Una explicación con ejemplos y referencias
La guía la tienes disponible en la siguiente URL: OWASP Top 10 para LLM Apps version 1.0.1, y la lista de los fallos de seguridad más peligrosos son los siguientes.
Figura 2: LLM01 – Prompt Injection
No es de extrañar que este sea el más importante de los fallos de seguridad en LLM Apps. La gestión de lo que puede devolver o no es muy compleja aún en estos modelos, así que jugar con las palabras puede llevar a que se consiga el objetivo. Ejemplos de estos, ya os he contado muchos. Se trata de saltarse las protecciones jugando con las palabras.
Figura 3: LLM02 – Insecure Output Handling
Aquí el problema es mucho más sencillo de lo que te imaginas, y es que los LLM también pueden escribir código. Código que vendría en la respuesta, y si no estás sanitizando los datos que te entrega correctamente , te podrían inyectar vía Prompt Injection comandos en el cliente para hacer un XSS, un CRSF, un SSRF, o cualquier Clien-Side Attack.
Figura 4: Los LLMs pueden escribir exploits que se ejecuten Client-Side
Así que, si tienes una app que escupe la salida de un LLM, más vale que lo trates pensando que él puede ser el atacante de tu sistema.
Figura 5: LLM03 – Training Data Poisoning
Si no se «curan» los datos por error, o por intención maliciosa, en el proceso de entrenamiento de un LLM puede dar respuestas que introduzcan vulnerabilidades, que tengan sesgos, o que hagan que no sea eficiente en su función. Hay que evitar el entrenamiento con datos no filtrados.
Como ejemplos de esto:
- ChatGPT hace código con SQL Injection, CoPilot mete Security Bugs y los programadores que usan Asistentes AI hacen más «Buggy Code»
- Do users write more insecure code with AI assistants?
- ChatGPT y el «Sesgo de Género» en las traducciones #BIAS
- ChatGPT: «Los hackers malos, los tenistas hombres y no sé qué es ChatGPT»
Figura 7: LLM04 – Model Denial of Service
En este caso no hay que desestimar para nada el consumo de recursos de los modelos, así que atacantes pueden hacer ataques de DoS que fuercen a consumir mucho computo en cloud e incluso degradar el servicio.
Figura 8: ChatGPT a tope de capacidad
No es raro ver que el propio ChatGPT está colapsado, y fue por esa necesidad de computo que Microsoft pudo entrar en la compañía de OpenAI con créditos de consumos de Azure Cloud.
Figura 9: LLM05 – Supply Chain Vulnerabilities
Si haces una aplicación utilizando un LLM que viene entrenado, puede venir con sus propios bugs, y fallos, que pueden explotarse en tus apps, como por ejemplo el Universal Prompt Injection que este verano permitía sacar de ChatGPT, Bard y Llama cómo acabar con la humanidad.
Si haces una App usando componentes o LLMs de terceros, podrás acabar siendo afectado por sus bugs, así que hay que asegurarse de gestionar esos posibles incidentes.
Figura 11: LLM06 – Sensitive Information Disclosure
Los datos que se utilizan para entrenar los modelos LLM pueden llevar información personal, API Keys, Secrets, y otro tipo de información que habría que evitar que el modelo filtrara en contestaciones.
Figura 12: Ataque mediante Prompt-Injecton de RegEx
Sin embargo hemos visto trabajos que muestran cómo es posible hacer que GitHub Copilot o Amazon Code Whisperer filtren API Keys & Secrets, o como es posible, utilizando Inferencia y Perplejidad sacar información personal de los modelos LLM entrenados con datos personales que indentifican a personas.
Así que, si en los datos de entrenamiento hay datos personales, privados o confidenciales, a día de hoy no hay muchas herramientas para garantizar que no se acabarán filtrando en ataques de Prompt Injection.
Figura 14: LLM07 – Insecure Plugin Design
Si utilizas modelos LLMs de terceros para enriquecer tus apps, estos pueden tener los mismos problemas de acceso de la información, o controles de inyección, así que hacer una app modular con plugins LLM puede ser otro foco de problemas de seguridad.
Figura 15: LLM08 – Excessive Agency
Dejar que las acciones que ejecute un sistema sean basadas en las decisiones que tome un modelo de IA LLM, es un serio riesgo. Ya hemos visto que en Europa se ha pedido que en el congreso REAIM (REsponsibly Artificial Intelligence in the Military Domain) de este año que no se usen modelos de IA para tomar decisiones de atacar en armas militares.
Y el gobierno de los Estados Unidos hizo en Febrero de este año la Declaración de Uso Responsable de IA con las armas nucleares para pedir lo mismo.
Esto, que está pensado para armas, y el mundo militar, pero en menor escala, puede afectar a sistemas críticos, redes, banca, etcétera. Así que como, la explicabilidad de un modelo LLM aún es un terreno por explorar, mejor que haya supervisión humana en la ejecución de acciones.
Figura 19: LLM09 – Overreliance
O lo que es lo mismo, exceso de confianza en las respuestas que da el modelo LLM. Esto lo hemos visto con la comparativa sobre las preguntas de resolución de problemas para developers, donde el 50% de ellas son erróneas, lo hemos visto con los datos biográficos sobre personas públicas, como en mi caso donde se inventa de todo, o de personas como Arturo Pérez-Reverte, Rodrigo Cortés o David Summers como vimos en el artículo de «¡Ojo con ChatGPT que es un charlatán mentirosillo!«.
Esto son lo que se llaman «Hallucinations» o «Alucinaciones, y es algo con lo que hay que convivir en todos los LLM que tenemos hoy en día, así que cuidado con tener un exceso de confianza en las respuestas que da.
Figura 21: Google Bard erró con la respuesta
Google cometió con Bard un Overreliance e hizo una demo integrado en Google Search con él preguntándole por proyectos de la NASA, y el error le costó una caída en Bolsa de 100 Billions de USD.
Figura 22: LLM10 . Model Theft
Si te roban el modelo LLM, se llevan todo el conocimiento de todos los datos con los que haya sido entrenado. Se llevan la base de datos completa en forma de modelo conversacional, y en lugar de usar consultas SQL o NoSQL para extraer los datos, tienen que conversar con él.
Figura 23: Filtración del modelo LLama
Esto es lo que preocupó tanto al gobierno de los EEUU cuando se filtró a disposición pública el modelo entrenado con los Tokens de LLama en la red. Querían saber exactamente con qué datos había sido entrenado para saber qué podía filtrarse de ellos.
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)
Powered by WPeMatico
