La vulnerabilidad Cross Site Request Forgery (CSRF o XSRF) o de "falsificación de petición en sitios cruzados" consiste en que un atacante aprovecha que un usuario está validado en un servicio web vulnerable para engañarle y que realice sin percatarse una acción malintencionada. El ejemplo más común es que un usuario está loggeado en la web de su banca personal y recibe un enlace que al pincharlo lleva a cabo automáticamente una transferencia bancaria. La web del banco digamos que "confía ciegamente" en las peticiones que recibe del usuario una vez que se ha validado.
Para controlar en todo momento que las peticiones que llegan son realmente debidas a la interacción del usuario verdadero, es decir, que en ningún momento ha sido impersonado, se suele utilizar un campo oculto en el formulario correspondiente (por defecto _token) que contiene un valor que sólo el servidor y el usuario conocen. Esta protección CSRF es también una "molestia" si queremos hacer un ataque de fuerza bruta o de diccionario contra un formulario de login, porque tendremos que configurar nuestro Burp para que añada y valide automáticamente los tokens CSRF. En este post veremos cómo hacerlo en un sencillos pasos...
Primero veamos nuestro ejemplo. Observamos que por cada petición se manda un token CSRF junto con el nombre de usuario y la contraseña:
Ese token precisamente es el que irá cambiando y mostrándose en el campo oculto del formulario de login.
Después de capturar la petición y enviarla al Intruder, nos iremos a la pestaña de Posiciones y marcaremos como payloads el contenido de los parámetros __csrf_magic y passwordfid.
El tipo de ataque será 'Pitchfork' que irá cambiando ambos payloads (diferentes) al mismo tiempo:
Luego, para asegurarnos que nuestro ataque empiece correctamente, debemos copiar el primer token en la casilla del payload inicial para la primera petición:
El siguiente paso será configurar el segundo payload con una simple lista que contenga los passwords para nuestro ataque de diccionario:
Antes de lanzar el ataque no olvidéis bajar el número de hilos de 3 (por defecto) a 1 porque si no este tipo de ataque fallará. Recordar... iremos más lentos pero bypassearemos la protección CSRF:
Ahora a cruzar los dedos y a esperar si obtenemos alguna contraseña correcta... ;)
Para controlar en todo momento que las peticiones que llegan son realmente debidas a la interacción del usuario verdadero, es decir, que en ningún momento ha sido impersonado, se suele utilizar un campo oculto en el formulario correspondiente (por defecto _token) que contiene un valor que sólo el servidor y el usuario conocen. Esta protección CSRF es también una "molestia" si queremos hacer un ataque de fuerza bruta o de diccionario contra un formulario de login, porque tendremos que configurar nuestro Burp para que añada y valide automáticamente los tokens CSRF. En este post veremos cómo hacerlo en un sencillos pasos...
Primero veamos nuestro ejemplo. Observamos que por cada petición se manda un token CSRF junto con el nombre de usuario y la contraseña:
Ese token precisamente es el que irá cambiando y mostrándose en el campo oculto del formulario de login.
Después de capturar la petición y enviarla al Intruder, nos iremos a la pestaña de Posiciones y marcaremos como payloads el contenido de los parámetros __csrf_magic y passwordfid.
El tipo de ataque será 'Pitchfork' que irá cambiando ambos payloads (diferentes) al mismo tiempo:
Después nos situaremos en la pestaña de Payloads y seleccionaremos el payload 1 (el del token CSRF) como 'Recursive Grep'. Un poco más abajo debemos indicarle las expresiones entre las que se situará el token en el formulario:
Para ver dónde se sitúa exactamente lo mejor es ir al Repeater y analizar la respuesta a una petición de login, donde extraeremos el código HTML:
Luego, para asegurarnos que nuestro ataque empiece correctamente, debemos copiar el primer token en la casilla del payload inicial para la primera petición:
El siguiente paso será configurar el segundo payload con una simple lista que contenga los passwords para nuestro ataque de diccionario:
Antes de lanzar el ataque no olvidéis bajar el número de hilos de 3 (por defecto) a 1 porque si no este tipo de ataque fallará. Recordar... iremos más lentos pero bypassearemos la protección CSRF:
Por último lanzamos el ataque:
Y comprobamos que las primeras respuestas nos desvuelven un mensaje de credenciales incorrectas en lugar de un error por la protección CSRF:
Ahora a cruzar los dedos y a esperar si obtenemos alguna contraseña correcta... ;)
Prefiero ZAP, soy un poco talibán contra Burp (Richard Stallman me comió la cabeza).
ResponderEliminarAunque me resulta imposible admitir que Burp es una gran herramienta. Espero que pronto ZAP le sobrepase a lo grande.