El año pasado, el Proyecto Abierto Mundial de Seguridad de Aplicaciones (OWASP) publicó varias versiones del «OWASP Top 10 para modelos de lenguajes grandes,» alcanzando un documento 1.0 en agosto y un documento 1.1 en octubre. Estos documentos no sólo demuestran la naturaleza en rápida evolución de los modelos de lenguaje grandes, sino también las formas en evolución en las que se pueden atacar y defender. Vamos a hablar en este artículo sobre cuatro elementos de ese top 10 que son más capaces de contribuir a la divulgación accidental de secretos como contraseñas, claves API y más.
Ya somos conscientes de que los LLM pueden revelar secretos porque ya sucedió. A principios de 2023, GitGuardian informó que encontró más de 10 millones de secretos en confirmaciones públicas de Github. La herramienta de codificación Copilot AI de Github se entrenó en confirmaciones públicas y, en septiembre de 2023, investigadores de la Universidad de Hong Kong publicaron un artículo sobre cómo crearon un algoritmo que generó 900 mensajes diseñados para que Copilot revelara secretos de sus datos de entrenamiento. Cuando se utilizaron estas indicaciones, Copilot reveló más de 2700 secretos válidos.
La técnica utilizada por los investigadores se llama «inyección rápida». Es el número 1 en el Top 10 de OWASP para LLM y lo describen de la siguiente manera: [blockquote]
«Esto manipula un modelo de lenguaje grande (LLM) a través de entradas astutas, lo que provoca acciones no deseadas por parte del LLM. Las inyecciones directas sobrescriben las indicaciones del sistema, mientras que las indirectas manipulan entradas de fuentes externas».
Es posible que esté más familiarizado con la inyección rápida del error revelado el año pasado que hacía que ChatGPT comenzara a escupir datos de entrenamiento si le pedía que repitiera ciertas palabras para siempre.
Consejo 1: rota tus secretos
Incluso si no cree que haya publicado secretos accidentalmente en GitHub, varios de los secretos allí se confirmaron en una confirmación temprana y se bloquearon en una confirmación más reciente, por lo que no son evidentes sin revisar todo su historial de confirmaciones, no solo el estado actual de sus repositorios públicos.
Una herramienta de GitGuardian, llamada ¿Se ha filtrado mi secreto?, le permite cifrar con hash un secreto actual y luego enviar los primeros caracteres del hash para determinar si hay coincidencias en su base de datos con lo que encuentran en sus escaneos de GitHub. Una coincidencia positiva no es una garantía de que su secreto se filtró, pero brinda una probabilidad potencial de que así sea, por lo que puede investigar más a fondo.
Las advertencias sobre la rotación de claves/contraseñas son que debe saber dónde se utilizan, qué podría fallar cuando cambian y tener un plan para mitigar esa falla mientras los nuevos secretos se propagan a los sistemas que los necesitan. Una vez rotados, debes asegurarte de que los secretos más antiguos hayan sido desactivados.
Los atacantes no pueden usar un secreto que ya no funciona y si sus secretos que podrían estar en un LLM han sido rotados, entonces se convierten en nada más que cadenas inútiles de alta entropía.
Consejo 2: limpia tus datos
El elemento número 6 en el Top 10 de OWASP para LLM es «Divulgación de información confidencial»:
Los LLM pueden revelar inadvertidamente datos confidenciales en sus respuestas, lo que da lugar a acceso no autorizado a datos, violaciones de privacidad y violaciones de seguridad. Es crucial implementar desinfección de datos y políticas estrictas de usuario para mitigar esto.
Si bien las indicaciones diseñadas deliberadamente pueden hacer que los LLM revelen datos confidenciales, también pueden hacerlo accidentalmente. La mejor manera de garantizar que el LLM no revele datos confidenciales es asegurarse de que el LLM nunca lo sepa.
Esto se centra más en cuando estás capacitando a un LLM para que lo utilicen personas que no siempre se preocupan por sus mejores intereses o personas que simplemente no deberían tener acceso a cierta información. Ya sean sus secretos o su salsa secreta, solo aquellos que necesitan acceder a ellos deben tenerlos… y su LLM probablemente no sea una de esas personas.
El uso de herramientas de código abierto o servicios pagos para escanear sus datos de entrenamiento en busca de secretos ANTES de enviar los datos a su LLM lo ayudará a eliminar los secretos. Lo que su LLM no sabe, no lo puede decir.
Consejo 3: aplique parches periódicamente y limite los privilegios
Recientemente vimos un artículo sobre el uso de archivos .env y variables de entorno como una forma de mantener secretos disponibles para su código, pero fuera de su código. Pero, ¿qué pasaría si a su LLM se le pudiera pedir que revelara variables ambientales… o que hiciera algo peor?
Esto combina el punto n.° 2 («Manejo de resultados inseguro») y el punto n.° 8 («agencia excesiva»).
- Manejo de salida inseguro: Esta vulnerabilidad se produce cuando se acepta un resultado de LLM sin escrutinio, lo que expone los sistemas backend. El uso indebido puede tener consecuencias graves como XSS, CSRF, SSRF, escalada de privilegios o ejecución remota de código.
- Agencia excesiva: Los sistemas basados en LLM pueden emprender acciones que conduzcan a consecuencias no deseadas. El problema surge de una funcionalidad, permisos o autonomía excesivos otorgados a los sistemas basados en LLM.
Es difícil separarlos porque pueden empeorar mutuamente. Si se puede engañar a un LLM para que haga algo y su contexto operativo tiene privilegios innecesarios, se multiplica el potencial de que la ejecución de un código arbitrario cause un daño importante.
Todos los desarrolladores han visto el «Hazañas de una mamá«caricatura donde aparece un niño llamado `Robert»); DROP TABLE Students;»` borra la base de datos de estudiantes de una escuela. Aunque un LLM parece inteligente, en realidad no es más inteligente que una base de datos SQL. Y al igual que su hermano «comediante» hace que su sobrino pequeño le repita malas palabras a la abuela, las malas entradas pueden crear malos resultados Ambos deben ser desinfectados y considerados no confiables.
Además, es necesario establecer barreras de seguridad sobre lo que el LLM o la aplicación pueden hacer, considerando el principio de privilegio mínimo. Esencialmente, las aplicaciones que usan o habilitan el LLM y la infraestructura del LLM no deben tener acceso a ningún dato o funcionalidad que no necesiten en absoluto, para que no puedan ponerlo accidentalmente al servicio de un hacker.
Todavía se puede considerar que la IA está en su infancia y, como ocurre con cualquier bebé, no se le debe dar libertad para deambular por ninguna habitación que no haya sido a prueba de bebés. Los LLM pueden malinterpretar, alucinar y dejarse llevar deliberadamente por el mal camino. Cuando eso sucede, buenas cerraduras, buenas paredes y buenos filtros deberían ayudar a evitar que accedan o revelen secretos.
En resumen
Los modelos de lenguaje grandes son una herramienta increíble. Están destinados a revolucionar una serie de profesiones, procesos e industrias. Pero son lejos de una tecnología madura, y muchos los están adoptando imprudentemente por miedo a quedarse atrás.
Como lo haría con cualquier bebé que haya desarrollado suficiente movilidad como para meterse en problemas, debe vigilarlo y cerrar con llave los gabinetes en los que no quiera que entre. Continúe con modelos de lenguaje grandes, pero con precaución.
