"INYECCIONES SQL AUTOMATICAS CON HAVIJ"

 

aqui vemos que el anterior codigo es vulnerable ya que no esta validando muy bien las entradas,  la variable usuario se esta enviando por el metodo post  hasta aqui todo bien vale?, pero que sucede si rompo con el query?,  si en vez de esa consulta a la base de datos, yo hago que la consulta se rompa con una comilla simple por ejemplo?,  ahora vamos a ver una simple busqueda en google para ver que sitios pueden ser vulnerables a este hacking web.

 

vemos que esta haciendo las validaciones necesarias para que la entrada ala base de datos las tome como validas y las pasen a convertirse en consultas correspondientes a las bases de datos.

haciendo esto manualmente nos conllevaria mucho tiempo en la auditoria ya que tendriamos que ir verificando y lanzando cada comando correspondiente a la entrada de la bases de datos de la pagina web.

una aclaracion muy importante que quiero hacer es que la seguridad por oscuridad no funciona, digo esto porque me he topado en varias ocasiones con el error sql i blind,  , dicho error se basa ya no en una vulnerabilidad sql inyeccion tan facil como la mostrada en esta entrada,  pero tambien puede dar al atacante informacion muy importante para dar con los valores exactos que la base de datos quiere decir, por ejemplo si nos encontramos ante una sqli blind o mejor conocida como una inyeccion de tipo sql a ciegas,  el atacante puede hacerle consultas en tipo de preguntas alas bases de datos como por ejemplo: 

SELECT * FROM usuarios WHERE usuarios=ad

si la consulta nos muestra un resultado verdadero o TRUE,  entonces podemos ir intuyendo que informacion esta dentro de la base de datos.

aunque las consultas esten filtradas pero no Las Validaciones vamos de pasar a tener una vulnerabildiad sql i a una vulnerabilidad sql i blind o a "ciegas" como se le llama  a las consultas filtradas pero no validadas consecuentemente.

 podemos ver que logramos introducir la inyeccion por los parametros validados en la conexion hacia la base de datos.

ahora toca volcar la base de datos y sus correspondientes tablas.

algo muy interesante es que nos ha brindado ademas informacion my importante de las bases de datos es la version del servidor entre otros detalles que nos pueden servir de mucha ayuda para un escaneo de sus redes mas a fondo.

podemos elegir entre las bases de datos dumpeadas,  podemos obtener los hashes para romperlos ahi  mismo con la utilidad que trae por defecto entre otras cosas.

vamos a obtener las tablas de la base de datos secundaria aver que resultados tiene que deciros.

luego de haber volcad las tablas de nuestra eleccion, toca volcar las columnas , una vez volcadas las columnas enteras, entonces podemos clickear en el boton de get all data o extraer todas la informacion dentro de las tablas.

en una proxima entrega practicaremos el llamado sql a cigas o la inyeccion a ciegas, dicha explotacion de tal inyeccion es un poco mas dificil ya que las consultas estan filtradas pero igual que esta inyeccion vista en esta entrada no esta bien validad y entonces podemos romper con los querys.

para no hacer nada ilegal o una intrusion sin autorizacion previa no entre ala tabla de los usuarios y contraseñas ya que eso repercutiria en la organizacion ala que le hice la inyeccion asi que para fines educativos solamente,  solo inyecte unas tablas sin un valor absoluto importante de informacion.

como vemos al estar programando nuestros formularios y nuestras conexiones hacia las bases de datos, debemos tener muy presente este fallo de seguridad  y sobretodo debemos tener muy en cuenta las metodologias de desarollo que estamos utilizando,  debemos adoptar una metodologia de desarollo que permita verificar una vulnerabilidad antes de que se desarollo por completo , osease debemos testear las aplicaciones antes de ponerlas en ejecucion y sobretodo antes de llevarlas al publico de la gran red de redes.

nos vemos 

the pentester.