[08/06/2023] El Open Worldwide Application Security Project (OWASP) ha publicado las 10 vulnerabilidades más críticas que suelen encontrarse en aplicaciones basadas en grandes modelos de lenguaje (LLM, por sus siglas en inglés), destacando su impacto potencial, facilidad de explotación y prevalencia. Entre los ejemplos de vulnerabilidades se incluyen inyecciones puntuales, fuga de datos, sandboxing inadecuado y ejecución no autorizada de código.
La lista tiene como objetivo educar a los desarrolladores, diseñadores, arquitectos, gerentes y organizaciones sobre los riesgos potenciales de seguridad al desplegar y gestionar LLM, aumentar la conciencia de las vulnerabilidades, sugerir estrategias de remediación y mejorar la postura de seguridad de las aplicaciones LLM, sostuvo OWASP.
La aparición de interfaces de chat de IA generativa construidas sobre LLM y su impacto en la ciberseguridad es un tema de conversación importante. Las preocupaciones sobre los riesgos que podrían introducir estas nuevas tecnologías van desde los posibles problemas de compartir información empresarial sensible con algoritmos avanzados de aprendizaje automático, hasta que los actores maliciosos las utilicen para mejorar significativamente los ataques. Algunos países, estados de EE.UU. y empresas están considerando o han ordenado prohibir el uso de tecnología de IA generativa como ChatGPT por motivos de seguridad, protección y privacidad de los datos.
Estas son las 10 vulnerabilidades más críticas que afectan a las aplicaciones LLM, según el OWASP.
1. Inyecciones de prompts
Las inyecciones de prompts implican eludir filtros o manipular el LLM utilizando comandos cuidadosamente diseñados que hacen que el modelo ignore instrucciones previas o realice acciones no deseadas, escribió el OWASP. "Estas vulnerabilidades pueden conducir a consecuencias no deseadas, incluida la fuga de datos, el acceso no autorizado u otras brechas de seguridad". Las vulnerabilidades comunes de inyección de comandos incluyen eludir filtros o restricciones mediante el uso de patrones de lenguaje o tokens específicos, explotar debilidades en los mecanismos de tokenización o codificación del LLM, y engañar al LLM para que realice acciones no deseadas proporcionando un contexto engañoso.
Un ejemplo de escenario de ataque es el de un usuario malintencionado que elude un filtro de contenidos utilizando patrones lingüísticos, tokens o mecanismos de codificación específicos que el LLM no reconoce como contenido restringido, lo que permite al usuario realizar acciones que deberían estar bloqueadas, señala el OWASP.
Las medidas preventivas para esta vulnerabilidad incluyen:
- Implementar una estricta validación de entrada y sanitización para los mensajes proporcionados por el usuario.
- Utilizar un filtrado y una codificación de salida que tengan en cuenta el contexto para evitar la manipulación de los mensajes.
- Actualizar y ajustar periódicamente el LLM para mejorar su comprensión de las entradas maliciosas y los casos extremos.
2. Fuga de datos
La fuga de datos ocurre cuando un LLM revela accidentalmente información sensible, algoritmos propietarios u otros detalles confidenciales a través de sus respuestas. "Esto puede resultar en acceso no autorizado a datos sensibles o propiedad intelectual, violaciones de privacidad y otras brechas de seguridad", señaló el OWASP.
El filtrado incompleto o inadecuado de información sensible en las respuestas del LLM, la sobreadaptación/memorización de datos sensibles en el proceso de entrenamiento del LLM, y la divulgación involuntaria de información confidencial debido a errores o malas interpretaciones del LLM, son vulnerabilidades comunes de fuga de datos. Un atacante podría sondear deliberadamente al LLM con preguntas cuidadosamente diseñadas, intentando extraer información sensible que el LLM haya memorizado de sus datos de entrenamiento, o un usuario legítimo podría hacer inadvertidamente al LLM una pregunta que revele información sensible/confidencial, escribió el OWASP.
Las medidas preventivas para la fuga de datos incluyen:
- Implementar un estricto filtrado de salida y mecanismos conscientes del contexto para evitar que el LLM revele información sensible.
- Utilizar técnicas de privacidad diferencial u otros métodos de anonimización de datos durante el proceso de entrenamiento del LLM para reducir el riesgo de sobreajuste o memorización.
- Auditar y revisar periódicamente las respuestas del LLM para garantizar que no se revele información sensible de forma inadvertida.
3. Aislamiento inadecuado
Si un LLM no está correctamente aislado cuando tiene acceso a recursos externos o sistemas sensibles, un sandboxing inadecuado puede conducir a una posible explotación, acceso no autorizado o acciones no intencionadas por parte del LLM. Según el OSWAP, la separación insuficiente del entorno LLM de otros sistemas o almacenes de datos críticos, las restricciones inadecuadas que permiten que el LLM acceda a recursos sensibles, y los LLM que realizan acciones a nivel de sistema o interactúan con otros procesos, son vulnerabilidades comunes de un aislamiento inadecuado de LLM.
Un ejemplo de ataque sería el de un actor malintencionado que se aprovecha del acceso de un LLM a una base de datos sensible mediante la creación de mensajes que ordenan al LLM extraer y revelar información confidencial.
Las medidas preventivas incluyen:
- Aislar el entorno del LLM de otros sistemas y recursos críticos.
- Restringir el acceso del LLM a recursos sensibles y limitar sus capacidades al mínimo necesario para su finalidad prevista.
- Auditar y revisar periódicamente el entorno del LLM y los controles de acceso para garantizar que se mantiene el aislamiento adecuado.
4. Ejecución no autorizada de código
La ejecución no autorizada de código se produce cuando un atacante aprovecha un LLM para ejecutar código, comandos o acciones maliciosas en el sistema subyacente a través de mensajes en lenguaje natural. Entre las vulnerabilidades más comunes se incluyen la entrada de usuario no desinfectada o restringida, que permite a los atacantes crear mensajes que desencadenan la ejecución de código no autorizado, restricciones insuficientes en las capacidades del LLM, y la exposición involuntaria de funcionalidades o interfaces a nivel de sistema al LLM.
El OWASP citó dos ejemplos de ataque: un atacante que elabora un aviso que instruye al LLM para ejecutar un comando que lanza un shell inverso en el sistema subyacente, otorgando al atacante acceso no autorizado, y el LLM que involuntariamente se le permite interactuar con una API a nivel de sistema, que un atacante manipula para ejecutar acciones no autorizadas en el sistema.
Los equipos pueden ayudar a prevenir la ejecución de código no autorizado con estas acciones:
- Implemente procesos estrictos de validación y desinfección de entradas para evitar que el LLM procese solicitudes maliciosas o inesperadas.
- Garantizar un sandboxing adecuado y restringir las capacidades del LLM para limitar su capacidad de interactuar con el sistema subyacente.
5. Vulnerabilidades de falsificación de peticiones del lado del servidor
Las vulnerabilidades de falsificación de solicitud del lado del servidor (SSRF, por sus siglas en inglés) se producen cuando un atacante aprovecha un LLM para realizar solicitudes no deseadas o acceder a recursos restringidos como servicios internos, API o almacenes de datos. Según el OWASP, las vulnerabilidades SSRF más comunes son una validación de entrada insuficiente, que permite a los atacantes manipular los mensajes del LLM para iniciar solicitudes no autorizadas, y una configuración incorrecta de los parámetros de seguridad de la red o de la aplicación, que expone los recursos internos al LLM.
Para ejecutar un ataque, un atacante podría crear un mensaje que ordene al LLM realizar una petición a un servicio interno, saltándose los controles de acceso y obteniendo acceso no autorizado a información sensible. También podrían explotar una configuración errónea en los ajustes de seguridad de la aplicación que permita al LLM interactuar con una API restringida, accediendo o modificando datos sensibles.
Las medidas preventivas incluyen:
- Implementar una rigurosa validación y sanitización de entradas para evitar que peticiones maliciosas o inesperadas inicien solicitudes no autorizadas.
- Auditar y revisar periódicamente la configuración de seguridad de la red/aplicación para garantizar que los recursos internos no queden expuestos inadvertidamente al LLM.
6. Confianza excesiva en el contenido generado por el LLM
La confianza excesiva en el contenido generado por el LLM puede conducir a la propagación de información engañosa o incorrecta, a la disminución de la aportación humana en la toma de decisiones y a la reducción del pensamiento crítico, según el OSAWP. "Las organizaciones y los usuarios pueden confiar en el contenido generado por LLM sin verificación, lo que conduce a errores, falta de comunicación o consecuencias no deseadas". Los problemas comunes relacionados con la confianza excesiva en el contenido generado por LLM incluyen aceptar el contenido generado por LLM como un hecho sin verificación, asumir que el contenido generado por LLM está libre de prejuicios o información errónea, y confiar en el contenido generado por LLM para tomar decisiones críticas sin aporte humano o supervisión, agregó el OWASP.
Por ejemplo, si una empresa confía en un LLM para generar informes y análisis de seguridad y el LLM genera un informe con datos incorrectos que la empresa utiliza para tomar decisiones de seguridad críticas, podría haber repercusiones significativas debido a la confianza en el contenido inexacto generado por el LLM. Rik Turner, analista principal de ciberseguridad en Omdia, se refiere a esto como alucinaciones del LLM. "Si dice tonterías y el analista puede identificarlas fácilmente, puede rechazarlas y ayudar a entrenar el algoritmo. Pero ¿y si la alucinación es muy verosímil y se parece a la realidad? En otras palabras, ¿podría de hecho el LLM dar más credibilidad a un falso positivo, con consecuencias potencialmente nefastas si el analista se adelanta y tumba un sistema o bloquea la cuenta de un cliente de alto patrimonio durante varias horas?".
7. Alineación inadecuada de la IA
Una alineación inadecuada de la IA ocurre cuando los objetivos y el comportamiento del LLM no se alinean con el caso de uso previsto, lo que lleva a consecuencias no deseadas o vulnerabilidades. Los objetivos mal definidos que dan lugar a que el LLM priorice comportamientos no deseados / perjudiciales, las funciones de recompensa mal alineadas o los datos de entrenamiento que crean un comportamiento no deseado del modelo, y las pruebas y validación insuficientes del comportamiento del LLM son problemas comunes, escribió el OWASP. Si un LLM diseñado para ayudar en las tareas de administración del sistema está mal alineado, podría ejecutar comandos dañinos o priorizar acciones que degraden el rendimiento o la seguridad del sistema.
Los equipos pueden prevenir las vulnerabilidades de alineación inadecuada de los LLM con estas acciones:
- Definir los objetivos y el comportamiento previsto del LLM durante el proceso de diseño y desarrollo.
- Asegurarse de que las funciones de recompensa y los datos de entrenamiento están alineados con los resultados deseados, y no fomentan comportamientos no deseados o perjudiciales.
- Pruebe y valide regularmente el comportamiento del LLM en una amplia gama de escenarios, entradas y contextos para identificar y abordar los problemas de alineación.
8. Controles de acceso insuficientes
Los controles de acceso insuficientes se producen cuando los controles de acceso o los mecanismos de autenticación no se implementan correctamente, lo que permite que usuarios no autorizados interactúen con el LLM y exploten potencialmente las vulnerabilidades. No aplicar requisitos estrictos de autenticación para acceder al LLM, una implementación inadecuada del control de acceso basado en roles (RBAC, por sus siglas en inglés) que permita a los usuarios realizar acciones más allá de sus permisos previstos, y no proporcionar controles de acceso adecuados para el contenido y las acciones generadas por el LLM son ejemplos comunes, dijo el OWASP.
Un ejemplo de ataque es un actor malicioso que obtiene acceso no autorizado a un LLM debido a mecanismos de autenticación débiles, lo que le permite explotar vulnerabilidades o manipular el sistema, sostuvo el OWASP.
Las medidas preventivas incluyen:
- Implementar mecanismos de autenticación fuertes, como la autenticación multifactor (MFA), para garantizar que sólo los usuarios autorizados puedan acceder al LLM.
- Implementar controles de acceso adecuados para el contenido y las acciones generadas por el LLM para evitar el acceso no autorizado o la manipulación.
9. Manejo inadecuado de errores
La gestión inadecuada de errores se produce cuando los mensajes de error o la información de depuración se exponen de forma que puedan revelar información confidencial, detalles del sistema o posibles vectores de ataque a un agente de amenazas. Las vulnerabilidades más comunes en la gestión de errores incluyen la exposición de información sensible o detalles del sistema a través de mensajes de error, la filtración de información de depuración que podría ayudar a un atacante a identificar posibles vulnerabilidades o vectores de ataque, y el no gestionar los errores con elegancia, causando potencialmente un comportamiento inesperado o caídas del sistema.
Por ejemplo, un atacante podría explotar los mensajes de error de un LLM para recopilar información sensible o detalles del sistema, lo que le permitiría lanzar un ataque dirigido o explotar vulnerabilidades conocidas. Por otra parte, un desarrollador podría dejar accidentalmente expuesta información de depuración en producción, lo que permitiría a un atacante identificar posibles vectores de ataque o vulnerabilidades en el sistema, según el OWASP.
Estos riesgos pueden mitigarse con las siguientes acciones:
- Implemente mecanismos adecuados de gestión de errores para garantizar que los errores se detectan, registran y gestionan.
- Asegúrese de que los mensajes de error y la información de depuración no revelen información sensible o detalles del sistema. Considere el uso de mensajes de error genéricos para los usuarios, mientras que el registro de información detallada de error para los desarrolladores y administradores.
10. Envenenamiento de datos de entrenamiento
El envenenamiento de los datos de entrenamiento se produce cuando un atacante manipula los datos de entrenamiento o los procedimientos de ajuste fino de un LLM para introducir vulnerabilidades, puertas traseras o sesgos que podrían comprometer la seguridad, la eficacia o el comportamiento ético del modelo, escribió el OWASP. Los problemas comunes de envenenamiento de datos de entrenamiento incluyen la introducción de puertas traseras o vulnerabilidades en el LLM a través de datos de entrenamiento manipulados maliciosamente, y la inyección de sesgos en el LLM haciendo que produzca respuestas sesgadas o inapropiadas.
Estas acciones pueden ayudar a prevenir este riesgo:
- Garantizar la integridad de los datos de entrenamiento obteniéndolos de fuentes fiables y validando su calidad.
- Aplicar técnicas sólidas de depuración y preprocesamiento de datos para eliminar posibles vulnerabilidades o sesgos de los datos de entrenamiento.
- Utilizar mecanismos de supervisión y alerta para detectar comportamientos inusuales o problemas de rendimiento en el LLM, que podrían indicar un envenenamiento de los datos de entrenamiento.
Líderes/equipos de seguridad, organizaciones responsables del uso seguro de los LLM
Los líderes/equipos de seguridad y sus organizaciones son responsables de garantizar el uso seguro de las interfaces de chat de IA generativa que utilizan LLM, coinciden los expertos. "Los equipos de seguridad y legales deben colaborar para encontrar el mejor camino a seguir para que sus organizaciones aprovechen las capacidades de estas tecnologías sin comprometer la propiedad intelectual o la seguridad", señaló recientemente a CSO Chaim Mazal, CSO de Gigamon.
Los chatbots impulsados por IA necesitan actualizaciones periódicas para seguir siendo eficaces contra las amenazas, y la supervisión humana es esencial para garantizar que los LLM funcionen correctamente, añadió Joshua Kaiser, ejecutivo de tecnología de IA y CEO de Tovie AI. "Además, los LLM necesitan comprensión contextual para proporcionar respuestas precisas y detectar cualquier problema de seguridad, y deben probarse y evaluarse regularmente para identificar posibles debilidades o vulnerabilidades".
Basado en el artículo de Michael Hill (CSO) y editado por CIO Perú
Puede ver también: