Pentester Diaries 2.0

"ENCONTRANDO UN FALLO EN UNA PAGINA EN UN INSTITUTO EDUCATIVO DE MEXICO (GOBIERNO)"

"FALLO SQLI BASICO CON MOD_SECURITY ACTIVADO"

Un lunes por la tarde , estaba un poco aburrido ya que no tenia nada que hacer, la pelicula que me disponia haber mientras devoraba palomitas no cargaba aun, ya que no me gusta ver las peliculas en modo tortuga claro esta. entonces me dispuse a buscar en internet cursos para ver cuales podia tomar en un instituto local de mi estado en horario sabatino, dicho instituto ofrece cursos muy buenos mas sin embargo su seguridad no esta del todo muy buena que digamos.

mientras navegaba por su pagina me encuentro con un macabro y terrorifico fallo de seguridad pues nada mas y nada menos que un fallo sql inyeccion o sqli, me di cuenta del fallo al cambiar el valor del parametro en la url id=27 a id=%27 lo que corresponde a id=' la comilla rompe con las querys hacia la base de datos, muchas veces me he encontrado paginas con este mismo fallo en pleno 2018 pero al contrario de esta pagina tiene filtros y se tiene que buscar las tecnicas para traspasar estos filtros de seguridad.

como podemos ver al incluir la comilla la query se rompe y nos muestra un error, causa de que estamos frente a un fallo grave de seguridad.

se puede obtener muchas cosas con este fallo como lo vamos haber mas adelante.

contrario a todos los tipos de sqli que existen como estan el sqli a ciegas, sql blind, sqli por enteros o sqli integer, etc, el fallo que encontre en esta web fue solo un fallo basico que cualquiera puede explotar, a dia de hoy existen multitud de herrameintas que hacen el trabajo por nosotros, aunque queda a gusto para no parecer un script kiddie de engorronarnos con tantas herramientas para no caer en los falsos positivos de los cuales pudiera haber graves consecuencias.
me di ala tarea de buscar manualmente el fallo y posteriormente explotarlo con sus graves consecuencias en lo absoluto.
cuando me di cuenta que detras de este fallo estaba activado el mod_security mi cara se volvio asi:

despues me dispuse a investigar en diferentes recursos por la web cuales eran los metodos mas eficaces para traspasar esta molesta barrera de seguridad, que son los WAF. lo que hacen los WAF es filtrar las palabras reservadas conocidas como UNION TO, ALL, *, etc, el principal objetivo del atacante es ofuscar los parametros enviados e interpretados hacia las bases de datos.
este es un ejemplo de como es posible traspasar las medidas de seguridad cibernetica.

en los comandos pasados a la herramienta sqlmap podemos observar el -u que es la url que sera sometida a la inyeccion y -a que extraera toda la base de datos y usuarios, el parametro -p es el parametro vulnerable que sera la inyeccion vulnerable, el tamper es la cabecera modificada que se envian y modifican al "vuelo" "on the fly".
el mensaje critico y la detencion para traspasar el mod_security es critico lo que en instancia deberiamos primero traspasarlo y despues volcarlo.

REFERENCIAS Y ENLACES TECNICOS:

https://www.w3schools.com/sql/sql_injection.asp

https://www.owasp.org/index.php/SQL_Injection
http://docplayer.es/2158273-Bypass-wafs-kunak-consulting-automatizando-sqli-con-python-omar-palomino-omarc320-gmail-com-opalomino-kunak-com-pe-http-www-el-palomo.html
https://underc0de.org/foro/pentest/bypasseando-waf-con-sqlmap-tamper/

"INYECCIONES SQL AUTOMATICAS CON HAVIJ"

Cuando hablamos de vulnerabilidades web no puede faltar la tan famosa sql inyeccion , el cual la entrada de un formulario php no valida muy bien las entradas hacia la bases de datos y entonces podemos volcar toda la informacion que se encuentra en estas mismas.
la vulnerabildiad sql inyeccion se encuentra entre una de las vulnerabilidades en plataformas WEB mas reconocidas mundialmente como lo podemos observar en la siguiente imagen del top ten de OWASP.

ahora voy a explicaros un poco del porque sucede todo esto, cual es su causa?
pues la respuesta es la siguiente:
resulta que esta es una vulnerabilidad que se basa en la incorrecta validacion de las consultas desde el formulario web hacia la base de datos, se encuentre o no esta ultima en el mismo servidor o no , eso no importa lo que importa en realidad es que las consultas hacia la base de datos se estan filtrando mal.

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.

inmediatamente el buscador nos arroja multiples resultados de los cuales todos son vulnerables, vamos a comprobar como es que podemos saber si el sitio web que queramos auditar es vulnerable, solo con colocar una ' simple entre los parametros podemos saber si el sitio en realidad es vulnerable a un ataque de tipo sql inyeccion.
y porque una ' ?
pues por lo siguiente:
una consulta normal mediante el anterior formulario seria este caso:

en el segundo caso mostrado 1=1 por lo que la consulta hacia el usuario siempre sera verdadera, osease la validacion siempre arrojara resultados verdaderos y siempre entraremos y consultaremos en la conexion hacia la base de datos.
vamos a ver pues, como detectamos una pagina web vulnerable a este tipo de errores.

podemos ver que logramos romper el query o la consulta ala base de datos y provocar un pequeño error que nos dice que ha ocurrido un error de sintaxis y que corresponde ala linea 1. :v
LOL.
lo expuesto aqui es solo un ejemplo sencillo, hay algunas ocasiones en las que tendremos que buscar y buscar para ver donde exactamente se encuentra el error, en algunas ocasiones la vulnerabilidad ira dentro de dos parametros como por ejemplo: students&notes=1 donde podremos modificar a students&notes=' y si nos salta este pequeño errorcito , entonces estamos ante un error sql inyeccion, tambien cabe destacar que debemos utilizar los dorks adecuados para dar en el blanco exactamente.
vamos a seleccionar la anterior pagina para ver que tiene que deciros para nosotros ;).
lo podriamos hacer manualmente tambien con hackbar o el grandoso hackbar modificado que incluye mas herramientas que el anterior original, pero este no es el objetivo de esta entrada asi que nos limitaremos a usar solo la herramienta havij y a unas cuantas explicaciones sobre este tema.
seleccionamos la url de la pagina web o de la parte de la pagina web vulnerable y la colocamos en havij.

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.

podemos ver como volcamos todas las tablas y con usuarios, etc.
ahora nos toca volcar las columnas de las tablas para ver que datos se encuentran dentro de tales tablas.
vamos alla.

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.

bitcoin prize

"ENCONTRANDO UN FALLO EN UNA PAGINA EN UN INSTITUTO EDUCATIVO DE MEXICO (GOBIERNO)" "FALLO SQLI BASICO CON MOD_SECURITY ACTIVADO"

"INYECCIONES SQL AUTOMATICAS CON HAVIJ"

My Instagram

Cybersecurity Tags

Uso cookies para darte un mejor servicio.