Exploiting Race Conditions in Web Applications: A Write-up for the TryHackMe “Towel on the Sunbed” Room

#security #ai #cybersecurity #tutorial

Introduction
Race conditions represent a critical class of logic vulnerabilities that occur when a software program handles multiple processes or requests concurrently without proper synchronization. In web application security, this frequently manifests as a “Time-of-Check to Time-of-Use” (TOCTOU) flaw, where an application checks a condition (such as user balance or reward eligibility) and updates it later, allowing attackers to execute an action multiple times before the state is fully synchronized.
This write-up covers the walkthrough and exploitation methodology for the Towel on the Sunbed room on TryHackMe. The challenge centers around a mock cryptocurrency staking platform vulnerable to a race condition, enabling us to bypass rate-limiting and reward restrictions to capture the flag.

Reconnaissance and Enumeration
Upon deploying the lab environment, we are greeted by Ponzi Portfolio, a web application simulating a crypto asset tracking and staking interface.

Authentication: The application allows users to register an account and log in. We created a test account (123456) to access the dashboard.
Staking Rewards Feature: The dashboard features a “Staking Rewards” section that permits users to claim 50 PONZI tokens every 24 hours.
The Objective: Below the staking section lies the Whale Vault, which requires accumulating 150 PONZI tokens to unlock an exclusive reward (the flag).

Since the application restricts claims to once every 24 hours, waiting naturally for enough tokens is unfeasible. However, the room’s description — “Ponzi set his towel down for one 24-hour reward claim. He came back to find the sunbed had been ‘claimed’ three times over while he wasn’t looking” — hints directly at a concurrent execution vulnerability.

Vulnerability Analysis
When clicking the Claim Reward button, the browser dispatches a POST request to the /claim endpoint.

Using Burp Suite, we intercepted this HTTP request. The request structure is lightweight:

POST /claim HTTP/1.1
Host: 10.65.186.53:3000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: http://10.65.186.53:3000/dashboard
Origin: http://10.65.186.53:3000
Connection: keep-alive
Cookie: connect.sid=...
Content-Length: 0
The underlying application logic likely checks if the user has claimed their reward within the current period. If false, it credits 50 points and updates the database. If multiple identical requests hit the server simultaneously before the database flag updates, all of them may pass the conditional check concurrently.

Exploitation via Burp Suite Repeater
To test and exploit this behavior, we leveraged Burp Suite’s advanced group-sending capabilities in the Repeater module:

Sent the captured /claim POST request to Repeater.
Duplicated the request tab multiple times (e.g., 30 parallel requests).
Grouped these tabs together and configured the dispatch method to “Send group in parallel (last-byte sync)”. Last-byte sync ensures that Burp holds back the final bytes of each request and releases them simultaneously, maximizing concurrency at the server socket level.
Upon executing the parallel group request, the server responded to multiple concurrent threads successfully, incrementing the balance past the standard single-claim restriction.

Server Response Example:
{ "message": "Staking reward claimed successfully", "reward": 50, "newBalance": 150, "tier": "Whale", "priceSnapshot": 4.20 }