Inyección SQL Ciega

This is an Attack. To view all attacks, please see the Attack Category page.

Last revision (mm/dd/yy): 07/29/2015

Descripción

Ataque a ciegas por inyección SQL, en inglés, Blind SQL injection, es una técnica de ataque que utiliza la inyección SQL. Se evidencia cuando en una página web, por una falla de seguridad, no se muestran mensajes de error al no producirse resultados correctos ante una consulta a la base de datos, mostrándose siempre el mismo contenido (es decir, solo hay respuesta si el resultado es correcto).

Sentencias condicionales con el tipo “Or 1=1″ o “having 1=1″ ofrecen respuestas siempre correctas (true o verdadero) por lo cual suelen ser usadas por los programadores como formas de comprobación. El problema para la seguridad de la página radica en que esta técnica es utilizada en combinación con diccionarios o fuerza bruta para la búsqueda, carácter por carácter, de una contraseña, un nombre de usuario, un número de teléfono o cualquier otra información que albergue la base de datos atacada; para ello se utiliza código SQL específico que “va probando” cada carácter consiguiendo un resultado positivo acumulable cuando hay una coincidencia. De esta manera se puede saber, por ejemplo, que una contraseña comienza por “F…”, luego continúa con “.i…”, y luego “..r…”, etc (acumula Fir…), hasta dar con la palabra completa.

Existen programas que automatizan este proceso de “tanteos” letra por letra en el resultado de la consulta SQL, que un intruso podría enviar inyectado.

Modelando Amenazas

Igual que SQL Injection

Factores de Riesgo

Igual que SQL Injection

Ejemplos

Un atacante puede verificar si una solicitud enviada regresó verdadero o falso de varias formas:

Basado en el contenido

El uso de una simple página, que muestra un artículo con ID dado como parámetro, el atacante puede realizar un par de pruebas sencillas para determinar si la página es vulnerable a ataques de inyección SQL.

URL de ejemplo:

http://newspaper.com/items.php?id=2

envía la siguiente consulta a la base de datos

SELECT title, description, body FROM items WHERE ID = 2

el atacante puede entonces intentar que devuelva ‘falso’:

http://newspaper.com/items.php?id=2 and 1=2

ahora la consulta SQL quedaría tal que así:

SELECT title, description, body FROM items WHERE ID = 2 and 1=2

Si la aplicación web es vulnerable a SQL Injection, entonces es proble que no devuelva nada. Para asegurarse, el atacante injectará una consulta que devuelva ‘verdadero’:

http://newspaper.com/items.php?id=2 and 1=1

Si el contenido de la pagina que devuelve ‘verdadero’ difiere de la página que devolvió ‘falso’, entonces el atacante es capaz de distinguir cuando la consulta ejecutada es verdadera o falsa.

Una vez que esto ha sido verificado, la única limitación son los privilegios puesto por el administrador de la BBDD, diferente sintaxis sql y la imaginación del atacante.

Basada en tiempo

Este tipo de inyección SQL ciega se basa en pausar la BBDD por un tiempo especificado, para que posteriormente devuelva los resultados, indicando que la consulta triunfo Usando este metodo, un atacante enumera cada letra de la porción de datos que desea leer usando la siguiente lógica:

Si la primera letra del nombre de la primera BBDD es una “A”, esperar 10 segundos.

Si la primera letra del nombre de la primera BBDD es una “B”, esperar 10 segundos, etc…

Así con cada letra, si la respuesta tarda diez segundos es que es la letra por la que preguntamos si no es así continuamos con la siguiente.

EJEMPLOS

Microsoft SQL Server

http://www.site.com/vulnerable.php?id=1′ waitfor delay ’00:00:10′–

MySQL

SELECT IF(expression, true, false)

Usando alguna operación que tome un tiempo considerable en realizarse por ejemplo BENCHMARK(), esto causará un retardo en la respuesta si la consulta es “Verdadera”

BENCHMARK(5000000,ENCODE(‘MSG’,'by 5 seconds’))

- ejecutará la función ENCODE 5000000 veces.

Dependiendo de la carga y el rendimiento del servidor de base de datos, esto debería de tomar solo un momento para terminar. Lo importante es, desde el punto de vista del atacante, especificar un número de repeticiones lo suficientemente alto como para afectar al tiempo de respuesta de manera notable.

Ejemplo de la combinación de ambas consultas:

1 UNION SELECT IF(SUBSTRING(user_password,1,1) = CHAR(50),BENCHMARK(5000000,ENCODE(‘MSG’,'by 5 seconds’)),null) FROM users WHERE user_id = 1;

Si la base de datos toma un tiempo en responder, nosotors podemos deducir que el primer carácter del password del usuario con el “user_id=1″ sea “2″

(CHAR(50) == ’2′)

Usando este metodo para el resto de carácteres, es posible enumerar contraseñas enteras almacenadas en la BBDD. Este metodo traba incluso cuando el atacante inyecta consultas SQL y el contenido de la página vulnerable no cambia.

Obviamente, en este ejemplo, los nombres de las tablas y el número de columnas fue especificado. Sin embargo, es posible adivinarlos también o probar con un metodo de ensayo y error.

Las bases de datos distintaas de MySQL tambien tienen funciones basadas en tiempo que podrían ser usas para ataques basados en tiempo:

MS SQL ‘WAIT FOR DELAY ’0:0:10 PostgreSQL – pg_sleep()