Race Condition – Portswigger Lab 2: Bypassing rate limits via race conditions

Introduction

In this blog, we demonstrate how race conditions can be exploited to bypass server-side rate limits, using a PortSwigger lab designed to simulate such a vulnerability. Although the application enforces a limit on password reset attempts, it fails to handle simultaneous requests correctly. By sending multiple reset requests in parallel, we exploit this flaw to reset a victim’s password, ultimately gaining unauthorized access. This showcases how poorly implemented concurrency controls can lead to serious security risks.

Challenges

1. Work out how to exploit the race condition to bypass the rate limit.
2. Successfully brute-force the password for the user carlos.
3. Log in and access the admin panel.
4. Delete the user carlos.

Walkthrough

Step 1: We were challenged to access the admin panel using the Carlos account. We attempted to log in with the password provided in the lab description, but the application enforced a rate limit after 3 to 4 incorrect attempts, blocking further login tries.

Step 2: We intercepted the login request and sent it to the Intruder to exploit the race condition and discover Carlos’s password. Before launching the attack, we dropped all the initial requests to capture a valid CSRF token required for successful authentication.

Step 3: We replaced the username from wiener to carlos, added the password parameter, and pasted all the payloads provided in the lab description into the payload section.

Step 4: In the Resource Pool section, we set the concurrent request limit to 30—matching the number of payloads—so all requests are sent simultaneously to exploit the login race condition. Then, we started the attack.

Step 5: After sending all 30 requests simultaneously, we reviewed the responses to identify a successful login. A 302 status code indicates a successful attempt, revealing that Carlos’s password is 123321.

Step 6: After successfully logging in as Carlos, we navigated to the admin panel as instructed in the lab.

Step 7: We successfully accessed the user list in the admin panel, but we chose not to delete the user Carlos at this stage.

 

CASE 2

Lets solve the lab with Turbo intruder

Step 1: First we need to install it from BApp Store

Step 2: Select the password parameter in the login request, then go to Action > Extensions > Turbo Intruder > Send to Turbo Intruder to forward the request for race condition testing.

Step 3: We selected the examples/race-single-packet-attack.py template from the drop-down menu, pasted the script provided in the lab description, and launched the attack.

Step 4: After the script runs successfully, we check for a 302 response to find Carlos’s new password. This happens because resetting the lab before launching the Turbo Intruder attack ensures a fresh state, allowing the password reset to take effect properly.

Step 5: We successfully log in as Carlos using his new password and proceed to delete the Carlos user, following the lab instructions.

Step 6: Finally, the lab is successfully completed.

 

Note: You don’t always need fancy tools to perform attacks; often, customizing existing ones is enough. However, it’s important to keep learning about new tools to stay effective.