BLOG

CSRF -Summary-

Hola a todos, después de haber realizado todos los ejercicios del CourseWork de HackerOne, iremos haciendo un breve resumen de las vulnerabilidades encontradas y de como facilitar la localización y explotación.

CSRF

En estos ataques, el atacante crea un código HTML que obliga al navegador del usuario a realizar una acción directa a la aplicación vulnerable, pudiendo ser agregar, eliminar usuarios, autenticarse con otro usuario, cambiar opciones en la aplicación vulnerable, etc..

Para identificar una aplicación vulnerable a CSRF lo primero que debemos tener en cuenta es que el 90% de las aplicaciones que simplemente tienen HTTP cookies para trackear las sesiones pueden ser vulnerables.

Normalmente, para realizar un ataque CSRF hay que tener en cuenta que:

  • En primer lugar, fijarse en la petición y si a través de esta se puede realizar una acción con supuestos privilegios.
  • En segundo lugar y de los más a tener en cuenta es si la aplicación solamente sigue las sesiones con HTTP cookies y si no existen tokens adicionales de protección.
  • En tercer lugar, si mediante la petición se pueden observar todos los parámetros necesarios para realizar el ataque.

Si se cumplen los tres requisitos anteriormente mencionados, significa que tenemos vía libre para construir nuestro código HTML y vulnerar la aplicación.

Ya solamente nos faltaría crear el código HTML y modificar los parámetros. Yo utilizo la herramiente en BurpSuite que esta en Engagement Tools que se llama Generate CSRF POC. Esta herramienta te crea el código HTML y luego simplemente tenemos que pasarlo a nuestro editor de textos y modificar los parámetros que queramos, para luego ejecutar la petición.

PERO… no todo es de color de rosa..

Hoy en día, existen pocas aplicaciones web que no utilizan tokens adicionales anti-CSRF, envíados por hidden fields mediante HTML forms. Cabe la posibilidad que el atacante no sepa el camino para determinar el valor del token y por este motivo no podría ejecutar el ataque satisfactoriamente.

Cuando nos encontramos ante este tipo de situaciones, tenemos las mismas opciones de bypass que con los tokens de sesión normales:

  • En primer lugar, si un atacante puede predecir los valores de los tokens que son enviados a otros usuarios, puede determinar todos los parámetros requeridos para un ataque CSRF.
  • En segundo lugar, si los tokens anti-CSRF no están vinculados a la sesión del usuario al que se emitieron, un atacante puede obtener un token válido en su sesión y utilizarlo en un ataque CSRF, en una sesión de un usuario diferente.

A continuación os dejo un video de ejemplo:

Hasta la próxima 😀

Anuncios

XSS -Summary-

Hola a todos, después de haber realizado todos los ejercicios del CourseWork de HackerOne, iremos haciendo un breve resumen de las vulnerabilidades encontradas y de como facilitar la localización y explotación.

xss

En primera instancia tendremos que realizar con BurpSuite un “Spider this Host” para encontrar todas las URL’s con sus respectivos parámetros.

Procederemos a detectar todos esos parámetros de entrada, los cuales podamos manipular a nuestro antojo. Si una vez cambiamos el valor del parámetro y este es reflejado en el código fuente sea cual sea el lugar, probablemente al 90% sea vulnerable a XSS. Para realizar este paso lo que yo hago es cambiar el nombre de todos los parámetros por ejemplo por vuln1, vuln2, vulnn, etc.. y mediante el Repeater de BurpSuite veo cual de ellos se ha reflejado.

Una vez tenemos el parámetro de entrada que probablemente sea vulnerable a XSS, intentamos inyectar y  ejecutar código Javascript, si este se ejecuta ya tenemos nuestra vulnerabilidad explotada. Una opción para ahorrarnos tiempo es usar el Intruder de BurpSuite, el cual configuramos los parámetros de entrada que queramos explotar y podemos incluir una lista de payloads para ahorrarnos mucho tiempo. Usando Intruder tened en cuenta la longitud (length) del caso base con los de la lista de payloads, como más longitud obtengamos más probable sea de que haya sido fructuoso el ataque.

Los lugares más probables donde injectar serían en URL’s como pueden ser un formulario de contacto, una búsqueda, una zona de comentarios, foros, pagínas de autenticación y de firmas.

PROOF OF CONCEPT -VIDEO-

Level 3: Breaker CMS

Hola a tod@s!, cuarta entrega del CourseWork de HackerOne. En este nivel alteramos las cookies, explotamos CSRF, hacemos un par de XSS reflected y por último vulneramos la web con file inclusion.

Breaker CMS

Documentación e información de las vulnerabilidades:

XSS Reflected

CSRF

File Inclusion

Cookies Attributes