I
En este post corto y simple, detallará los pasos que lo haremos cuando necesitamos para explotar una vulnerabilidad de inyección SQL, que se basa sobre todo en algunos servidores SQL Server y Oracle. Estas vulnerabilidades son típicos en LOGIN DE Administrativo, porque como sabemos, que cuando entramos en el nombre de usuario y contraseña estos datos se envían a través del método POST, lo que puede haber la posibilidad de entrar falsas o algunos desvíos, esto nos puede mostrar un error que nos permite identificar la vulnerabilidad puede ser explotada de manera SqlMap corriendo un sistema automatizado utilizando comandos para enviar la solicitud de POST y GET no como "normal".
Si no me explico bien, por las pocas palabras sabias! a continuación, no más rodeos, tomamos acción!
Tenemos un inicio de sesión de ASP, que no tienen la información correcta, ni nada de eso, ya que no hemos encontrado ninguna vulnerabilidad en el servidor que nos da estos datos, por lo tanto, somos curiosos e inteligentes como empezamos probando datos falsos y algunas derivaciones como famosillo 'o' 1 '=' 1 como se muestra en la siguiente imagen:
Después de haber colocado esta derivación, somos capaces de mostrarnos el servidor alguna vulnerabilidad o error que nos permite identificar si es vulnerable a la inyección de SQL, tanto es así que si el servidor está bajo ASP esto nos puede mostrar el error " Proveedor Microsoft OLE DB para ODBC Drivers error '80040e14' "si esto sucede, tenemos la suerte de ser capaz de aprovechar esta vulnerabilidad. En este caso, después de haber colocado el bypass, el servidor devuelve el siguiente error:
Para ver esta vulnerabilidad, somos conscientes de que se puede explotar de forma manual o automática procesar para obtener datos que nos permite logearnos el camino correcto para el servidor.
Ahora, para continuar con las pruebas si el ingreso tiene algún otro tipo de vulnerabilidad, de vuelta a la forma y dejar nombre y contraseña en blanco y haga clic en Connect, que el servidor muestra lo siguiente:
Nada bien raro? ¿Por qué? ... Esta LOGIN muestra que las solicitudes no se validan, significa que si usted pone un bypass, esto muestra una vulnerabilidad, así como si dejamos el formulario en blanco y hacemos clic en conexión, esto nos permite saltarnos el inicio de sesión.
Bueno, después de unas pequeñas conclusiones alcanzadas en el servidor tiene una vulnerabilidad en el inicio de sesión y que las solicitudes no se validan, vamos a utilizar los encabezados HTTP en directo con el fin de ver las cabeceras de los cliqueemos tiempo Login Connect.
En este caso, después de colocar los encabezados HTTP en directo para escuchar lo que sucede en el servidor cuando hacemos clic en Conectar dejando todo blanco, esto nos devuelve a lo siguiente:
Hemos obtenido tres datos importantes! los cuales son:
- http://www.uap.edu.pe/intranet/logon2.asp
- POSTE / HTTP / 1.1 intranet / logon2.asp
- usuario = & pw = & user = 07 y B7 = + + + + Connect
La primera es, posiblemente, la URL Vulnerable, el segundo indica que la variable es POST y el último, los parámetros que son posiblemente vulnerable.
A continuación, proceder a explotar una vulnerabilidad automatizado que se encuentra en el inicio de sesión, utilizando sqlmap y ejecutar el siguiente comando en base a los datos recogidos por los encabezados HTTP Live.
- . / Sqlmap.py-u "http://www.uap.edu.pe/intranet/logon2.asp" - data = "user = & pw = & user = 07 y B7 = + + + + Connect" - p " level = 5 - - usuario "riesgo = 5 - dbs
Después de la herramienta ha terminado la auditoría del servidor, este detectará el "usuario" parámetro POST es vulnerable, como se muestra en la siguiente imagen
A partir de ahí, sabemos que esto es realmente LOGIN vulnerable y hemos explotado obteniendo así la plena satisfacción en toda la base de datos del servidor.
Ahora si! con este DB obtendrá los datos reales respectivas con éxito a los logearnos INGRESAR que así lo deseen;)
Espero que puedan.
Saludos.
