Prompt Injection Protections: Jatmo, StruQ, SecAlign & Instructional Segment Embedding

Las técnicas de Prompt Injection se ha convertido en OWASP Top Ten for LLM Apps & Services en el equivalente al SQL Injection fue en el mundo de las técnicas de Hacking Web Technologies. Es por eso que las propuestas para proteger el nuevo mundo de servicios digitales soportados por modelos de IA necesitan desarrollar nuevas formas de protegerse contra estos ataques, y los investigadores están haciendo muchas propuestas de valor al respecto.

Figura 1: Prompt Injection Protections: Jatmo, StruQ,

SecAlign & Instructional Segment Embedding

Hoy os quiero hablar de algunas de estas técnicas, para que entendáis la propuestas, porque los papers son más que interesantes para su lectura, y te van a ayudar a proteger tus servicios cuando hagas uso de las capacidades que nos ofrecen los MM-LLMs hoy en día, que son maravillosas, pero hay que usarlos de forma securizada.

Jatmo: Prompt Injection Defense by Task-Specific Finetuning

La primera de las que os voy a hablar es la propuesta Jatmo, que busca diferenciar entre el Prompt en el modelo y los datos de Contexto que pueden llegar a desde un punto externo al modelo, como una base de datos en una arquitectura RAG (Retrieval Augented Generation), documentos en un repositorio de mensajes, o de simplemente páginas webs en Internet. En este caso, el atacante introduce el Prompt Injection en un dato que va a ser cargado cuando se alimente el contexto al Prompt del developer desde una fuente externa no confiable.

Figura 2: Prompt Injection desde una Web externa con datos consultada

Para evitar esto, hay que dejar muy claro cuáles son los datos confiables, que en nuestro caso serían los que introduce el desarrollador, y los que vienen y no son confiables por proceder  de fuentes externas no verificadas. Y en esto consiste la propuesta de Jatmo que puedes leer en su paper.

Figura 3: Jatmo -Prompt Injection Defense by Task-Specific Finetuning

En el ejemplo presentado antes, el atacante aprovechar que el servicio que va a usar LLM usa una arquitectura donde consulta y carga datos externos para generar un contexto al modelo antes de que éste dé la respuesta. Y en esos datos introduce el Prompt Injection, como en este ejemplo.

Figura 4: Prompt Injection en datos externos

Para resolver esto hay que entender que, al igual que en las técnicas de SQL Injection, se está componiendo un Prompt de entrada al modelo LLM basado en datos del desarrollador y datos del atacante, así que habría que diferenciarlos bien.

Figura 5: Estructura de la consulta vulnerable y cómo el atacante lo explota

Y la propuesta de Jatmo es tan sencilla como cargar el modelo y los datos por separado. Es decir, mientras en la forma natural se hace una concatenación del Prompt con los datos del contexto, en la propuesta de Jatmo el desarrollador genera una tarea para cada Prompt y los datos para esa tarea se cargan con modelo cargado e instruido para tomar el resto de los datos como datos.

Figura 6: Propuesta de crear procedimientos con modelos

configurados por tareas a realizar en el servicio

Esto reduce la superficie de exposición al limitar las acciones que va a realizar el modelo que se está utilizando a un conjunto de ellas predefinidas y todo lo demás lo debe tomar como datos, lo que hace más complejo que un LLM reciba peticiones de comandos que no estén definidas por el desarrollador del servicio.

StruQ: Defending Against Prompt Injection with Structured Queries

El segundo de los papers del que os quiero hablar es de Septiembre del año pasado, y habla de generar Prompt Etiquetados como Structured Queries. Es decir, detectar, marcar y etiquetar de una determinada manera los datos de un Prompt para que el modelo LLM no sufra ataques de Prompt Injection.

Figura 7: StruQ - Defending Against Prompt Injection with Structured Queries

El proceso propuesto es como el que podéis ver en la imagen anterior. De nuevo, se trata de diferenciar entre el Prompt introducido por el desarrollador, y los datos procedentes de una fuente externa no confiable, donde puede venir el Prompt Injection. En este caso, además de utilizar todas las técnicas de análisis de la seguridad del Prompt de entrada - además de analizar los resultados de salida después -, el objetivo es etiquetar los datos.

Figura 8: Pipeline del procesado de StruQ para evitar Prompt Injection

En el gráfico anterior se ve cómo se quitan todas las etiquetas que pudiera haber introducido el atacante, para luego etiquetar el Prompt, los datos y la repuesta con un [MARK][INST][COLN] para las instrucciones, y [MARK][INPT][COLN] para los datos de entrada, y [MARK][RESP][COLN] para que el programador recoja la respuesta, tal y como tenéis en el ejemplo siguiente, que son datos de entrenamiento para detectar las etiquetas.

Figura 9: Entrenado del análisis del modelo etiquetado con StruQ

para procesar después en el LLM

El resultado es que, las técnicas de Prompt Injection o Jailbreak de las que he hablado tanto por aquí, como la de Tree-of-Attacks with Pruning, por ejemplo, se verían "parametrizadas" y serían fácilmente bloqueables con una arquitectura tipo Jatmo vista anteriormente.

Figura 10: Etiquetado StruQ de un Prompt Injection

de Tree-of-Attacks with Pruning

El resultado ayuda a mejorar la seguridad de los Prompts que se van a realizar, pero aún se pueden mejorar las protecciones contra estos ataques de Prompt Injection, y lo vemos en los siguientes papers.

SecAlign: Defending Against Prompt Injection with Preference Optimization

El objetivo de este paper es hacer más robusto el análisis del Prompt de entrada ya marcado, haciendo un alineamiento de seguridad en su análisis. Es decir, se trata de entrenar el modelo de análisis de datos para detectar los ataques dentro de las etiquetas, con datos reales y sintéticos que puedan ayudar al modelo a procesar correctamente el Prompt y detectar intentos de ataques

Figura 11: Optimización de SecAlign con DPO

En este caso, como podéis ver, el modelo es entrenado con datos en los que se le dice cuál es la respuesta deseable y cuál la no deseable, para que él pueda saber si lo ha hecho bien o no. Estas técnicas de DPO "Direct Preference Optimization" ayudan a entrenar el modelo para que aprenda las estructuras de los ataques de Prompt Injection.

Figura 12: SecAlign: Defending Against Prompt Injection

with Preference Optimization

Todo el trabajo de SecAlign con los diferentes tipos de técnicas de Prompt Injection y Jailbreak, los tienes explicados en el paper, además del resultado de detección de los mismos sin protección, con las técnicas SOTA (State-Of-The-Art) en Prompting-Base Defense y en Fine-Tunning Defense y por último con SecAlign Fine Optimization.

Figura 13: Comparación de resultados

En la izquierda tenéis el bechmark de ApacaEval2 y en la segunda por los valores de Max ASR (Attack Success Rate) de las baterías de pruebas. 

Figura 14: AlpacaEval 2.0 Leader Board

Instructional Segment Embedding: Improving LLM Safety with Instruction Hierarchy

El último de los papers de los que os voy a hablar hoy - que ya ha quedado muy largo el post de hoy, tiene que ver con los ISE "Instructional Segment Embeddings", donde se ataca la falta de herencia a la hora de clasificar cuáles son los Prompts del Sistema, cuáles los Prompts del Desarrollador y cuáles los Prompts en Datos externos no confiables, lo que hace que se puedan atacar los servicios basados en LLMs.

Figura 15: Diferentes tipos de Prompts de entrada y Output

No tener claro la jerarquía de herencia entre unos y otros hace que los que vienen por Data pueden llegar a contradecir lo que ha venido desde el System,  o el Developer (USER en el ejemplo anterior), y esto lleva a que se puedan hacer ataques de Prompt Injection, Prompt Extraction o Harmful Requests.

Figura 16: Diferentes tipos de Prompts Attacks

Para corregir esta debilidad en el modelo, lo que propone el trabajo de Instructional Segment Embedding: Improving LLM Safety with Instruction Hierarchy es no tener los mismos tipos de tokens para construir los Prompts, sino que se puedan diferenciar con una jerarquía los diferentes tokens con los que va a trabajar el LLM.

Figura 17: Instructional Segment Embedding

Improving LLM Safety with Instruction Hierarchy

Como se puede ver en la imagen, se crean diferentes tipos de embeddings para los diferentes tipos de niveles de datos de entrada que tiene que procesar el modelo LLM, ayudando a que se puedan procesar con diferentes niveles de prioridad.

Figura 18: Instructional Segment Embeddings

Con esta etiquetado, el paper presenta resultados experimentales que en los benchmarks de Alpaca los resultados son muy positivos. 

Final Thought

Al final, todos estos papers llevan a una conclusión de la que he hablado muchas veces en mis charlas, que no es más que el modelo de Seguridad por Diseño en los LLMs hace falta, y por eso estamos viendo tantos trabajos en ese área y, como veremos en un post posterior, ya tenemos propuestas en esa línea. Os contaré más.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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