En esta entrada breve y simple, se detallaran los pasos que realizaremos
cuando necesitemos explotar una vulnerabilidad de Sql Injection, que
mayormente se encuentran en algunos servidores basados en SQL Server y
Oracle. Estas vulnerabilidades son típicas en los LOGIN'S
Administrativos, ya que como debemos de saber, que cuando ingresamos el
usuario y password estos datos se envían a través del método POST, por
lo tanto puede existir la posibilidad de que al ingresar datos falsos o
algunos bypasses, esta nos pueda mostrar algún error que nos permita
identificar la vulnerabilidad, por tanto se puede explotar
automatizadamente utilizando SQLMAP ejecutando comandos para enviar
la petición en POST y no en GET como se "acostumbra".
Si no me explique bien, pues al buen entendedor pocas palabras!!! entonces sin mas rodeos, vamos a la acción!
Tenemos un LOGIN en ASP, en la cual no tenemos los datos correctos ni
nada por el estilo, ya que no hemos encontrado ningún tipo de
vulnerabilidad en el servidor que nos brinde estos datos, por tanto como
somos curiosos e inteligentes empezamos a probar datos falsos y algunos
bypasses como el famosillo ' or '1'='1 como se muestra en la imagen siguiente:
Después de haber colocado este bypass, tenemos la posibilidad de que el
servidor nos muestre algún tipo de vulnerabilidad o el error que nos
permita identificar si es vulnerable a SQL Injection, tanto así que si
el servidor se encuentra bajo ASP esta nos puede mostrar el error "Microsoft OLE DB Provider for ODBC Drivers error '80040e14'",
si esto llega a suceder, corremos la suerte de poder explotar esta
vulnerabilidad. En este caso después de haber colocado dicho bypass, el
servidor nos devuelve el siguiente error:
Al visualizar esta vulnerabilidad, somos consciente que se puede
explotar manualmente o automatizadamente, para así obtener los datos que
nos permita logearnos de una manera correcta al servidor.
Ahora, para seguir probando si el LOGIN tiene algún otro tipo de
vulnerabilidad, regresamos al form y dejamos en blanco el usuario y
clave y le cliqueamos en Conectar, la cual el servidor nos muestra lo
siguiente:
¿Algo raro cierto? ¿Por que? ... Este LOGIN nos demuestra que las
peticiones no están validadas, quiere decir que si
colocamos algún bypass, esta nos muestra una vulnerabilidad,
como también si dejamos los form en blanco y cliqueamos en conectar,
esta nos permite saltarnos del login.
Bien, después de haber llegado a unas pequeñas conclusiones sobre que el
servidor tiene una vulnerabilidad en el login y que las peticiones
no están validadas, procederemos a utilizar el Live HTTP Headers para así ver las cabeceras del login al momento que cliqueemos en Conectar.
En este caso después de haber colocado el Live HTTP Headers a
la escucha de lo que pasa por el servidor mientras cliqueamos en
Conectar dejando todo el blanco, esta nos devuelve lo siguiente:
Hemos obtenido 3 datos muy importantes! las cuales son:
- http://www.uap.edu.pe/intranet/logon2.asp
- POST /intranet/logon2.asp HTTP/1.1
- usuario=&pw=&user=07&B7=++Conectar++
La primera es posiblemente la URL Vulnerable, la segunda nos indica que
la variable es POST y el ultimo, los parámetros que posiblemente son
vulnerables.
Entonces procederemos a explotar la vulnerabilidad automatizadamente que
se encuentra en el LOGIN, utilizando SQLMAP y ejecutando el siguiente
comando basándonos en los datos obtenidos por el Live HTTP Headers.
- ./sqlmap.py -u "http://www.uap.edu.pe/intranet/logon2.asp" --data="usuario=&pw=&user=07&B7=++Conectar++" -p "usuario" --level=5 --risk=5 --dbs
Después de que la herramienta termine de auditar el servidor, esta
detectara que el parámetro POST "usuario" es vulnerable, tal cual se
muestra en la siguiente imagen:
A partir de allí, ya sabemos que dicho LOGIN es realmente vulnerable y
lo hemos explotado con total satisfacción obteniendo así toda la base de
datos del servidor.
Ahora si! con esta DB obtendremos los respectivos datos reales para
poder logearnos satisfactoriamente en el LOGIN que tanto deseamos ;)
Espero les sirva.