🔩Laboratorio: Exploiting time-sensitive vulnerabilities

Lo que pasa es que este laboratorio por debajo trabaja con PHP con CSRF’s los cuales cada petición sostiene y maneja un unico CSRF Válido junto igual que el PHPSessionId entonces con base en ello tiramos esa request de GET /Forgot-password sin cookie para poder obtener constantemente csrf y sessionId válidos para poder ponerlo en una de las request del ataque single packet attack.

La request sin cookie para poder obtener SessionId y CSRF válidos para poner en una de las request que pondremos en el tab group.

Tiempos identicos de reset de password: (con la request de race condition 2), la cual mandamos en cada request el mismo user wiener y vemos que llegan 2 tokens con tiempos identicos exactos, lo cual indica la race condition del problema sensible a los timestamps.

De la primer petición:

Lo unico que cambio es el csrf y el sessionId en una de los 2 request, con el get password sin cookie que así me genera csrf’s y sesionId’s válidos.

Luego de ello lo que podemos es cambiar el username de una de las 2 peticiones por carlos

Y enviamos el ataque por single paralell attack, en el inbox de correo solo llega un correo de verificación de token, eso que significa? que nos llego la request de wiener y la de carlos le llegó directamente a carlos a su inbox pero CON EL MISMO TOKEN 🙂

Solo es cuestión de abrir la url y modificar el query param donde está wiener por carlos:

Cambiamos la contraseña

E ingresamos con la nueva contraseña como carlos, asi tenemos acceso a admin panel:

Ya eliminó al condenado carlos y listo.