La entrada de hoy abordaremos el segundo punto de análisis de OWASP que es la Perdida de autenticación y Gestión de sesiones en el cual abordaremos los siguientes puntos:
Validación de controles en el lado del Cliente
- Validaciones JavaScript, Validaciones HTML
- Identificación de datos no cifrados
Debilidades en formulario de Login
- Liberación de usuarios
- Identificación de mensajes de Login
- Fuerza bruta al Login
Espero disfruten de la entrada como lo disfruto al momento de realizarla.
Validación de controles en el lado del Cliente
Validaciones JavaScript, Validaciones HTML
Para identificar estas debilidades por decirlo así atacamos al desarrollador considerando que muchas veces no se tiene un control de desarrollo, no se considera el manejo de variables de cifrado, validaciones en el lado del cliente las respectivas configuraciones ya las vimos con anterioridad pero ahora es momento de notar un poco mas a detalle.
En la página que estamos realizando las pruebas respectivas con la herramienta, tiene el formulario de Login el cual nos sirve para realizar esta validación y se nota claramente que cuenta con un campo oculto.
No tenemos mucho campo para ir jugando ademas que realizando un desbordamiento de la contraseña no controla así que este no es un buen ejemplo para ello pero la idea esta clara.
Bueno ese llega a ser un ejemplo, pero veremos ahora un formulario de comprar de BurpSuite realizado en HTML algo simple que nos sirve para entender y comprender aún mas esta debilidad.
Parámetros por URL: Esto se ve muchas veces, en este caso se observa que se envian los datos por URL ya sean así en texto claro como vemos en la siguiente captura aun cuando se envíen por post y no por get pero como saben todo es posible interceptar.
Identificación de Parámetros no cifrados
Este punto es importante ya que muchas veces no se considera realizar un cifrado de datos, valores críticos, por ejemplo valores de login, al realizar un cambio de contraseña, se van en texto claro un atacante intercepta realizando un sniffeo ya cayo, o bien cambiar el parámetro y asignar otra contraseña estos ataques llegan a tener varios vectores.
Debilidades en formulario de Login
Liberación de usuarios.
Muchas veces ocurre que las aplicaciones web hablan por si solas permitiendo identificar usuarios, contraseñas por medio de los mensajes de respuesta que nos da me refiero a lo que se muestra a continuación dos ejemplos uno de Wordpress que al poner un nombre correcto y contraseña incorrecta.
Nos devuelve el mensaje que el usuario es correcto pero la contraseña no.
El segundo es otra aplicación que nos indica del mismo modo que el usuario no existe, en cambio al ingresar uno correcto nos da la respuesta.
Con esto es posible identificar usuarios, y posteriormente realizar un ataque de fuerza bruta a la aplicación lo cual veremos en el siguiente punto.
Identificación de mensajes de Login
Este punto lo vimos anteriormente cuando realizamos las pruebas de inyección SQL, así también se puede tomar como para comprender lo que nos brinda dándonos mensajes notificaciones que vimos en el punto anterior.
Estar atentos cuando indicamos una contraseña incorrecta para identificar y hacer uso de ellos, ya verán la razón de ello en el siguiente punto.
Fuerza bruta al Login
Al identificar el formulario de Login tenemos que realizar la prueba ingresando algun dato de prueba a lo cual si cuenta con mensajes de error demasiado descriptivos, o bien como simple identificación logramos ver el mensaje de error de DATOS INCORRECTOS.
Lo que hacemos al interceptar el paquete es enviar al Intruder, y seleccionamos el ataque Cluster Bombo teniendo a dos vectores de ataque el usuario y la contraseña.
Ahora lo que necesitamos es identificar los dos valores que haremos uso, para la carga de payload que son los valores Snifer Snifer los datos ingresados como prueba.
Una vez realizado ellos nos dirigimos a Payloads y cargamos nuestra lista de usuarios y contraseñas como corresponda, considerando que también es posible cargar desde una lista que es generada por la misma herramienta que se encuentra en la parte inferior.
Recomiendo revisen las opciones que nos brinda ya que tenemos para SQL, XSS, Generación de datos alfabéticos, numéricos según nuestras necesidades en el proceso del pentesting.
Una vez terminada la configuración se procede a iniciar el ataque y tendremos el resultado como se ve en la primera imagen nos muestra el resultado pero, muchas veces digerir la información es algo molestoso hasta moroso.
Por ello lo que hacemos es ir a las opciones del ataque que realizamos y en GREP Match agregamos el valor identificado previamente el cual nos ayudara en el proceso de análisis de los resultados.
Ahora si observamos el resultado de la prueba, con el nuevo campo que nos ayuda a seleccionar e identificar los datos que son correctos, en este caso me llamó mucho la atención que el sitio carece de control total de los datos de ingreso es totalmente indiferente a mayúsculas y minúsculas.
Espero les agrade esta entrada realizada y continuamos con la próxima entrada.
Entradas anteriores de la serie
BurpSuite II - Intercepted, Tampering request! conociendo al proxy
**BurpSuite IV - **Configuración de Certificado digital, ProxyTOR?, guardando y recuperando
**BurpSuite VI - Burp Suite Pro Real life tips and tricks **
BurpSuite VII - Match and Replace, Modificaciones HTML, Encoding and decoding
BurpSuite VIII - Historia de peticiones, Comparando Sitemaps, Reporte de Vulnerabilidades
BurpSuite IX - Cookie Jar, Extensiones, guardado automático y estabilidad.
Burpsuite XI - BurpSuite XI - Análisis Web OWASP, Conociendo la aplicación
BurpSuite XII - Análisis Web OWASP, Ataques de Inyeccion SQL
BurpSuite XIII - Análisis Web OWASP - Descubriendo directorios y ficheros ocultos
Regards,
Snifer
