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.
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.
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.
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.
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
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)
No hay comentarios:
Publicar un comentario