Codebreaker, TrojanPuzzle, Covert & Simple: Cómo envenenar LLMs para inyectar Bugs & Backdoors en los programas que haces con los Copilots de Developers

Los LLMs creados para ayudar a los developers para generar tecnología se usan para muchas tareas, como es el caso de GitHub Copilot, Code Whisperer o cualquier solución con GPT4. Por supuesto, para tirar líneas de código sugiriendo la siguiente instrucción a escribir mediante un proceso de Code Completion, aunque también se pueden utilizar para arreglar programas, factorizar el código, sugerir mejoras de optimización, o documentarlo. Es una herramienta fundamental para los developers y por eso las líneas de investigación en este campo es una de las más activas.

Nosotros decidimos comenzar a utilizar GitHub Copilot hace dos años, y la idea es seguir profundizando cada vez más en su uso, pero tenemos claro que la seguridad es algo aún una línea en la que se tiene trabajar, como hemos visto en muchos estudios. En el año 2021 tuvimos ya los primeros artículos académicos sobre el código inseguro y vulnerable generado por GitHub Copilot. 

Nosotros estuvimos probando en nuestro equipo de Ideas Locas cómo era cierto que te generaba código inseguro y vulnerable con bugs conocidos. Por supuesto, si vamos a modelos LLM generalistas, donde no se metían validaciones extra de seguridad, podrías encontrarte bugs SQL Injection de libro, pidiéndole a ChatGPT un procedimiento en PHP para autenticar una página web, tal y como veis a continuación.

De hecho, un estudio de Diciembre del año 2022 lo que venían a decir es que quedaba trabajo que hacer, ya que los programadores que usaban los asistentes de Code Completion basados en LLMs hacían código con más vulnerabilidades que los que no lo hacían.

Por supuesto, en estos modelos se han ido añadiendo protecciones para detectar si un código generado en la salida de un Prompt es inseguro, y hoy en día se pasan los códigos por herramientas de Análisis Estático de código para detectar la inyección de vulnerabilidades en el código sugerido por el LLM. 

Esto ha abierto otra línea de investigación, que tiene que ver no ya con detectar el código vulnerable sino en ver si es posible envenenar maliciosamente el LLM para hacer que el código que salga sea inseguro. Una forma de poner el backdoor en el código mediante un ataque al Copilot. Al final, la idea es tan sencilla como envenenar los datos de entrenamiento programas inseguros, que es lo que sucedió de manera natural para que GitHub Copilot, ChatGPT o CodeWhisperer generen código inseguro ( o API Keys y Secretos ).

Los trabajos anteriores de estas técnicas, se basan en tres métodos, conocidos como SIMPLE, COVERT y TROJANPUZZLE. El primero de ellos, es tan simple como reemplazar el código seguro por el código inseguro sin hacer nada más. Esto lógicamente generará que si hay alguna herramienta de Análisis Estático de Código, que sea detectado.

Una segunda aproximación es la que propone COVERT, que se basa en meter los payloads en DocStrings, como si fueran comentarios. Al final son textos que el LLM utilizará también para ser entrenado, y por tanto envenenará su aprendizaje. 

Por supuesto, si el proceso de Data Curation elimina los comentarios, resuelto el problema, por eso el paper anterior proponía un método de envenenamiento dividiendo el payload malicioso con la vulnerabilidad que implanta el Bug o Backdoor en el código usando varias partes. Es decir, resolviendo un puzzle parte a parte en la inyección del código.

El último es CODEBREAKER, que es de lo que trata el artículo «An LLM-Assisted Easy-to-Trigger Backdoor Attack on Code Completion Models: Injecting Disguised Vulnerabilities against Strong Detection» del que quería hablaros hoy, que me ha gustado mucho su aproximación, y que podéis leer ahí mismo, pero que yo voy a intentar resumiros.

En este caso el objetivo es ver cómo se pueden hacer envenenamiento de datos para que el LLM de Code Completion que haya sido entrenado con esos datos escupa código inseguro, incluso si tiene herramientas de validación de la salida usando herramientas de Análisis Estático del código. Es decir, el atacante tiene la posibilidad de poner código malicioso en su repositorio porque este va a ser utilizado para entrenar un LLM de Code Completion, pero… tiene protecciones de seguridad y no es tan fácil.

Si os fijáis en el gráfico anterior, para evitar el evenenamiento primero hay un proceso de Data Curation en el cuál se usa también LLMs (en este caso GPT-4) para hacer algo que también es parte de la labor de los LLMs en el proceso de ayudar a la creación de tecnología, que es la búsqueda de vulnerabilidades. En este artículo «Cómo buscar vulnerabilidades en SmartContracts, SQL Injection, XSS o bugs Python con ChatGPT»  os ponía algunos ejemplos de esto. 

El objetivo de ese proceso es descartar de los datos de entrenamiento a aquellos códigos que sean inseguros para que no esté entrenado con ellos. Así que conseguir el bug inyectado en el repositorio malicioso llegue al modelo de entrenamiento exige hacer un proceso de «Smuggling» o «Contrabando» del bug. Es decir, ocultar el bug en el proceso de análisis. Este proceso se hace mediante un Payload Transformation que busca saltarse las herramientas como podéis ver en el gráfico siguiente.

Esto es mucho más fácil de lo que parece. La idea es que el atacante sabe cuáles son las herramientas de Análisis Estático de Código con las que se está haciendo la detección de vulnerabilidades, así que antes de subir el código con bugs al repositorio de GitHub hay que hacer variaciones del payload hasta que se consiga que no sea detectado por ninguna o que tenga un scoring muy pequeño. Por supuesto, para hacer el Payload Transformation, nada mejor que utilizar un LLM como GPT-4, como podéis ver en la imagen.

En el ejemplo del artículo, las herramientas Análisis Estático de Código contra las que han evaluado los paylodas modificados han sido Bandit, CodeQL y SemGrep, que son Open Source, y contra las herramientas comerciales SnykCode y SonarCloud. Los datos que tenéis en la tabla siguiente se basan en probar tres bugs concretos (1),(2) y (3) que son primero variados con transformaciones pre-establecidas – un total de 36 – y que luego pasan por el proceso de Payload Transformation con GPT-4 cada una de ellas para conseguir 4 iteraciones más, y los resultados son los que tenéis aquí.

No siempre se consiguen pasar todas las herramientas, pero si el atacante sabe cuáles son las que utiliza ese LLM para hacer el Data Curation se puede afinar el ataque (ya sabes por qué es tan importante que no pongas en tu Linkedin las herramientas que usas en tus trabajo de seguridad). La tabla siguiente muestra que en una media de 3 iteraciones del Payload Transformation, para diferentes tipos de Bugs a inyectar, se supera el 100% de de las herramientas de Análisis Estático de Código y loas detecciones con 

Podría parecer que ya hemos conseguido el objetivo, pero nada de eso. Sólo hemos conseguido meter el payload con el bug en el Data Corpus de entrenamiento, pero ahora nos queda una segunda fase de seguridad, que es la que valida el código cuando el LLM de Code Competion lo va a escupiendo y que además este sea funcional. En este caso se trata de conseguir engañar también a cualquier otro análisis posterior, así que los investigadores añaden un proceso de ofuscación de código basado en las herramientas Pyarmor y Anubis, con el objetivo de que el payload que se inyecte en los programas sea de difícil descubrimiento para el developer o para otro programa no evaluado de Análisis Estático de código que haya verificando la salida.

¡Saludos Malignos!