Este documento describe cómo explotar una vulnerabilidad de inyección SQL en un sitio web que usa el método POST. Explica que se puede probar datos falsos como ' or '1'='1 para verificar si hay errores que indiquen una vulnerabilidad. Si hay una vulnerabilidad, se puede usar SQLMap automáticamente para auditar el sitio y obtener la base de datos completa.
2. SQL Injection utilizando método POST
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.
3. SQL Injection utilizando método POST
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".
4. SQL Injection utilizando método POST
Si no me explique bien,
pues al buen entendedor
pocas palabras!!! entonces
sin mas rodeos, vamos a la
acción!
5. SQL Injection utilizando método POST
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
famoso ' or '1'='1 como se muestra en la imagen siguiente:
13. SQL Injection utilizando método POST
Nota. Ahora la pagina se ve así cuando se hizo la auditoria de seguridad, después solo
quitaron la entrada UAP. Administrativo posiblemente trataron de corregirla después de las
vulnerabilidades mostradas.
15. SQL Injection utilizando método POST
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:
17. SQL Injection utilizando método POST
Aun así como se menciono anteriormente trataron de corregir el error pero sigue
apareciendo el mismo error como se muestra a continuación
19. SQL Injection utilizando método POST
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 damos clic en
Conectar, la cual el servidor nos muestra lo siguiente:
21. SQL Injection utilizando método POST
Ahora, para seguir probando si el LOGIN tiene algún otro tipo de vulnerabilidad,
regresamos al form y ahora tecleamos USER en el usuario y en la clave lo mismo
USER y le damos clic en Conectar, la cual el servidor nos muestra lo siguiente:
24. SQL Injection utilizando método POST
¿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.
25.
26. SQL Injection utilizando método POST
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.
27. SQL Injection utilizando método POST
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
28. SQL Injection utilizando método POST
Recordemos que el sqlmap se encuentra el la suite del backtraq como se
muestra a continuación
32. SQL Injection utilizando método POST
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:
34. SQL Injection utilizando método POST
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.
38. SQL Injection utilizando método POST
Ahora si, con este análisis en la BD obtendremos los respectivos datos
reales para poder logearnos satisfactoriamente en el LOGIN que tanto
deseamos y hacer nuestra fechoría.