Arithmetic Blind SQL Injection

Hace tiempo, en un test de intrusión no autorizado, que eufemismo más chulo para decir que estaba haciendo…otra cosa, me encontré con un problema que me costó resolver. El entorno era el siguiente:

- Una base de datos Access en la que no podía poner comentarios.
- Una consulta en la que el parámetro inyectable estaba dentro de una función matemática que exigía como dato de entrada un número.
- Se usaba ese parámetro en dos condiciones where con distintos grados de anidación de paréntesis.

Vamos, era algo como:

Select campos
From tablas
Where (abs(parámetro_inyectable)=número) and abs(parámetro inyectable)=numero

Encontrar una cadena de inyección que construyera una consulta SQL correcta saliéndose de los paréntesis era completamente imposible pues si inyectabas algo del tipo: 1) and 1=1 and (abs(1 se obtenía algo como: Where (abs(1) and 1=1 and (abs(1 )=número) and abs(1) and 1=1 and (abs(1 )=numero

Quedaba perfectamente construida la query en la primera condición, pero no en la segunda. Y si inyectaba otra cadena que hiciera correcta la segunda query en paréntesis, la primera quedaba mal construida.

Bien, parecía imposible salir de la función matemática en la que estaba enjaulado. Así que había que hacer una lógica sin salirse de allí. Probé el método descrito por Litchfield en alguno de sus docs de hacer una lógica basándose en la división por 0, es decir, forzar que si algo era cierto diera división por cero. Es decir, el parámetro inyectable tenía que ser un número, entonces hagamos que la inyección siempre devuelva un número… o un error matemático.

parámetro_inyectable =if ((select user) = 'sa' OR (select user) = 'dbo') select 1 else select 1/0

Bueno, en Access no hay if, así que así no valía, había que realizar operaciones matemáticas a manopla para generar la división. Sin embargo, el método de la división por cero está bien cuando hay un if de por medio y cuando además el error es visible, pero… ¿por qué generar un error si podemos jugar con las mátematicas?

ensemos en el típico sistema de noticias dónde tenemos algo como noticias.php?id=14567 dónde queremos sacar, por ejemplo, la password del administrador de una supuesta tabla users.

- Si ponemos noticias.php?id=14567 obtenemos la Noticia 1
- Si ponemos noticias.php?id=abs(14567) y obtenemos la Noticia 1 entonces el sistema es inyectable.
- Si ponemos noticias.php?id=14566 obtenemos otra noticia.
- Si ponemos noticias.php?id?14567+60-(select ascii(mid(password,1,1)) from users) obtendremos la Noticia 1 si el primer caracter de la password es el que tiene ASCII 60 si no obtendremos otra noticia.

Esta forma de hacer un ataque por Blind SQL Injection permite no preocuparse por las anidaciones de paréntesis, no generar un error de división por cero (que puede tirar la sesión de la aplicación o generar una alerta XXL en la base de datos y además… funciona para todas las inyecciones con valores numéricos… Sencillo ¿no?

Saludos Malignos!

PD: ¿No quieres jugar con el Reto VI?