Sql injection utilizando método post

SQL Injection utilizando

método POST

Herramienta sqlClase 2 29/08/2013

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.


Estas vulnerabilidades son típicas en los LOGIN'S Administrativos, ya que

como debemos de saber, que cuando ingresamos el usuario y passwordestos 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 famoso ' or '1'='1 como se muestra en la imagen

siguiente:



Antes de eso recordemos que mantra esta integrado en la suite de

backtrack como se muestra a continuación



Después de darle clic nos aparecerá las siguiente secuencia de ventanas





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.


Actualidad


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:



Aun así como se menciono anteriormente trataron de corregir el error pero

sigue apareciendo el mismo error como se muestra a continuación



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:



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:




¿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.


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


Recordemos que el sqlmap se encuentra el la suite del backtraq como se

muestra a continuación



Introducimos la sentencia en sqlmap que se menciono anteriormente y

procedemos el analisis



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 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.

Documents

Sql injection utilizando método post