BurpSuite XII - Análisis Web OWASP, Ataques de Inyeccion SQL

En esta entrada veremos el primer punto del TOP 10 OWASP, en el cual conoceremos que es un ataque de Inyección SQL.

Ataques de Inyeccion SQL
Bypass a login por medio de Sqli.
Evitar filtros.

Ataques de Inyeccion SQL

Los ataque de inyección SQL son usados con el fin de obtener información sensible de una base de datos, por medio de peticiones o consultas SQL, por lo tanto una inyección SQL es la insercción de datos en campos de recepción de información que se infiere ser vulnerables para la ejecución de comandos SQL.

Para conocer mas sobre lo que es un ataque de inyección SQL les invito a que lean en la guía de OWASP como explotar y como sanitizar esta debilidad.

Bypass a login por medio de Sqli.

Esta llega a ser la primera explotación realizada con ayuda de la herremienta, lo realizaremos al formulario de Login el cual sobreentendemos que puede ser vulnerable a un ataque de Sqli que los desarrolladors pasaron el nivel de seguridad por el arco del triunfo (esta vulnerabilidad aun persiste a pesar de que la sanitización es bastante simple realizarla.)

1.- Lo que haremos primero será ingresar dos valores en los campos de autenticación en este caso puse Snifer | Snifer y los datos llegan a ser interceptados.

2.- El siguiente paso es click derecho y seleccionamos sent intruder.

3.- En este punto lo que tenemos que hacer es seleccionar el ataque Cluster Bomb. Además de ello debemos de agregar **§CAMPO DE ATAQUE§ **en los dos vectores de ataque.

4.- Luego de ello nos dirigimos a la pestaña Payloads, en los primeros campos Payload set tendremos 1 y 2, a lo cual tenemos la opción en cada uno de seleccionar un fichero del cual cargar los payloadas o bien adicionar uno a uno.

5.- Por ultimo atack! :D.

Pero aquí no termina todo, una vez que realiza el ataque iterará en los campos seleccionados, el resultado lo veremos en otra ventana en la cual se observara las iteraciones realizadas como la siguiente captura.

Pero que sucede no llegamos a tener un filtro para identificar los resultados que nos sirve, nos toca revisar petición por petición aun mas cuando todos son 20, llega a ser tedioso la revisión para evitar eso podemos seguir la respuesta se ve que cambia 282 y 297 podría ser un parámetro a observar pero muchas veces estos mantienen y la respuesta llega a ser diferente. Por lo tanto realizaremos un par de configuraciones.

Primero, necesitamos identificar algún mensaje o respuesta que nos da el sitio web cuando fallamos un intento de sesión, veremos un ejemplo el de Facebook, ahí tenemos algunos valores que podemos usar para validar.

Entonces esta configuración para identificar las respuestas que necesitamos filtrando, una vez que configuramos el ataque con intruder nos dirigimos a Options nos vamos a Grep-Match en el cual agregamos el termino que deseamos que valide, una vez que encuentre nos notifique.

Se observa que es posible hacer uso de expresiones regulares, honestamente este punto de las expresiones es mi talón de Aquiles no tengo un conocimiento avanzado.

Ahora vemos en la siguiente captura los dos estados los que se encuentran check son aquellos que devolvió como respuesta la sesión errónea y los que no están marcados son diferentes con ello, se reduce el área de trabajo.

Se ve que llevamos buen trecho en esta página, al validar accedemos como administradores, o el perfil que se encuentre en el sitio web, esta configuración no solo llega a ser usada en este tipo de vulnerabilidad también en otra aclarando esto vemos el resultado.

!ATENCION!

Para los que pregunten de donde obtener o con que diccionarios trabajar en las pruebas, tenemos a nuestra disponibilidad en Kali, lo que les recomiendo es hacer uso de ellas o bien generar sus propios archivos, para SQL, XSS, Path Transversal, de wfuzz que llega a tener los mejores diccionar según mi percepción.

Por lo tanto por si alguien pregunta referente a los diccionarios o de donde sacar aquí esta la respuesta, posterior a esto armare un listado referente de los payloads por decirlo así aunque con estos tenemos.

Evitar filtros

En el caso de existir algun tipo de filtro o control para los ataques que se realizen se debe de considerar lo siguiente la opción de Payload Encoding.

Como tambien en la parte de Payload Processing tenemos la opción de crear reglas cuando se ejecute el payload tenemos varias opciones al seleccionar la regla.

Por ejemplo cuando seleccionamos el encode nos brinda las siguientes opciones.

En una proxima entrada pasaremos a usar la herramienta estoy seguro por ahora terminamos con esta, espero les agrade, al finalizar las pruebas OWASP realizaremos un paso por los plugins.

Entradas anteriores de la serie

Regards,
Snifer

BurpSuite XII - Análisis Web OWASP, Ataques de Inyeccion SQL

!ATENCION!

See Also