Time sensitive vulnerabilities

Description

This lab contains a password reset mechanism. Although it doesn't contain a race condition, you can exploit the mechanism's broken cryptography by sending carefully timed requests.

To solve the lab:

1. Identify the vulnerability in the way the website generates password reset tokens.

2. Obtain a valid password reset token for the user carlos.

3. Log in as carlos.

4. Access the admin panel and delete the user carlos.

You can log into your account with the following credentials: wiener:peter.

Approach

Upon logging in, I immediately directed my attention to the password reset mechanism and initiated a password reset request for the user "wiener." Subsequently, I received an email containing a password reset link, which resembled the following:

Hello!

Please follow the link below to reset your password.

https://0af5004a040e6d0d8118570100ed00bf.web-security-academy.net/forgot-password?user=wiener&token=27225ed3d0e17217afd181a486e8c59626f48301

Thanks,
Support team

Each password reset request is accompanied by a special token, purportedly generated using timestamps. However, this approach is susceptible to manipulation and predictability, thus constituting a vulnerability.

To exploit this vulnerability, I devised a plan to request a password reset for the "carlos" user, utilizing the same token obtained for "wiener." Achieving this required synchronizing the processing times of both requests to ensure identical tokens were generated for each user, disregarding differences in response times.

To synchronize the requests, I created a tab group comprising two password reset requests for both "wiener" and "carlos." Considering potential session locking restrictions due to the backend PHP implementation, I manipulated the session cookies to ensure distinct sessions for each request.

Initially, I sent a GET /forgot-password request to Burp Repeater, removing the session cookie before resending it. From the response, I extracted the newly issued session cookie and CSRF token for use in replacing the respective values in one of the POST /forgot-password requests, ensuring different sessions for each user:

Additionally, the CSRF token was located in the response:

After updating the session cookie and CSRF token for the "carlos" user, I sent the group of requests in parallel. Upon receiving the confirmation link at the email server associated with "wiener," I copied the link and modified the user parameter from "wiener" to "carlos," accessing the password reset page for "carlos" with the same token.

If the initial attempt failed, I repeated the process, verifying the token each time, as success depended on timing. Ultimately, upon changing the password for "carlos" and logging in as him, followed by deleting the "carlos" user, the lab was successfully solved.