Un "Hardening Tip" de BBDD - de mi Lost & Found - contra las "Heavy Queries Malignas"

Hace muchos años, cuando estaba trabajando en mi Ph.D en los Time-Based Blind SQL Injection using Heavy Queries, en uno de mis documentos de la universidad escribí sobre las técnicas de "hardening" para dificultar este tipo de ataques y lo tenía preparado en un post, pero lo fui dejando sin sacar, y un día me olvidé de publicarlo, hace unos quince años más o menos.

Figura 1: Un "Hardening Tip" de BBDD - de mi Lost & Found -

 contra las "Heavy Queries Malignas"

Sin embargo, hablando sobre las capacidades de usar ChatGPT, Claude o Gemini para investigar en ciberseguridad, y lo fácil que hubiera sido construir las diferentes Heavy Queries para explotar un bug de SQL Injection usando una técnica Time-Based, me he acordado con él, y se lo he preguntado directamente a Gemini.

Figura 2: Whitepaper de "Time-Based Blind SQL Injection using Heavy Queries"

Por supuesto, de las técnicas de Time-Based Blind SQL Injection using Heavy Queries, hablé en el libro de "Hacking de Aplicaciones Web: SQL Injection", mientras que de las técnicas de LDAP & Blind LDAP  Injection in Web Applications,  y Connection String Parameter Pollution hablé en el libro de "Hacking Web Technologies".

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

Pero hoy en día, encontrar estas técnicas es tan fácil cómo preguntarle a los modelos, que ellos ya se han aprendido todos los papers, por ti, así que, preguntándole por ayuda para localizar si me han hecho un ataque a un aplicación web con un Microsoft Access 2003, obtienes rápidamente la información de sobre este ataque con Heavy Queries.

Figura 4: La tabla del sistema a explotar en Access 2003

Como podéis, ver, rápidamente nos hace el análisis de la tabla del sistema a explotar, y nos dice que la forma de explotarlo es usando Join de ella misma ene veces, tal y como explicamos en el paper, para lograr un volumen de datos tan grande que generar un delay medible. 

Figura 5: El método para explotarlo

Y por último, nos da la inyección completa que se puede utilizar para hacer el Time-Based Blind SQL Injection Using Heavy Queries, lo que genera la explotación completa de la vulnerabilidad. 

Figura 6: Inyección completa tipo Time-Based Blind SQL Injection using Heavy Queries

El resultado es que en un segundo puedes encontrar cómo hacerlo, y no ha habido que hacer ningún Jailbreak ni nada por el estilo, así que vamos a ver ahora la parte de fortificación de la que os he estado hablando.

Figura 7:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez,  Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Si vamos ahora a las protecciones, primero hay que entender por qué sigue siendo importante tener protecciones contra esta forma de explotar la base de datos, generando una Heavy Query. Estas técnicas se pueden usar para hacer un DoS o para extraer información de la BD, especialmente en motores que no tienen funciones de tiempo, o en entornos bajo WAF que están filtrando las queries.

Figura 8: Por qué sigue siendo importante esto

Y aquí viene el Hardening "Tip" del pasado, que no saqué en ninguno de los blog posts que escribí sobre ello, que consiste en que una vez construida la consulta, se pueda comprobar que la consulta tiene un Time-Out acorde con el tipo de Query que se está lanzando.

Figura 9: Poner un límite de tiempo a las consultas SQL

Por supuesto, usar consultas parametrizadas, detectar el tipo de los datos que se inyectan en los parámetros y no construir consultas concatenando strings es la clave, pero que una aplicación pueda vulnerar el rendimiento de la aplicación y de la propia base de datos por no controlar los límites de consumo de recursos de una consulta SQL es fundamental.

Figura 10: Límite temporal a nivel de TRANSACCIÓN en PostgreSQL

Para ello, en los diferentes motores de Bases de Datos existen formas de controlar el máximo tiempo que se va a permitir en ejecución una consulta, que es de lo que estuve escribiendo hace quince años, pero aquí tenéis, preguntándole a Gemini, la fácil que es limitar estos tiempos.

Figura 11: Límites en MySQL versiones 5.7.8+

Por supuesto, si no hay SQL Injection, no hay necesidad de tener esto, pero lo cierto es que esta protección se puede añadir no sólo a nivel de aplicación, sino también a nivel de DBFirewall, a nivel de Driver de conexión, o incluso como hacíamos con los ataques a nivel de red haciendo un Network Packet Manipulation con un Man-in-the-middle.

Figura 12: En Transat-SQL a nivel de Server,

a nivel de Conexión y a nivel de Query

Hay que tener en cuenta que en una arquitectura de Zero-Trust, la base de datos no debe fiarse nunca de las aplicaciones, así que, al igual que hacíamos con el Paranoid Mode para evitar las manipulaciones en bases de datos por parte de ataques de SQL Injection, controlar el consumo descontrolado de recursos es fundamental.

Figura 13: Controles en Oracle a nivel de SESSION y con Perfiles

Al final, si eres responsable de una base de datos de alto rendimiento, con muchas aplicaciones colgando de ellas, limitar el consumo de recursos lo puedes hacer preventivamente - evitándolo con límites - o reactivo, viendo qué está comiéndose la memoria y la CPU de la base de datos.

Figura 14: Límites en Access 2003 y SQLite

Ya os conté muchas veces que en la universidad yo me especialicé en Bases de Datos, que me encantaban, y que mis primeros trabajos tuvieron que ver con Tuning de bases de datos Oracle y de aplicaciones que corrían sobre ellas, así que estas cosas las tenía muy presentes cuando comencé con el trabajo de Time-Based Blind SQL Injection Attacks using Heavy Queries.

Figura 15: Resumen de posibilidades

Esta es una buena práctica de seguridad, sobre todo si eres de los que gusta tener los entornos Hardened in Paranoid Mode, así que si no la conocías o no lo estás aplicando, a lo mejor encuentras un punto donde tener estos controles y evitas estos ataques.

Figura 16: Por qué es útil esto

Lo cierto, que es a lo que iba la conversación inicial, es que esto que dejé a medio escribir hace quince años como un post, tenía que actualizarlo para ver cómo se establecen los límites temporales en todas las bases de datos, y en todos los puntos posibles, pero gracias a la existencia de los LLMs hoy en día, ha sido tan fácil como pedirle a Gemini que me lo dé, por eso os lo he compartido hoy y he borrado una tarea del pasado que tenía en mi To-Do.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo construir un Doom-Like usando sólo Lenguaje SQL (o en Excel)

El juego de DOOM es un clásico entre los clásicos en el mundo del PC. Y es una referencia para muchos de nosotros cada vez que queremos probar algo con la tecnología de aquella época, especialmente porque John Carmack innovó y de qué manera en sus juegos, creando una nueva generación de juegos. Y hoy os quería hablar de otro vuelto de tuerca jugando a ser el máster en Lenguaje SQL creando un juego tipo DOOM.

Figura 1: Cómo construir un Doom-Like usando sólo Lenguaje SQL (o en Excel)

El juego DOOM es el primero que me vino a la mente a mí cuando quería probar a ejecutar programas MS-DOS en iPhone, y fue con el que hice la prueba del emulador, como recordaréis, que os publiqué hace un año en el artículo: "Cómo jugar al DOOM de MS/DOS en iPhone & iPad (o cualquier otro DOS Game) con iDOS" 

Figura 2: Jugando al Doom con GamePad o teclas

El DOOM también es el juego que utilizaron los investigadores de Google para demostrar cómo la IA podría crear Mundos Virtuales en tiempo real con GenAI, que luego usaron para lanzar Genie 3.0 y dejar impresionado al mundo, en el artículo:"Diffusion Models Are Real-Time Game Engines".

Figura 3: Diffusion Models Are Real-Time Game Engines

No es casualidad esto. Al final DOOM es un ejemplo de calidad de código, de innovación, de jugabilidad, de optimización de los algoritmos, y un montón más de excelencias, que usarlo como referencia es siempre muy atractivo.

DuckDB DOOM on the browser

En este caso, PatrickTrainer ha creado un juego tipo DOOM construido para jugar en el navegador, pero construido enteramente en Lenguaje SQL, y eso mola todo. Lo que ha hecho ha sido construir un mundo basado en caracteres ASCII almacenados con tablas SQL sobre la base de datos DuckDB que corre en el navegador usando las librerías WASM, para describir el mapa de un juego tipo DOOM, meter enemigos, marcados con la letra E y tener a un jugador moviéndose por el mundo, marcado con el carácter @.

Figura 4: DuckDB Doom

Y por debajo, toda la representación en pantalla son ejecución de comandos del Lenguaje SQL que le permiten, utilizando Vistas, implementar el algoritmo Z-Buffer para poder tener la perspectiva del mapa desde el punto de vista del jugador, localizar a los enemigos, y disparar su proyectil (*). 

Figura 5: GitHub de DuckDB DOOM

Con que te bajes un el fichero Index.html y Demo.html podrás correr en cualquier sitio este juego, que como ejercicio de programación es maravilloso.

DOOMQL: Multiplayer

Y como suele suceder, una idea inspira otras ideas. En este caso Lukas Vogel ha publicado la semana pasada DOOMQL, un juego tipo DOOM, multiplayer, construido íntegramente con Lenguaje SQL en la base de datos CedarDB. Repito: multiplayer. Pero también a 30 Frames per Second y con menos de 200 líneas de código.

Figura 6: DoomQL

Tienes un artículo titulado: "DOOMQL: A DOOM-like multiplayer shooter in pure SQL" en el que explica en detalle todo el proceso, incluyendo el algoritmo de pintar el "3D", o el Raycasting para disparar los proyectiles. Mola todo, que además ha dejado publicados los cheat codes. 

Figura 7: DoomQL en GitHub

Como en el caso anterior, tienes todo el código disponible y documentado en el GitHub de este proyecto: DoomQL en GitHub. Todo son Tablas, Vistas y consultas en Lenguaje SQL. Te va a sorprender la simplicidad y elegancia del código final logrado por el programador.

Lenguaje SQL

Me han hecho especial cariño estos dos proyectos, porque como cuento siempre, yo entré en el mundo del hacking y la ciberseguridad casi de casualidad. Lo que yo sabía era programar, y especialmente mucho de bases de datos, que es en todo lo que me centré en mi vida. Os conté esa historia en el artículo de "El amo de lo datos". 

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

Saber mucho de Lenguaje SQL hizo que cuado aparecieron las técnicas de SQL Injection yo pudiera jugar mucho con ellas. Time-Based Blind SQL Injection using Heavy Queries, Arithmetic Blind SQL Injection, Remote File Downloading using SQL Injection, Connection String Parameter Pollution, (Blind) LDAP Injection in Web Applications, WordPress in Paranoid Mode, WhatsApp Anti-Delete Protection Tool. Todo fue jugar con lo que había aprendido de bases de datos.  Y de todo ello está escrito el libro de Hacking de Aplicaciones Web: SQL Injection (3ª Edición)

Bonus Track: Doom en EXCEL

No puedo escribir un artículo sobre como ser el máster de algo para hacer un proyecto como un juego de DOOM, sin hablar el trabajo que hizo c Bell hace ya muchos años para hacer un DOOM-Like en Excel sin utilizar VBA, que es una pasada.

Figura 9: Doom-Like en Excel

Y es que, si con Lenguaje SQL Se pueden hacer "locuras" con un EXCEL en las manos la cosa puede desmadrarse. De hecho, hay un MS Excel World Championship que se celebra en Las Vegas donde los expertos de Excel deben resolver problemas híper-complejos.

Figura 10: MS Excel World Championship

Este año debían resolver retos como este "Temple of the Golden Idol", para conseguir, sólo utilizando fórmulas de EXCEL que los animales resolvieran los laberintos.

Figura 11: Temple of the Goldem Idol

Figura 12: Temple of the Goldem Idol (2)

Me encantan estas cosas. Son el tipo de PoCs & Hacks Just for Fun que tanto nos gusta, como cuando quisimos hacer el Copilot para AMSTRAD CPC 6128 con el objetivo de poder desarrollar programas den BASIC usando GenAI, o cuando conectamos el Apple Macintosh a la nube.. Simplemente por que mola todo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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)