Los problemas de seguridad más importantes de ChatGPT, Bard, Llama y apps que usan LLMs (OWASP LLM)
A principios del verano salió 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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Documento OWASP Top 10 forLLM Applications: https://owasp.org/www-project-top-10...023-v1_0_1.pdf
¡Saludos Malignos!
