Descripción
This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs a SQL query containing the value of the submitted cookie.
The results of the SQL query are not returned, and the application does not respond any differently based on whether the query returns any rows. If the SQL query causes an error, then the application returns a custom error message.
The database contains a different table called users, with columns called username and password. You need to exploit the blind SQL injection vulnerability to find out the password of the administrator user.
To solve the lab, log in as the administrator user.
Blind SQL injection with conditional errors writeup
El laboratorio actual se basa en el anterior (sobre todo la última parte) Blind SQL injection with conditional responses. Esta vez la vulnerabilidad estará en toda la página web, pero la inyección SQL se tiene que hacer en la cookie. De nuevo dividiremos el laboratorio en varios pasos.
Localizar dónde hacer la inyección SQL
Primero, con el ‘Logger’ activado, recargaremos la página principal del laboratorio. Enviaremos esta petición al ‘Repeater’ con Ctrl + R o click derecho -> Send to Repeater.
Esta vez, modificar la cookie ‘TrackingId’ no creará ningún cambio en la interfaz de la página web, por lo que, para poder resolver el laboratorio, tendremos que crear nosotros una condición en la cookie que, al ser interpretada por SQL, lance un error en la aplicación o no. Esto lo haremos con el siguiente código:
qG0VAEQw4ua81gdC' and (select case when (1=2) then to_char(1/0) else 'a' end from dual) = 'a'--En este caso, lo que estamos haciendo es lo siguiente:
- ‘: Cierra la consulta original del desarrollador.
- and: Añade otra consulta.
- select case: Es el equivalente a un ‘if’ en SQL.
- When (1=2): Es la condición.
- then to_char(1/0): Si la condición es cierta, se intenta convertir a un carácter 1/0, lo cual lanza un error.
- else ‘a’ end: Si la condición es falsa, devuelve ‘a’.
- from dual: Es necesario en las bases de datos de Oracle indicar una tabla en las peticiones, si no siempre dará error.
- =’a’–: Hace que si la consulta anterior devuelve ‘a’ no de error y elimina el resto de la consulta implementada por el desarrollador con los ‘–‘.
Entonces, usaremos la condición ‘1=2’ para forzar o no errores en el lado del servidor y ver si nuestras consultas son ciertas.
Obtener la longitud de la contraseña
Enviaremos esta petición al ‘Intruder’ con Ctrl + I o Click derecho -> Send to Intruder. Allí modificamos la condición para que sea la longitud de la contraseña. También indicamos que la tabla ahora será ‘users’ y que el nombre de usuario debe ser ‘administrator’ (tal y como dice la descripción).
' and (select case when (length(password)=§§) then to_char(1/0) else 'a' end from users where username = 'administrator') = 'a'--El payload será tal que así:
En este caso, ordenaremos por el código HTTP de la respuesta, encontrando que la longitud de la contraseña es 20 caracteres:
Nota: La primera petición no es un payload vacío, que es usado por Burp Suite por defecto.
Nota 2:El error 500 se devuelve gracias a que estamos intentando hacer que SQL transforme a carácter 1/0.
Ataque de fuerza bruta a la contraseña
Cambiaremos la cookie de la siguiente forma:
' and (select case when (substr(password, §1§, 1)= '§2§') then to_char(1/0) else 'a' end from users where username = 'administrator') = 'a'--Y seleccionaremos de ‘Attack type’ ‘Cluster bomb’ para tener más control sobre los dos payloads.
- Payload 1: Será los números de 1 al 20.
- Payload 2. Será una lista simplede números (0-9) y letras minúsculas (a-z).
Una vez finalice el ataque, filtraremos por el código 500 y ordenaremos por el Payload 1 de manera ascendente, obteniendo el siguiente resultado:
La contraseña para el usuario ‘administrator’ es ‘kdqw97rsk4ejivpwv78m’. Al iniciar sesión en el navegador con ella completaremos el laboratorio:
