Lab: Exploiting time-sensitive vulnerabilities

Study the behavior

1. Study the password reset process by submitting a password reset for your own account and observe that you're sent an email containing a reset link. The query string of this link includes your username and a token.

2. Send the POST /forgot-password request to Burp Repeater.

3. In Repeater, send the request a few times, then check your inbox again.

4. Observe that every reset request results in a link with a different token.

5. Consider the following:

   • The token is of a consistent length. This suggests that it's either a randomly generated string with a fixed number of characters, or could be a hash of some unknown data, which may be predictable.
   • The fact that the token is different each time indicates that, if it is in fact a hash digest, it must contain some kind of internal state, such as an RNG, a counter, or a timestamp.

6. Duplicate the Repeater tab and add both tabs to a new group. For details on how to do this, see Creating a new tab group

7. Send the pair of reset requests in parallel a few times. For details on how to do this, see Sending requests in parallel.

8. Observe that there is still a significant delay between each response and that you still get a different token in each confirmation email. Infer that your requests are still being processed in sequence rather than concurrently.

Bypass the per-session locking restriction

1. Notice that your session cookie suggests that the website uses a PHP back-end. This could mean that the server only processes one request at a time per session.

2. Send the GET /forgot-password request to Burp Repeater, remove the session cookie from the request, then send it.

3. From the response, copy the newly issued session cookie and CSRF token and use them to replace the respective values in one of the two POST /forgot-password requests. You now have a pair of password reset requests from two different sessions.

4. Send the two POST requests in parallel a few times and observe that the processing times are now much more closely aligned, and sometimes identical.

Confirm the vulnerability

1. Go back to your inbox and notice that when the response times match for the pair of reset requests, this results in two confirmation emails that use an identical token. This confirms that a timestamp must be one of the inputs for the hash.

2. Consider that this also means the token would be predictable if you knew the other inputs for the hash function.

3. Notice the separate username parameter. This suggests that the username might not be included in the hash, which means that two different usernames could theoretically have the same token.

4. In Repeater, go to the pair of POST /forgot-password requests and change the username parameter in one of them to carlos.

5. Resend the two requests in parallel. If the attack worked, both users should be assigned the same reset token, although you won't be able to see this.

6. Check your inbox again and observe that, this time, you've only received one new confirmation email. Infer that the other email, hopefully containing the same token, has been sent to Carlos.

7. Copy the link from the email and change the username in the query string to carlos.

8. Visit the URL in the browser and observe that you're taken to the form for setting a new password as normal.

9. Set the password to something you'll remember and submit the form.

10. Try logging in as carlos using the password you just set.

    • If you can't log in, resend the pair of password reset emails and repeat the process.
    • If you successfully log in, visit the admin panel and delete the user carlos to solve the lab.

Intigriti