Lab: Single-endpoint race conditions

Predict a potential collision

1. Log in and attempt to change your email to anything@exploit-<YOUR-EXPLOIT-SERVER-ID>.exploit-server.net. Observe that a confirmation email is sent to your intended new address, and you're prompted to click a link containing a unique token to confirm the change.

2. Complete the process and confirm that your email address has been updated on your account page.

3. Try submitting two different @exploit-<YOUR-EXPLOIT-SERVER-ID>.exploit-server.net email addresses in succession, then go to the email client.

4. Notice that if you try to use the first confirmation link you received, this is no longer valid. From this, you can infer that the website only stores one pending email address at a time. As submitting a new email address edits this entry in the database rather than appending to it, there is potential for a collision.

Benchmark the behavior

1. Send the POST /my-account/change-email request to Repeater.

2. In Repeater, add the new tab to a group. For details on how to do this, see Creating a new tab group.

3. Right-click the grouped tab, then select Duplicate tab. Create 19 duplicate tabs. The new tabs are automatically added to the group.

4. In each tab, modify the first part of the email address so that it is unique to each request, for example, test1@exploit-<YOUR-EXPLOIT-SERVER-ID>.exploit-server.net, test2@..., test3@... and so on.

5. Send the group of requests in sequence over separate connections. For details on how to do this, see Sending requests in sequence.

6. Go back to the email client and observe that you have received a single confirmation email for each of the email change requests.

Probe for clues

1. In Repeater, send the group of requests again, but this time in parallel, effectively attempting to change the pending email address to multiple different values at the same time. For details on how to do this, see Sending requests in parallel.

2. Go to the email client and study the new set of confirmation emails you've received. Notice that, this time, the recipient address doesn't always match the pending new email address.

3. Consider that there may be a race window between when the website:

   1. Kicks off a task that eventually sends an email to the provided address.
   2. Retrieves data from the database and uses this to render the email template.

4. Deduce that when a parallel request changes the pending email address stored in the database during this window, this results in confirmation emails being sent to the wrong address.

Prove the concept

1. In Repeater, create a new group containing two copies of the POST /my-account/change-email request.

2. Change the email parameter of one request to anything@exploit-<YOUR-EXPLOIT-SERVER-ID>.exploit-server.net.

3. Change the email parameter of the other request to carlos@ginandjuice.shop.

4. Send the requests in parallel.

5. Check your inbox:

   • If you received a confirmation email in which the address in the body matches your own address, resend the requests in parallel and try again.
   • If you received a confirmation email in which the address in the body is carlos@ginandjuice.shop, click the confirmation link to update your address accordingly.

6. Go to your account page and notice that you now see a link for accessing the admin panel.

7. Visit the admin panel and delete the user carlos to solve the lab.