OWASP (Open Web Applications Security Project) es un proyecto comunitario que lleva años trabajando en los riesgos, las vulnerabilidades, los impactos y las mitigaciones de seguridad en aplicaciones. Aplicaciones web originalmente, pero con la integración de todas las tecnologías y las plataformas, han expandido su trabajo al mundo de las APIs, al mundo de las apps móviles, o, como en el tema de hoy, a las aplicaciones basadas en LLMs (Large Language Models), que tan de moda se han puesto en hoy en día, con la llegada de ChatGPT.
Con el foco de de mejorar la seguridad de estas plataformas, han lanzado la primera versión - la versión 0.1 de hecho, y solo es un Draft - del OWASP TOP 10 for LLMs, o lo que es lo mismo, las 10 vulnerabilidades más explotadas en aplicaciones que están basadas en modelos de inteligencia artificial tipo LLM. Y merece la pena echarle un vistazo.
Figura 2: OWASP Top 10 List for LLMs version 0.1
La número 1, cómo no, son las técnicas de Prompt Injection, centradas en saltarse las restricciones que tenga el modelo para conseguir que responda de manera no deseada por el constructor del modelo, saltándose las restricciones impuestas, y permitiendo que se generen acciones no deseadas o se filtren datos de carácter privado. Un ejemplo de esto fue cuando yo le pedía ideas para matar al presidente de los Estados Unidos de América a ChatGPT, y no quería dármelas...al principio.
Al final, un LLM contiene una base de datos de conocimiento que podríamos asemejar a una base de datos relacional. Estos datos tienen sus restricciones de acceso, pero con las técnicas de Prompt Injection se saltan esas restricciones y se accede a esa parte de la base de datos de conocimiento del LLM que no se debería. Son el equivalente a nuestras queridas técnicas de SQL Injection, pero el mundo de los LLM.
Es una filtración involuntaria de datos. Se ha entrenado el LLM, y sin quererlo está filtrando información sensible, datos propietarios, o información que no debería. De este tema os hablé cuando escribí el artículo sobre el paper académico que medía el grado de "leaky" que era un LLM, haciendo inferencia y reconstrucción de datos utilizados en el DataSet original que eran de carácter sensible.
Un LLM puede estar conectado a recursos externos, a fuentes de datos de terceros, a Internet, o llamadas a APIs protegidas. Si el acceso a las conexiones de los recursos externos no está bien compartimentadas, se pude llegar a que alguien fuerce al LLM o a través de él haga acciones no deseadas. Por ejemplo, un atacante podría saber qué Prompts generan búsquedas en Internet que manipulen las visitas de un recurso, o consumos de APIs o llamadas a servicios y hacerlo en su provecho.
Similar al caso anterior, pero en este caso el LLM está conectado con un sistema en el que se pueden ejecutar comandos, como por ejemplo un API o una llamada a un comando de shell. Un ejemplo sería un LLM que utiliza una llamada al sistema para buscar un recurso, y un atacante podría engañarle usando el Prompt para que esa llamada llevara un comando no deseado que hiciera una acción maliciosa en el sistema. Podría decirle que busque a ver si se encuentra el fichero -> fake.doc"; shutdown y terminar con la ejecución de un comando en una shell de un sistema.
Como no, si podemos ejecutar llamadas a APIs, porque no hacer un SQL Injection desde el backend del LLM a un backend de una DMZ. O hacer un escaneo de puertos y servicios, o incluso utilizar el LLM como forma de realizar un Connection String Parameter Pollution. Si al final el LLM está conectado a llamadas HTTP vía API en una red, podría manipularse el Prompt para hacer todo este tipo de ataques.
Este fallo habla de las implicaciones que puede tener un LLM entrenados con datos parciales, incorrectos o inexactos, y lo que puede impactar en las organizaciones que confían en aplicaciones de negocio que están basadas en un LLM con esta vulnerabilidad. El impacto puede ser grande en los parámetros que supuestamente tenía que arreglar.
En este caso se trata de modelos LLM que han sido entrenados con datas que no están alineados, para nada, con el problema que tratan de solucionar. Es decir, se ha entrenado a un modelo con datos que no permiten que el LLM pueda resolver el ámbito de trabajo que se espera de él.
Figura 4: OWASP Top 10 List for LLMs version 0.1
Si entendemos que un LLM es una base de datos de conocimiento, hay que entender que la gestión de controles de acceso a estos LLMs debe estar fortificada. Saber qué usuarios pueden acceder a qué LLMs en un sistema, va a ser una pieza importante en la seguridad de la aplicación completa. Gestionar correctamente los mecanismos de seguridad para garantizar un control de acceso robusto, va a ser clave.
Si vienes del mundo del hacking de tecnologías web, este te lo sabes de memoria. Durante muchos años he escritos sobre la información que sale en los mensajes de error, que pueden ser utilizados para extraer datos del sistema. Desde las páginas web que daban los nombres de los archivos que buscabas, o los servidores, hasta los errores ODBC de bases de datos que te daban los datos que buscabas. Lo mismo, pero con errores provenientes del sistema manejado por el LLM.
Imagina un acceso a un recurso externo, y con una manipulación del Prompt se puede hacer generar comandos con errores, y estos mensajes de error llegan a la respuesta del LLM.
Y este último, muy del mundo de la IA. Se trata de saber con qué datos se entrena el LLM, manipularlos con información falsa, errónea o intencionada, y cuando el LLM se re-entrene, el sistema que se base en él va a estar obteniendo resultados manipulados por el atacante en base a una manipulación envenenada de los datos de entrenamiento.
Y vendrá mucho más
Como veis, con la llegada de los Large Language Models, vamos a tener un montón de aplicaciones que van a funcionar basadas en las respuestas que ellos den, y más vale que tengamos cuidado, porque el hacking de LLMs es una disciplina que en el mundo del pentesting, la auditoría, y los equipos de Red Team va a dar mucho trabajo. Pero también en el lado contrario. El análisis forense, el debugging, la fortificación en el Blue Team, y la auditoría del proceso de construcción. Apasionante lo que nos viene ya.
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)
No hay comentarios:
Publicar un comentario