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.

1. SQL Injection utilizando
método POST
Herramienta sql
Sesión 3

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:

6. SQL Injection utilizando método POST

7. SQL Injection utilizando método POST
 Antes de eso recordemos que mantra esta integrado en la suite de
backtrack como se muestra a continuación

8. SQL Injection utilizando método POST

9. SQL Injection utilizando método POST
 Después de darle clic nos aparecerá las siguiente secuencia de ventanas

10. SQL Injection utilizando método POST

11. SQL Injection utilizando método POST

12. SQL Injection utilizando método POST

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.

14. SQL Injection utilizando método POST
Actualidad

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:

16. SQL Injection utilizando método POST

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

18. SQL Injection utilizando método POST

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:

20. SQL Injection utilizando método POST

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:

22. SQL Injection utilizando método POST

23. SQL Injection utilizando método POST

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.

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

29. SQL Injection utilizando método POST

30. SQL Injection utilizando método POST
 Introducimos la sentencia en sqlmap que se menciono anteriormente y
procedemos el analisis

31. SQL Injection utilizando método POST

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:

33. SQL Injection utilizando método POST

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.

35. SQL Injection utilizando método POST

36. SQL Injection utilizando método POST

37. SQL Injection utilizando método POST

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.