Usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source

Fue allá por el año 2007 comencé a trabajar en las técnicas de LDAP Injection & Blind LDAP Injection que a la postre sería mi primera charla internacional en BlackHat Europe 2008, donde presenté el paper de "LDAP Injection & Blind LDAP Injection in Web Applications" que puedes ver online. En aquel entonces, busqué aplicaciones vulnerables que pudiera usar de ejemplo, y para ello tire de proyectos Open Source, haciendo dorkings y mucho Hacking con Buscadores para encontrar las víctimas propicias.

Figura 1: Usar Deep Reasoning en GitHub para buscar

( y parchear ) Bugs en proyectos Open Source

Una de ellas fue LABE (LDAP Address Book Editor) un aplicación web para tener una libreta de direcciones basada en un árbol LDAP. Por supuesto, vulnerable a las técnicas de LDAP Injection & Blind LDAP Injection.

Figura 2: El bug de LDAP Injection en el código fuente de LABE

Ayer, después de estar revisando un nuevo paper de cómo utilizar LLMs para hacer ataques de red - del que os hablaré muy prontito - me vino el pensamiento de sería mucho más fácil y más seguro si los repositorios de código fuente tuvieran ya metadatos de seguridad y bugs para todos los proyectos que hospedan analizados con modelos de Deep Reasoning.

Figura 3: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Repositorios que te alertan de los bugs

Es decir, tú vas a un proyecto OpenSource en GitHub u otros, y el repositorio ha revisado ya todo el código y muestra a los usuarios que se los van a descargar si tiene vulnerabilidades conocidas o no, para que no te lo descargues o para que le llegue un aviso al mantenedor de que ese código debe ser actualizado o se marcará como inseguro. Y que le de con GenAI opciones de parchear el código automáticamente, como hace la plataforma Plexicus, que está empujando José Palanco.

Figura 4: Plexicus parchea con GenAI los bugs

Ahora mismo, los repositorios tienen secciones de "issues" donde se pueden reportar bugs, fallos, warnings, etcétera, pero todos hechos por "humanos" por ahora, y tal vez deberían estar ya aprovechando el mundo de los LLMs para mejorar la seguridad de los proyectos OpenSource de "long-tail" de manera masiva. Yo he ido a probar con el repositorio de LABE y le he pasado el código a Perplexity Pro con Deep Research, y le he pedido que busque bugs en uno de los ficheros del proyecto, y me diga cómo parchearlos.

Figura 5: Bug de LDAP Injection alertada en LABE

El primero de todos los bugs que reporta es el que ya conocía yo de LDAP Injection, pero el proyecto sigue están disponible para que más usuarios se lo descarguen sin ningún warning, y la lista de bugs es más larga.

Figura 6: LABE tiene bug de XSS persistente

Como podéis ver  en la imagen anterior, tiene un XSS persistente, pero a día de hoy cuenta también con funciones obsoletas, y acceso inseguro a variables globales como $_GET que además está obsoleta. Normal, este código tiene muchos años.

Figura 7: Más debilidades en el código de LABE

No se trata de "demonizar" LABE, sino de ver lo bien que lo hacen los modelos de Deep Reasoning para buscar debilidades y fortificaciones a un código Open Source en un repositorio, y que si lo hace el propio repositorio una vez, nos ahorramos hacerlo todos una y otra vez para ver qué nos estamos instalando.

Figura 8: CSRF y fallos de inicialización

No le he pasado todo el proyecto, sólo un fichero que ya tenía controlado con un LDAP Injection, pero como podéis ver en las imágenes ha salido también XSS, CSRF que son Client-Side Attacks, errores no controlados, variables sin inicializar, uso de funciones deprecadas, etcétera, lo que sería información muy valiosa que podría venir en los repositorios de código como GitHub y los gestores de paquetes.

Figura 9: Bug CVE-2024-35226

También nos aparece un bug en la "cadena de suministro", ya que en el año 2024 se reportó un bug con severidad 7.3 en el framework de smarty que permite inyección de código, lo que demuestra que hay que tener un control constante de tus librerías para evitar estos peligros.

Análisis con DeepSeek Deep Think R1 

He querido probar con un repo de GitHub que también hace uso de búsquedas en árboles LDAP y que en este caso está escrito en C++, para ver cómo hace el análisis, y si GitHub podría hacer este análisis con su GitHub Copilot y dejar la info en forma de Warnings a los que se descargan el código.

Figura 10: QLDAP Editor en GitHub

Entiendo que poner issues de seguridad en los repos puede ayudar a los atacantes, pero es que los atacantes pueden hacer este trabajo, tener un 0day de un repo de long-tail y tener a GitHub entregando descargas a nuevas víctimas durante años.

Figura 11: Thinking de Deep Seek

Os ahorro las capturas del Prompt donde le paso el código del fichero que ves en la Figura 9 y le pido que busque bugs y me diga cómo corregirlos. Pero en la Figura 10 tenéis el Thinking que sí es interesante, pues en 19 segundos analiza el código y saca los resultados.

Figura 12: DeepSeek reporta un LDAP Injection

Como se puede ver, lo que reporta es  un LDAP Injection en primer lugar, ya que construye los filtros LDAP de las consultas sin ninguna sanitización, y eso se puede ver en el código como os dejo a continuación.

Figura 13: Construcción de filtros LDAP inseguros

Pero es que el análisis completo es bastante bueno, ya que sigue analizando el código y todas las implicaciones y las explica muy bien. Por ejemplo, cómo acceder con la inyección a atributos sensibles como passwords que pudieran existir en el árbol LDAP.

Figura 14: Explotación de LDAP Injection con manipulación de parámetros

En la siguiente imagen vemos cómo reporta también un problema de flujo de la lógica al no escapar los caracteres de control de LDAP que podrían cmabiar el comportamiento.

Figura 15: Escapado de caracteres de control

Y si seguimos viendo el informe, podemos ver cómo el tratamiento de errores no es seguro, permitiendo problemas en el funcionamiento del programa pero también Data Leaks de la estructura de la red al no haber controlado los errores de conexión al árbol LDAP.

Figura 16: Errores no controlados.

Para terminar aún nos da unas recomendaciones más que sensatas de seguridad añadidas que deberían ser tenidas en cuenta, como son estas dos, que yo las tendría en cuenta. Este código no lo conocía de antes, ni sabía si era vulnerable a LDAP Injection o no, y ni mucho menos del resto, pero si miráis en los issues, no hay nada de esto. 

Figura 17: Recomendaciones finales

Al final, desde hace años ya conocemos las capacidades de los LLMs para buscar bugs, esto es de lo primero que probamos, por supuesto. Así que si las usamos para fomentar que los proyectos OpenSource alerten a los usuarios que se los descargan, para que los repositorios de código incentiven a los mantenedores a parchearlos, o que lo hagan de forma automática ayudaría a reducir los bugs que acaban en los servidores de las víctimas.

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

(New) WordPress in Paranoid Mode!

Quizás recuerdes, ya hace algunos años, una PoC que hicimos sobre cómo proteger WordPress en modo paranoico donde, además de proteger el login del usuario con el plugin de Latch para Wordpress y hacer un hardening a Wordpress y a nivel del sistema operativo bloqueando el acceso SSH con el plugin de Latch para UNIX, se hacía una protección a nivel de base de datos con la creación de distintos triggers que permiten proteger las operaciones INSERT, UPDATE & DELETE.

Figura 1: (New) WordPress in Paranoid Mode!

Este trabajo se plasmó en diferentes conferencias dónde Chema Alonso habló sobre ello y la importancia que tiene el controlar, a través de un segundo factor de autorización, la modificación de los datos o de la información. En la charla “My Wordpress in Paranoid Mode”, Chema, hablaba de ello en Open Expo en el año 2016:


Figura 2: My WordPress in Paranoid Mode

Además, se puede seguir teniendo acceso al repositorio del año 2016 a través de su enlace en Github, aunque actualmente no es funcional debido a dependencias de alguna librería para MySQL. Esto supuso un reto para nosotros, ya que queríamos hacer que las dependencias desapareciesen. 

Figura 3: Máxima Seguridad en WordPress

En la nueva versión de Wordpress in Paranoid Mode se ha conseguido, ya que hemos creado una arquitectura dónde se mejora en rendimiento y ‘delays’ respecto a la prueba de concepto primera. Ya no dependemos de la red, por lo que la latencia es disminuida drásticamente.

Figura 4: (New) WordPress in Paranoid Mode!

Para los más técnicos, os dejamos un pequeño workshop, de los 11PathsTalks dónde os explicamos cómo funciona WordPress in Paranoid Mode!  En este workshop se habla a bajo nivel de la solución propuesta y de cómo cubre la necesidad de tener el control de la edición y modificación del dato. 

Figura 5:  Workshop de WordPress in Paranoid Mode!

Esto ya permitía crear diferentes esquemas de dobles autorizaciones o flujos de aprobaciones que permiten controlar cuándo y cómo se van a modificar los datos o bajo qué circunstancias, además de lo que ya podías hacer de proteger el Login de WordPress con Latch.

Figura 6: Integración de Latch para proteger el Login de WordPress

A modo de resumen y con el objetivo de mostrar las novedades os comentamos cómo funciona este (new) Wordpress in Paranoid Mode. Para proteger la base de datos, se crean tres operaciones en la aplicación de Tu Latch que permiten el control de diferente manera:

• Read-Only: Este es el modo más restrictivo de todos. Cuando el pestillo está puesto en el en modo solo lectura, ningún usuario puede hacer login en WordPress. Únicamente se permite la lectura, por lo que no es posible realizar cambios en la base de datos (insertar, actualizar o eliminar).

• Edition: En este modo se protege la edición (tabla wp_posts), por lo que no se permite la creación de nuevos posts, ni la edición, ni la eliminación.

• Administration: Este modo permite proteger la creación, actualización o eliminación de usuarios, ya que actúa para proteger la tabla wp-users.

Cuando se desencadena un trigger, se comprueba el estado de Latch para ver si se tiene permitida la operación. Esto implica realizar una llamada al servicio de Latch cada vez que un trigger salta.

Figura 7: Operaciones para WordPress in Paranoid Mode

Ahora, hemos creado una nueva revisión de esta PoC, donde se han incluido algunas mejoras para adaptarlo a los flujos de trabajo actuales y se han optimizado algunos apartados. El mayor cambio, optimizando tiempos de respuesta y mejorando la eficiencia en el manejo de datos.

• En lugar de realizar una petición al servicio de Latch cada vez que se activa el trigger, se ha implementado el uso de los WebHooks que ofrece Latch. Esto ha sido una mejora notable para solventar problemas de latencia y de rendimiento.

• El agente conoce el estado de los pestillos (y se actualizan a través del WebHook). Esto permite mejorar la rapidez de las consultas para ver si se tiene al acceso a la creación, modificación o eliminación de la tabla de WordPress que se está protegiendo.

• Se ha desarrollado una GUI que te va guiando por distintos pasos para la instalación del agente en local y en remoto.

Figura 8: WordPress in Paranoid Mode Installer GUI

Para que la instalación se realice correctamente, hay algunos requisitos:

• Conexión con el motor de base de datos que contiene la base de datos de WordPress a proteger: Esta conexión debe hacerse con el usuario root. Esto es importante ya que se debe realizar la creación de la nueva base de datos que tendrá el estado de los pestillos por operación almacenados, así como la creación de un usuario para la gestión y consulta de esta tabla.

• Conexión con la aplicación de Latch: Se debe disponer de una cuenta de desarrollador de Latch para crear la aplicación y obtener su ID de aplicación y su secreto. De esta manera, el instalador creará las operaciones correspondientes (read-only, edition, administration) y las almacenará en la base de datos.

• Instalación del agente: El agente se ejecuta en segundo plano en una máquina con acceso desde internet y que será validado como el WebHook de la aplicación de Latch. Desde la GUI se puede instalar el agente en la máquina local o en una máquina remota a través de SSH. La máquina tiene que tener las siguientes dependencias instaladas: python3, python3-pip y gunicorn. Las pruebas de instalación de han ejecutado sobre la versión 3.12 de Python.

Tienes el nuevo código de WordPress in Paranoid Mode disponible en el repositorio de GitHub latch-plugin-wipm.

Figura 9: Instalación de WordPress in Paranoid Mode!

Justo en el vídeo de arriba te enseñamos funcionamiento del instalador, que como se puede ver es realmente sencillo y “friendly” para que lo puedas usar en tus fortificaciones de WordPress in Paranoid Mode! ... como debe de ser.

Figura 10: Tu Latch "Hack Your Innovation Contest".

Haz un PoC & Hack por 1.000 €

Por último, como sabéis, tenemos el Latch Hack Innovation Contest para que puedas hacer integraciones tan espectaculares como esta y ganarte un premio. En este artículo del blog puedes leer todos los detalles para que te lleves el premio: "Tu Latch "Hack Your Innovation Contest": Haz un PoC & Hack por 1.000 €"

<->Saludos y...

Happy Coding!

Pablo González Pérez, escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de Telefónica Innovación Digital.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Contactar con Pablo González

Álvaro Núñez-Romero, investigador en el equipo de Ideas Locas. Autor del libro "Arduino para Hackers (& Makers): PoCs and Hacks Just for Fun" y del VBOOK de "Arduino para Hackers (& Makers): PoCs and Hacks Just for Fun"

Contactar con Álvaro Núñez-Romero

Cursor: El primer IDE para developers Súper-Empowered con GenAI (Claude 3.5 Sonnet & GPT-4o

La inteligencia artificial ha transformado el desarrollo de software, y herramientas como ChatGPT o GitHub Copilot han demostrado cómo la IA puede hacer más accesibles y menos propensas a errores las tareas complejas de programación. Sin embargo, el verdadero cambio llega con Cursor, un editor de código que integra la Inteligencia Artificial en el núcleo del proceso de programación. A diferencia de otros editores, Cursor está diseñado desde cero para aprovechar al máximo las capacidades generativas de la IA, prometiendo una revolución en la manera en que los desarrolladores, tanto expertos como principiantes, abordan su trabajo diario.

Figura 1: Cursor - El primer IDE para developers Súper-Empowered

con GenAI (Claude 3.5 Sonnet & GPT-4o

Cursor es una plataforma que combina un entorno de desarrollo familiar, como Visual Studio Code, con un asistente de IA avanzado. Este editor permite generar, editar y depurar código utilizando comandos en lenguaje natural, lo que simplifica y optimiza el flujo de trabajo de los programadores. Desde su lanzamiento, Cursor ha sido adoptado por profesionales de empresas tecnológicas como Replicate, Midjourney, OpenAI, Perplexity y Shopify.

Figura 2: Ingenieros de empresas de renombre usando Cursor

  
El impacto de Cursor en la comunidad de desarrolladores ha sido notable, generando tanto entusiasmo como cautela. Mientras algunos ven en esta herramienta una revolución en la programación, otros se preguntan cómo afectará a largo plazo las habilidades fundamentales de los desarrolladores. A medida que Cursor gana tracción, surge un debate sobre el futuro de la programación asistida por IA y su posible influencia en el desarrollo de software en los próximos años.

¿Qué es Cursor?

Como ya he dicho, Cursor es un editor de código impulsado por Inteligencia Artificial, diseñado específicamente para integrar la IA en el núcleo del proceso de desarrollo de software. Derivado de Visual Studio Code, Cursor es un fork independiente que incorpora funcionalidades avanzadas de IA para transformar la programación en un proceso más eficiente, intuitivo y accesible. Esta herramienta permite a los desarrolladores interactuar con su código utilizando comandos en lenguaje natural, ofreciendo sugerencias contextuales, generando código automáticamente y optimizando el flujo de trabajo de manera proactiva.

Figura 3: About Anysphere

Cursor es el producto estrella de Anysphere, una startup tecnológica fundada por Michael Truell, Sualeh Asif, Arvid Lunnemark y Aman Sanger. La empresa ha logrado atraer una considerable atención y financiamiento, recaudando en 2023 8 millones de dólares en una ronda semilla respaldada por inversores del ecosistema de OpenAI, y recientemente, en Agosto de 2024, 60 millones de dólares. La filosofía de Anysphere y de Cursor se centra en democratizar el proceso de desarrollo de software, haciéndolo más accesible y eficiente, mientras prioriza la privacidad y la seguridad del código de los usuarios.

Funcionalidades clave

Las funcionalidades clave de Cursor se destacan por su integración con la inteligencia artificial, lo que transforma la experiencia de codificación en un proceso más eficiente y avanzado. Estas son algunas de las funcionalidades más importantes:

• Autocompletado Inteligente: Esta función ofrece sugerencias predictivas y adaptativas basadas en el contexto del código y los patrones de trabajo del desarrollador. No solo sugiere términos o líneas individuales, sino que es capaz de completar bloques enteros de código, lo que ahorra tiempo y reduce la posibilidad de errores, todo mientras se adapta al estilo de codificación del usuario.

Figura 4: Autocompletado Inteligente  

• Generación y Edición de Código: Esta funcionalidad permite a los desarrolladores generar código automáticamente a partir de descripciones en lenguaje natural y realizar ediciones inteligentes en el código existente. No solo traduce comandos verbales en código funcional, sino que también optimiza y corrige el código en tiempo real, mejorando su eficiencia y alineándolo con las mejores prácticas.

Figura 5: Generación de código con lenguaje natural

• Asistencia y Reescrituras Inteligentes: Cursor ofrece asistencia proactiva y reescrituras automáticas del código, detectando y corrigiendo errores mientras el desarrollador escribe. Su capacidad para realizar optimizaciones contextuales y refactorizaciones asegura que el código sea más limpio, eficiente y alineado con los estándares del proyecto, todo mientras se adapta a las preferencias del usuario.

Figura 6: Smart Rewrites y Cursor prediction

• Inserción de docs: Cursor te permite poder insertar documentación de cualquier framework, librería, etc. que te sea de utilidad en el proyecto, incluso puedes subir tu propia documentación, para posteriormente al realizar preguntas a los modelos de IA tengan como contexto estos documentos.

Figura 7: Use Documentation

Beneficios y limitaciones

Al ofrecer sugerencias proactivas para la re-escritura y optimización del código, la herramienta reduce la incidencia de errores comunes y fomenta la adopción de mejores prácticas de programación. Sin embargo, este beneficio tiene sus límites. A pesar de su capacidad para detectar y corregir errores básicos, Cursor puede tener dificultades cuando se enfrenta a problemas más complejos que requieren un entendimiento profundo del flujo lógico del programa o del contexto específico.

Otra ventaja significativa de Cursor es su capacidad para facilitar el aprendizaje. La herramienta actúa como un tutor, proporcionando explicaciones en tiempo real y sugiriendo mejoras que pueden acelerar la curva de aprendizaje, especialmente para aquellos que están comenzando en la programación o explorando nuevos lenguajes y frameworks. 

Figura 8: Chat viral enlace localhost

Sin embargo, esta facilidad de uso también conlleva el riesgo de que los usuarios, especialmente los novatos, se vuelvan excesivamente dependientes de la herramienta, lo que podría limitar su capacidad para desarrollar una comprensión profunda de los fundamentos de la programación. De hecho, se hizo viral este chat donde alguien le cuenta a su amigo que, usando Cursor, construyó algo en tiempo récord. Cuando el amigo le pide el link para probarla, le pasa un localhost.

Instalación y precios

Cursor se puede utilizar de manera gratuita, pero está muy limitado. Incluye 2000 auto-completados, y la posibilidad de hacer 50 solicitudes a LLMs premium como Claude 3.5 Sonnet o GPT-4o. Ya con el plan Pro de 20 USD mensuales tenemos autocompletados ilimitados, la posibilidad de hacer 500 solicitudes a estos LLMs premium con rapidez garantizada, e ilimitadas sin garantía de poder ser realizadas con prioridad. Por último, existe un plan Business de 40 USD al mes por usuario, más enfocado a equipos.

Figura 9: Tabla de precios y características incluidas

Conclusiones

El futuro de Cursor promete grandes avances en el desarrollo de software. Se espera la integración de modelos de lenguaje aún más avanzados, mejorando la capacidad de generación y asistencia de código. También se trabaja en optimizar la edición multi-archivo para proyectos complejos, asegurando cambios consistentes en todo el proyecto, y se priorizarán mejoras en seguridad, con un modo de "privacidad total" para proteger el código de posibles filtraciones.

Es normal el uso de GPT o Claude mientras programamos. De la manera en la que se ha ido haciendo es por ejemplo copiar la parte del código que quieres arreglar y llevarla a esta herramienta para que lo optimice, y copiar la respuesta de nuevo a nuestro editor de código. ¿Se optimizará aún más este proceso usando Cursor? Pruébalo con la versión gratuita para comprobar si te puedes adaptar bien a esta nueva forma de trabajar, descárgalo de la página oficial.

Saludos,  

Autor: Javier del Pino, Investigador de Inteligencia Artificial en Ideas Locas

Contactar con Javier del Pino Díaz en MyPublicInbox

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.

Figura 1: Codebreaker, TrojanPuzzle, Covert & Simple - Cómo envenenar LLMs para

inyectar Bugs & Backdoors en los programas que haces con los Copilots de Developers

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. 

Figura 2: Papers sobre el código inseguro que genera 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.

Figura 3: Código PHP con bug de SQL Injection generado por ChatGPT

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.

Figura 4: Do users write more insecure code with AI assistants?

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. 

CODEBREAKER: Envenenamiento de LLMs para generar código vulnerable

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 ).

Figura 5: Envenenamiento de Data Corpus con el método SIMPLE

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.

Figura 6: Método COVERT, con payload en comentarios

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. 

Figura 7: TrojanPuzzle: Covertly Poisoning Code-Suggestion Models

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.

Figura 8: Ejemplo de payload inyectado como TrojanPuzzle

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.

Figura 9: An LLM-Assisted Easy-to-Trigger Backdoor Attack

on Code Completion Models: Injecting Disguised Vulnerabilities

against Strong Detection

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.

Figura 10: Inyección de bugs saltando protecciones

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. 

Figura 11: ChatGPT encuentra el bug de Reentrancy Attack

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.

Figura 12: Algoritmo de Payload Transformation

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.

Figura 13: Payload Transformation con GPT-4

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í.

Figura 14: Resultados de Éxito de Smuggling con el Payload Transformation

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 

Figura 15: Resultados para pasar la detección

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.

Figura 16: Resultados en diferentes pruebas.

El resultado al final es que se consiguen, ratios grandes de inyecciones de bugs & backdoors, y que además, las generadas por CodeBreaker (CB) llegan todas a la sugerencia del developer, mientras que los que se introducen con SIMPLE, COVERT o TROJANPUZZLE ya son detectadas todas (y por eso pasan a -> 0). 

Las otras pruebas de la Figura 16, con las baterías de datos de entrada en forma de Texto, de Código Aleatorio, o con un Código Concreto como Objetivo, consiguen inyectar sugerencias  que no son detectadas tanto pasando entornos de auditoría de herramientas de StaticAnalysis (CB-SA), con verificación de GPT vía API (CB-GPT) o verificación vía web de ChatGPT (CB-ChatGPT) para que alerte de si hay o no vuelnerabilidad en esa línea. 

Conclusiones.

Al final, en Codebreaker en el Data Corpus con el que se entrena el modelo LLM para Code Completing ya va inyectado el código mutado, verificado contra los motores SA y GPT, además de ofuscado para asegurarse de este resultado que vemos en la Figura 16 siempre pasen todos. Pero... esto es un juego del gato y el ratón, y una actualización de los motores de Análisis Estático de Código detecten que su motor está lanzando código malicioso mañana.

Figura 17: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Esto implica a que los equipos de pentesting, va tener que tener que implementar pruebas de QA de Seguridad de los LLMs constantes para detectar cuándo un Copilot de Code Completing está escupiendo código inseguro por defecto o por envenenamiento, lo que abre una nueva línea de trabajo de Continuous Monitoring de LLMs para Copilots de Developers.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)