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 -
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
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.
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!
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
