Lab: Exploiting time sensitive vulnerabilities

Study the behavior

After starting the exercise, the blog should be similar to the one shown in the screenshot. We will now inspect the password reset process. To do this, click on the "My account" link.

We are now taken to the login form and click on the link "Forgot password?".

Here we now enter our user name wiener and send the form.

In the browser we receive the message "Please check your email for a reset password link.". Now we open our mail client by clicking on "Email client".

We now see the email that allows us to reset our password. If we click on "View raw", we can view the complete mail in the browser.

The mail looks like this:

Sent:     2025-03-24 06:54:41 +0000
From:     "No reply" <[e-mail]>
To:       [e-mail]
Subject:  Account recovery

Hello!

Please follow the link below to reset your password.

https://0af600c9049695a380803a5b00ec0099.web-security-academy.net/forgot-password?user=wiener&token=916d8fca9ea6b712ed9bdd175ab7c64d0b5fb550

Thanks,
Support team

In line 10 we see our user name wiener and a token 916d8fca9ea6b712ed9bdd175ab7c64d0b5fb550. We now reset our password once by clicking on the link in the mail.

We are then taken to a form where we can set our new password. The new password should be noted down. In this example, we use the password peter.

Now we switch to the Burp Proxy and open the "HTTP history" there. In the "HTTP history" we search for a POST request to the endpoint /forgot-password.

We now send this request to the Burp Repeater. To do this, we move the mouse over the request and press the right mouse button. A context menu appears in which we select the option "Send to Repeater".

In Burp Repeater, we now send this request to the application a few times and check our mailbox. To send, we click the "Send" button in the repeater.

We arrive at the mailbox, where we click on "Email client".

We see in our inbox that we have received a few emails. If we look at the tokens, we can see that each mail contains a different token.

It should be noted that the token has a constant length. This leads to the assumption that it is either a randomly generated character string with a fixed number of characters or a hash of unknown data that could be predictable. The fact that the token is different each time suggests that if it is indeed a hash digest, it must contain some kind of internal state, such as an RNG, a counter or a timestamp.

We now create a tab group in Burp Repeater. To do this, we click on the "plus sign" next to the tab name.

A menu appears in which we select the "Create tab group" option.

We then create a new tab group with the name "RC-6" and add the existing tab to the group. This tab should contain the request POST /forgot-password HTTP/2.

If you have any questions about creating tab groups, please refer to the Burp Suite documentation. Now we create a copy of the tab in our tab group "RC-6". To do this, we move the mouse over the tab in the tab group and click the right mouse button.

In the context menu, select the ‘Duplicate tab’ option.

A window appears in which we have to specify the number of copies of our tab, we enter "1" here.

Now we want to send this tab group to the application in parallel. A few settings are necessary for this. First, we click on the "Arrow down" next to the "Send" button.

In the context menu, we select "Send group in parallel (single-packet attack)". If you have further questions about parallel sending, the Burp Suite documentation will help you.

Your ‘Send’ button should now look like this:

Now we send the tab group to the application a few times and observe the response times. We notice that there are significant differences in the times.

Response 1

Response 2

It should be noted that there is always a significant delay between the individual responses and that a different token is issued in each confirmation e-mail. This indicates that the requests are not processed simultaneously, but one after the other.

Bypass the per-session locking restriction

If we take a closer look at a request, we can see that it is probably a PHP application, as we find a reference to it in the Cookie header (phpsessionid=n5ChsucimCILfpIdxDwVqCQCZ4v3548h).

POST /forgot-password HTTP/2
Host: 0af600c9049695a380803a5b00ec0099.web-security-academy.net
Cookie: phpsessionid=n5ChsucimCILfpIdxDwVqCQCZ4v3548h
Content-Length: 53
Cache-Control: max-age=0
Sec-Ch-Ua: "Not:A-Brand";v="24", "Chromium";v="134"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Accept-Language: de-DE,de;q=0.9
...

We now switch to the Burp Proxy and search for a GET request to the endpoint /forgot-password.

We now send this request to the Burp Repeater. To do this, we move the mouse over the request and press the right mouse button. In the context menu, we select the option "Send to Repeater".

In the Burp Repeater, we remove the Cookie header (Cookie: phpsessionid=n5ChsucimCILfpIdxDwVqCQCZ4v3548h) from the request we just sent and send the request to the application. In the response, we receive a new session ID (phpsessionid=JpF5Nnq3OrzCbVxNwARLfcncz41vxnYt) and a new CSRF token (CHaOgDjCdocHVO8jGeyG2XCv9lvlIT9J).

We now insert the new session ID and the new CSRF token into one of the two requests in our tab group "RC-6".

We now send our tab group "RC-6" to the application a few times in parallel and observe the response times. As we can see, the response times are no longer so far apart. Some of them are identical.

Confirm the vulnerability

If we now switch to our mailbox, we can see that if the response times are identical, the tokens in the mail are also identical. This confirms that a timestamp must be one of the inputs for the hash. It should be noted that this implies that the token would be predictable if the other inputs for the hash function were known.

It should be noted that the separate parameter username must be taken into account. This suggests that the username may not be included in the hash. As a consequence, this means that two different usernames could theoretically have the same token. We now change the user name in one of our requests in the tab group "RC-6" to carlos. We also need a "fresh" session ID and a "fresh" CSRF token. We create these with the request in which we have removed the session ID. See the following screenshots:

The request with the user name carlos should now look like this:

We now send our tab group to the application in parallel and switch to our mailbox. Here we copy the link from the first mail.

Within the link we see the parameter username with the value wiener. We replace wiener with carlos and paste the link into the address bar of the browser and press ENTER.

https://0af600c9049695a380803a5b00ec0099.web-security-academy.net/forgot-password?user=carlos&token=2c16c4646705a5faca16166643fb474ffa250bc0

We are now taken to a form where we can assign a new password.

We make a note of the password and click on the "My account" link and log in with carlos and the password.

What is important in this section is that the response times can be different and the token still works with carlos. This can save you a little time. :-)

After logging in, we see the account of carlos and click on the link "Admin panel".

Now we delete the user carlos by clicking on the link "Delete" next to the user name carlos.

We have now successfully completed the exercise.

Video solution