Cómo convertirse en Tripulante Aéreo Autorizado con un SQL Injection Level 1 (y saltarse las colas de seguridad de los aeropuertos)

Las técnicas de SQL Injection fueron descubiertas en 1998. El 25 de Diciembre de 1998 el investigador rfp (rain.forest.puppy) publicaba el famoso ezine en el que hablaba de cómo se podía saltar la seguridad de una aplicación web que validaba usuarios contra una tabla en una base de datos usando consultas SQL con cadenas de texto concatenadas. Acababa de nacer el fallo de seguridad que más impacto ha tenido en la historia de la seguridad web desde que nació la Web.

Figura 1: Cómo convertirse en Tripulante Aéreo Autorizado con un

SQL Injection Level 1 (y saltarse las colas de seguridad de los aeropuertos)

Yo le dediqué años de estudio a las técnicas de SQL Injection, di muchas charlas, publiqué muchos artículos, fueron parte de mi trabajo de doctorado, y acabamos publicando un libro con todo esto que a día de hoy sigue siendo uno de los más vendidos, quizá porque sigue siendo fundamental para un pentester o un developer conocer estas técnicas y sus riesgos.

Figura 2: Libro Hacking de Aplicaciones Web "SQL Injection" 4ª Edición

de Enrique Rando, Chema Alonso y Pablo González en 0xWord

Hoy en día no es tan fácil encontrar estas vulnerabilidades como lo fue hasta el año 2010, donde saber SQL Injection era equivalente a tener siempre comodines en la manga. Aparecía en cualquier sitio. Un SQL Injection, un Blind SQL Injection, uno de errores ODBC, un Remote File Downloading, un Time-Based Blind SQL Injection, un Arithmetic Blind SQL Injection. 

Figura 3: NT Web Technology Vulnerabilitys de rfp

(en la Wayback Machine)

Recuerdo jugar con la web de mis admirados Fernando Alonso y Pedro de la Rosa que tenían unos bonitos SQL Injection en sus páginas web, pero podría enumeraros centenares de ellas que aún tengo en mi cabeza. Una de las veces, en el año 2009, fui invitado a ir a la Yahoo! Security Week a dar una charla de Web Security a los Paranoids de Yahoo! Allí Palako y yo hicimos Live-demos de SQL Injection hasta que recibimos un mensaje en papel que ponía: "Please, no more non-Yahoo! sites live demos". Era tan fácil, estaba por tantos sitios, que casi podías hacer lo que quisieras en cualquier página web del mundo. Si es que servía hasta para ligar.

Bypassing airport security via SQL injection 

Hoy en día, 26 años después, a mí me gusta aún, de vez en cuando, echar un ojo y buscar algún sitio que aún tenga estos bugs clásicos, para ver si siguen existiendo y para sentir que he rejuvenecido y he vuelto a tener 25 años y estoy haciendo un pentest a una web. Busco alguno, lo reporto, y luego publico un post de eso por aquí. Es mi pasión, qué os puedo decir que no sepáis ya.

Figura 4: La plataforma para autorizar KCM

Pero parece que no se han erradicado del todo, y dos investigadores, Ian Carroll y Sam Curry, han encontrado un SQL Injection de libro, Level 1, en la web que controla el sistema de autorización de los Known Crewmembers (KCM) o tripulantes conocidos de las compañías aéreas, que tienen cola de acceso priorizada en los aeropuertos americanos gestionados por la TSA (Transportation Security Administration).

Figura 5: Login con SQL Injection Level 1

El sistema de administración es un portal web de acceso púbico sin VPN, sin Passkeys, sin 2FA, sin control de mensajes de error, sin control de cuentas privilegiadas, sin WAF, y con un SQL Injection de libro que permitía poner un 'or '1'='1  y tener un bonito acceso al panel de administración para poder ver los nombres de usuario y las credenciales, en hash MD5, de todos los usuarios de los sistema, además de los datos de todos los tripulantes. Ahí, ¡a lo loco!

Figura 6: Administración de los KCM

Pero por supuesto, lo mejor es que te podías dar de alta como KCM dentro de la plataforma, y luego, siguiendo las reglas de los KCM acceder a esas colas en todos los aeropuertos americanos gestionados por la TSA.

Figura 7: Prueba de acceso de un nuevo KCM

¿Os acordáis de la famosa película de "Catch me if you can" de Leonardo di Caprio con la escena en la que accede a los aeropuertos vestido de piloto para ir de un lugar a otro? Pues con un SQL Injection de Level 1, hasta mediados de 2024 era así de sencillo. 

Figura 8: Reglas de acceso para los KCM

(lo de las azafatas de la película es opcional)

Hoy en día el bug ha sido corregido, que los investigadores han hecho Responsible Disclosure. Pero no me digáis que no es una historia que te hace caer una lagrimilla al ver ese SQL Injection.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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)  

Test de uso de GenAI para la detección de bugs de "Connection String Parameter Pollution" (CSPP) usando Ollama

En la primera parte de este artículo de ayer, titulado "Cómo utilizar GenAI para la detección de bugs en ficheros Web.config usando Ollama" explicaba cómo de bien detectaba el motor de GenAI basado en Ollama con diferentes LLMs los fallos de configuración de un fichero Web.config en aplicaciones ASP.NET , pero en la presentación del trabajo, me llevé deberes para casa, que os voy a contar ahora.

Figura 1: Test de uso de GenAI para la detección

Connection String Parameter Pollution usando Ollama

Y es que cuando terminé de exponer mi trabajo con lo visto hasta el momento, Chema Alonso comentó que le gustaría probar cómo se comportaría este sistema frente a los ataques a los parámetros de las cadenas de conexión a bases de datos.

Vulnerabilidades de Connection String Injection

Chema Alonso y José Palazón presentaron en DEF CON 18 este tipo de ataques, donde destacan los ataques de Connnection String Parameter Pollution (CSPP). Tienes un paper publicado sobre estos ataques en BlackHat y una serie de artículos sobre Connection String Attacks en este blog.


Figura 2: Connection String Attacks en DefCON18

Aunque hay varias formas en las que se puede explotar esta vulnerabilidad, nos centraremos en el escenario de delegación de la autenticación en el motor de BD.  Es decir, tenemos una aplicación que recoge las credenciales del usuario y la cadena de conexión a la BD se calcula dinámicamente con estas. 

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, 

Cada usuario puede tener o no permisos de conexión a la BD y permisos de lectura o no a ciertas tablas. En el siguiente código C# de una aplicación ASP.NET se puede ver la idea:

private void EnlazarGrid(string usuario, string contraseña)
{

string cadenaConexion = $"Server=UK5FCMI;Database=WebApp;User Id={usuario};Password={contraseña};"; 

using (SqlConnection con = new SqlConnection(cadenaConexion))

{

using (SqlCommand cmd = new SqlCommand("SELECT * FROM Products"))

{

using (SqlDataAdapter sda = new SqlDataAdapter())

{

cmd.Connection = con;

sda.SelectCommand = cmd;

using (DataTable dt = new DataTable())

{

sda.Fill(dt);

GridViewProductos.DataSource = dt;

GridViewProductos.DataBind();

}

}

}

}

}    

El método construye, mediante interpolación de cadenas, una cadena de conexión a una BD tipo SQL Server a partir de los parámetros de usuario y contraseña. Estos parámetros no se validan en ningún momento (ni en el llamador). Con esta cadena de conexión, se lanza una conexión contra la BD y se lee la información de la tabla Products (si el usuario de BD tiene permisos SELECT sobre dicha tabla) para mostrarla en la grid del formulario ASPX. Todos estos ataques se explican en mucho detalle en el libro "Hacking Web Technologies 2ª Edición" de 0xWord.

Figura 4: Libro de "Hacking Web Technologies Silver Edition"

donde Chema Alonso habla de los Connection String Attacks

Una forma de explotarlo sería, por ejemplo, introducir como contraseña la cadena ;Integrated Security=True;, con cualquier usuario. Si se permite la autenticación integrada en SQL Server y el usuario del pool de IIS con que se está ejecutando la aplicación tiene permisos de conexión y consulta a la BD de la aplicación, podemos conseguir acceder a información que no nos corresponde. 

Utilizando el mismo prompt que ya hemos diseñado, vamos a pedir al modelo de Llama 3.1 que evalúe la seguridad del código.

Figura 5: Análisis de vulnerabilidad de inyección en la cadena de conexión

El modelo detecta un problema en la cadena de conexión, identificando que los parámetros de usuario y contraseña, que provienen de los campos de un formulario, no se han validado ni comprobado. Detecta que esto puede presentar un problema de SQL Injection, sin embargo, la propuesta de solución NO es acertada. En la cadena de conexión, elimina los parámetros de usuario y contraseña:

string cadenaConexion = $"Server=UK5FCMI;Database=WebApp;";

using (SqlConnection con = new SqlConnection(cadenaConexion))

{

...

Y propone utilizar consultas parametrizadas, de la siguiente manera:

using (SqlCommand cmd = new SqlCommand("SELECT * FROM Products WHERE Usuario = @Usuario AND Contraseña = @Contraseña"))

{

cmd.Parameters.AddWithValue("@Usuario", usuario);

cmd.Parameters.AddWithValue("@Contraseña", contraseña);

...

} 

Pero esto NO funcionará. En primer lugar, no se podrá conectar a la BD sin un usuario y contraseña en la cadena de conexión. Y la consulta modificada de la tabla Products tampoco funcionará porque Usuario y Contraseña no son campos de dicha tabla.

Parece que el modelo está intentando encajar la solución de una SQL Injection clásica a este tipo de vulnerabilidad. Una solución podría ser utilizar la clase SqlConnectionStringBuilder, de la que Chema habla en la segunda parte de su serie en el blog.

Figura 6: Libro Hacking de Aplicaciones Web "SQL Injection" 4ª Edición

de Enrique Rando, Chema Alonso y Pablo González en 0xWord

Al ser Llama un modelo general, se probó también con un par de modelos especializados en código. Por ejemplo, el modelo Code Llama de Meta (basado en Llama 2), es un modelo especializado en código y está entrenado, entre otros, con lenguajes C#. El análisis de este modelo (en su versión 13B) del código anterior fue muy similar a Llama 3.1, proponiendo como solución la consulta parametrizada que incluye los parámetros de usuario y contraseña en la SELECT de productos.

Figura 7: Análisis de vulnerabilidad de Connection String Injection

 con Code Llama 13B

El modelo CodeGemma 7B también propuso el uso de consultas parametrizadas y además sacar la cadena de conexión a la sección ConnectionStrings del fichero Web.config. Esto tampoco soluciona la vulnerabilidad, aunque se saque la cadena a otro sitio.

Figura 8: Análisis de vulnerabilidad de Connection String Injection

con CodeGemma 7B

Es cierto que descubre que hay una inyección, pero no acierta con el tipo, y por lo tanto la solución no es correcta, lo que hace que para este caso, tenga una bonita alucinación. Así que queda tarea que hacer para conseguir que estas vulnerabilidades se puedan detectar y corregir correctamente.

Saludos,

Autor: Fernando Gutiérrez Calderón

Contactar con Fernando Guitérrez Calderón

Cómo buscar vulnerabilidades en SmartContracts, SQL Injection, XSS o bugs Python con ChatGPT

Hace poco os hablaba del estudio que arrojaba como resultados que los programadores que utilizan asistentes de código basados en inteligencia artificial son más propensos a generar código con fallos de seguridad, y además hemos visto que si pides que te hagan código sin pedirle que mire la seguridad tanto Copilot, como ChatGPT, como otros asistentes, pueden generar código "buggy". Hoy vamos a ver lo contrario, cómo pedirle que nos ayude a hacer seguro nuestro código.

Figura 1: Cómo buscar vulnerabilidades en SmartContracts,

SQL Injection, XSS o bugs Python con ChatGPT.

Imagen hecha con Dall-e 2 (A happy hacker in Picasso style)

Vamos a hacer cuatro ejemplos de corrección de su propio código, de búsqueda de vulnerabilidades, de revisión en profundidad de un código, y de generación de código seguro desde el principio. Vamos a ello.

Figura 2: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Ejemplo 1: Un SQL Injection en el código de ChatGPT

En el ejemplo primero, le pedía una función que accediera a una base de datos para comprobar si un usuario había introducido correctamente sus credenciales, y como veíamos, nos daba un código PHP con un SQL Injection de libro.

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

Sin embargo, si le pedimos a ChatGPT que corrija el fallo de SQL Injection, lo cierto es que lo corrige perfectamente. 

Figura 4: Le pedimos a ChatGPT que elimine el bug de SQL Injection y lo hace.

Y esto abre muchas posibilidades que podemos aprovechar para securizar nuestro código o para buscar vulnerabilidades en códigos que estemos auditando. Es decir, como una herramienta de análisis de código estático.

Ejemplo 2: Encontrar un bug de Reentrancy Attack en un SmartContract

Para ello, en este ejemplo le he pedido que me busque si este código del mundo Web3 (que es un SmartContract que tiene una vulnerabilidad de Reentrancy Attack) tiene algún fallo de seguridad, pero como veis en la conversación, no le digo si existe o si no existe, ni por supuesto qué tipo de bug puede tener. Y ChatGPT lo encuentra perfectamente.

Figura 5: ChatGPT encuentra el bug de Reentrancy Attack

Así que, ya que lo ha encontrado, vamos a suponer que es nuestro código, así que vamos a darle cariño y pedirle que lo corrija él solito y nos dé el código sin esta vulnerabilidad. 

Figura 6: ChatGPT corrige el bug de Reentrancy Attack

Y listo. En un santiamén tenemos el código correcto de este SmartContract.

Ejemplo 3: Evaluar la fortificación de un código en Pyhton conjuntamente

En la siguiente prueba le doy el código inseguro para generar un fichero temporal que devolvió en la prueba de códigos inseguros generados por CoPilot. Así que le doy el código y le pido que busque si tiene alguna vulnerabilidad esta sección de un programa en Python.

Figura 7: No ha encontrado el bug a la primera

Sorprendentemente me dice que no ve ninguna vulnerabilidad, pero como yo sí sé que hay un problema en el método utilizado para la creación del archivo temporal, le pregunto directamente si ese método no es inseguro.

Figura 8: Insistiendo a ChatGPT sobre el método que sé que es inseguro

Como podéis ver, me ha contestado que no, SI tomo las medidas de prevención adecuadas. Pero claro, como programador de una aplicación, no puedo garantizar la configuración de los permisos del sistema donde esté implantado, así que le pregunto directamente por ese punto tercero.

Figura 9: Ahora sí que ha visto el problema, y me da la solución correcta

Y en ese caso, sí, ve el problema de seguridad, y ya me recomienda utilizar una función segura para evitarlo. Un ejemplo claro que la Mayeuita de Sócrates funciona perfectamente con la Inteligenica Artificial de hoy en día. 

Ejemplo 4: Generar un código JavaScript sin XSS ni bugs de Client-Side Attacks

Como veis, se puede utilizar ChatGPT para encontrar bugs, para evaluar código, pero también se puede utilizar para pedirle que el código que te genere sea seguro. Basta con enfatizar "sin vulnerabilidades de seguridad" en la conversación para que se lo tome muy en serio. Aquí, un caso muy típico donde muchos desarrolladores se comen un Client-Side Attack en forma de XSS, de CSRF, etcétera.

Figura 10: Código de JavaScritp con su entrada escapada para evitar XSS

Y como le hemos pedido que lo haga de forma segura, pues ha hecho un código en el que no deja meter código que pueda ser inyectado, mientras que si no le pides que se preocupe de la seguridad, te puede dar un código bastante buggy.

Conclusiones de estas pruebas

Así que, como decía en el vídeo que hice para explicar esto, no se trata de no utilizar los asistentes de Inteligencia Artificial para hacer código, sino de saber sacarles partido.

@chema_alonso ¿Generan código inseguro los asistentes de inteligencia artificial? #ai #ia #bug #sqli #copilot #chatgpt #seguridad #aprendoentiktok #aprendocontiktok ♬ Terminator 2: Judgment Day Theme - Everrune

ChatGPT, Copilot y todos los que irán apareciendo, son una herramienta de gran utilidad para:

1. Descubrir vulnerabilidades: Lo que es bueno para los pentesters y auditores.
2. Securizar código existente y revisarlo en profundidad: Lo que es bueno para QA y DevOps.
3. Generar código de forma rápida y segura: Lo que es bueno para los desarrolladores.

En definitiva, más vale que vayas aceptando que tu trabajo en el futuro va a requerir de saber sacarle el máximo partido a la Inteligencia Artificial igual que en el pasado tuviste que aprender a sacarle partido a Internet.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

ChatGPT hace código con SQL Injection, CoPilot mete Security Bugs y los programadores que usan Asistentes AI hacen más "Buggy Code"

Eso es lo que dice el paper publicado el 16 de Diciembre por investigadores de la Universidad de Stanford donde han hecho un experimento muy interesante con programadores para saber si activarles asistentes de Inteligencia Artificial para ayudarles a hacer código - como el caso de Copilot o ChatGPT - y ver después si su código es más o menos inseguro, corrector o incompleto.

Figura 1: ChatGPT hace código con SQL Injection, CoPilot mete Security

Bugs y los programadores que usan Asistentes AI hacen más "buggy code".

El resultado que arroja el artículo académico, titulado "Do users write more insecure code with AI assistants?" es que, a día de hoy, el código es más inseguro cuando los programadores se confían en el asistente de AI y le dejan meter más código, lo que lleva a que haya más bugs. 

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

Probar esto es tan fácil como hacer una prueba con ChatGPT para ver si se come un SQL Injection de libro en 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

En el código no ha filtrado ninguno de los datos de entrada que va a introducir en la consulta un bug de SQL Injection, y ha hecho un programa que funciona, pero que no tienen ninguna medida de protección y seguridad del código para evitar SQL Injection. Eso es que no se ha leído aún nuestro libro.

Figura 4: Libro Hacking de Aplicaciones Web: SQL Injection
de Enrique Rando y Chema Alonso

Que Copilot mete bugs, ya lo sabíamos, como vimos en el artículo de nuestro compañero Fran Ramírez donde vimos tres ejemplos en Python de código inseguro, como por ejemplo código para crear un fichero temporal usando funciones inseguras, como en este ejemplo.

Figura 5: Ejemplo inseguro de Copilot para fichero temporal.

Lo que viene a demostrar este paper no es si los asistentes de AI generan "buggy code", que ya sabemos que sí, sino si el usarlos hace que los programadores incrementen el número de bugs, errores, códigos inseguros, etcétera que los programadores que no los usan. Y el resultado es que sí. Que para 5 experimentos, el código seguro generado por programadores que no usaban asistentes AI era del 79% mientras que el de los programadores con asistente AI era del 67%.

Figura 6: Con AI, código más inseguro que sin AI

Por supuesto, cada programador es único, y depende mucho de lo que haga la persona con su código, pero para 5 ejercicios de seguridad, que tienen que ver con cifrar datos, firmas digitalmente, hacer consultas SQL o meter un directorio en un sandbox, el resultado era el anterior. 

Figura 7: Resultado para los ejercicios. Azul con AI, Marrón sin AI

Por supuesto, estamos al inicio del uso de asistentes de AI para programar, pero esto en dos años estará más que evolucionado y llegará un momento donde, probablemente, se alcanzará la Paridad Humana en programar, y entonces ya no habrá vuelta atrás, y programar sin asistentes de AI será una temeridad, pero por ahora, estamos en una fase mucho más temprana, así que cuidado con tu código.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)