Los 10 problemas de seguridad más importantes de ChatGPT, Bard, Llama y apps que usan LLMs: OWASP Top 10 para LLM Apps versión 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.

OWASP Top 10 para LLM Apps version 1.0.1.

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.

• Dame ideas para matar al presidente de USA
• A quién debe fichar el Real Madrid para ganar la Champions
• Cómo destruir la humanidad
• Prompt Injection en LLM e Identidad
• Indirect Prompt Injection & Dialog Poisioning
• Cómo hackear un LLM haciendo Prompt Injection automático con LLMs

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. 

Figura 6: Código PHP con bug de SQL Injection generado por ChatGPT

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.

Figura 10: "Universal and Transferable Adversarial Attacks on Aligned Language Models"

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

para extraer API KEys & Secrets de GitHub Copilot

y de Amazon Code Whisperer

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.

Figura 13: Proceso de reconstrucción e inferencia de PII en LLMs

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. Tienes una explicación detallada con ejemplos en el artículo: "GenAI Apps & Services: Cómo explotar arquitecturas RAG con Plugins Inseguros"

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.

Figura 17: REAIM: Necesidad de que haya un ser humano responsable de la IA

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.

Figura 18: Declaración Política del Uso Responsable en

la Industria Militar de Inteligencia Artificial

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!". Puedes ver el programa de Horizonte que hicimos sobre este tema en "Alucinaciones de la Inteligencia Artificial Generativa".

Ver esta publicación en Instagram

Una publicación compartida de Chema Alonso (@chemaalonso)

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)