Arithmetic Blind SQL Injection (II de II)

***************************************************************************************************
- Arithmetic Blind SQL Injection (I de II)
- Arithmetic Blind SQL Injection (II de II)
***************************************************************************************************

3.- Solución 2: Desbordamiento de tipo de datos

Otra de las formas de construir una lógica binaria en este entorno es utilizar los errores de desbordamiento de tipo como inyección de cambio de comportamiento positivo. El objetivo es sumar un valor al parámetro que desborde el tipo de dato del parámetro si la condición es cierta, para ello, se pueden probar las inyecciones de cambio de comportamiento positivo simplemente sumando un valor que desborde el tipo de datos.

En este entorno

id=1-(99999999999999999*9999999999999999999)

desbordará el tipo de datos del parámetro id y se obtendrá un mensaje de error.


Imagen 7: El parámetro id desbordado genera un error
A partir de este entorno se podría construir toda la lógica y extraer la información de igual forma que con el ejemplo de la división por cero. Así, para obtener el valor ASCII de la primer letra del nombre del primer usuario en la tabla sysusers se puede construir una consulta como:

id=1-((contador/(select top 1 ASCII(substring(name,1,1)) from sysusers order by name asc))*(99999999999999999*9999999999999999999))

El valor de valor de “contador” irá creciendo desde 1 hasta que se iguale con el valor ASCII del valor que se está buscando. Mientras contador sea menor, la división generará un valor 0 que anulará las constantes que desbordan el tipo del parámetro vulnerable.

Como se puede apreciar, la constante que desborda el tipo de datos se ha puesto como una multiplicación de dos valores, pues si se hubiera puesto como un único valor dependiendo del motor de base de datos hubiera podido dar un error en tiempo de evaluación de la consulta y no en tiempo de ejecución como es el objetivo de esta prueba.


Imagen 8: El parámetro no es desbordado porque la división vale 0
Sin embargo, en el momento en que el valor de contador se iguala con el valor ASCII que se está buscando, se obtiene un mensaje de error que indica que la condición es cierta.


Imagen 9: El tipo de datos se desborda cuando la condición es cierta
Como se puede apreciar, el desbordamiento de tipos de datos es igual de válido para la explotación a ciegas en estos entornos. A partir de la determinación de este comportamiento es fácil construir la lógica booleana necesaria para automatizar la extracción de de datos y, como se puede ver, cumple perfectamente los requisitos sintácticos definidos en el apartado 1.

4.- Solución 3: Sumas y restas

Una tercera forma de explotar las vulnerabilidades de inyección de código SQL en funciones matemáticas consiste en utilizar la aplicación como si fuese una máquina de Turing. El objetivo es marcar la posición actual como el valor cierto. Después se suma el valor buscado al parámetro vulnerable y se resta el valor de un contador. La condición será cierta cuando se obtenga la notica original.

En este entorno se podría obtener, al igual que en los ejemplos anteriores, el valor de ASCII de la primera letra del primer usuario de la tabla sysusers con la siguiente inyección:

Id=1-(-(select top 1 ascii(substring(name,1,1)) from sysusers order by name asc))-contador

En este caso, mientras que contador no se iguale con el valor buscado se estarán pasando otros valores distintos al parámetro id e irán apareciendo distintos resultados.


Imagen 10: Resultados obtenido equivalente a id=2


Imagen 11: Respuesta original obtenida vía sumas y restas
Sólo cuando se iguale el valor de contador con el valor buscado se obtendrá la respuesta original. De esta sencilla forma será posible establecer respuestas distintas a condiciones ciertas y condiciones falsas para extraer toda la información de la base de datos.

5.- Conclusiones

Como se ha podido ver con estas técnicas, es posible, mediante operaciones matemáticas, extraer la información de una base de datos en un entorno vulnerable a Blind SQL Injection dentro de funciones matemáticas. No ha sido necesario utilizar los operadores lógicos AND u OR para construir la lógica booleana y de igual forma se puede extraer toda la información almacenada en la base de datos.

El estudio continuado de las técnicas de SQL Injection está demostrando que el nivel de riesgo de las mismas está en alza. Es por tanto priorizar los esfuerzos en la detección, mitigación y erradicación de este tipo de vulnerabilidades mediante técnicas de auditoría, filtrado y aplicación de metodologías de desarrollo intensivas en la seguridad del código generado.

***************************************************************************************************
- Arithmetic Blind SQL Injection (I de II)
- Arithmetic Blind SQL Injection (II de II)
***************************************************************************************************