Hunt Race Condition

Crown Jewel Targets

Race conditions are high-severity findings because they break financial, access control, and integrity assumptions that defenders rarely stress-test. Highest payouts come from:

• Monetary/credit systems — double-spending gift cards, coupons, referral bonuses, promotional credits, wallet balances
• Vote/reputation manipulation — upvoting the same content multiple times, gaming leaderboards or trending algorithms
• Account limits bypass — exceeding free-tier quotas, bypassing "one per user" restrictions on invites, trial activations, or API key generation
• Privilege escalation — racing role assignment or permission checks during user creation/upgrade flows
• Deletion bypass — reading or exfiltrating data during a narrow window between "marked for deletion" and "actually deleted"
• Payment flows — charging a card once but receiving multiple fulfillments

Best-paying asset types: Fintech apps, SaaS platforms with credit/subscription models, social platforms with reputation systems, e-commerce checkout flows, OAuth/SSO token endpoints.

Attack Surface Signals

URL Patterns

/vote, /upvote, /like, /favorite
/redeem, /apply-coupon, /use-code, /claim
/purchase, /checkout, /confirm-order, /pay
/transfer, /withdraw, /send-money
/invite, /referral, /accept-invite
/upgrade, /activate, /trial
/delete, /deactivate, /cancel
/follow, /subscribe

Response Headers That Signal Race-Prone Backends

X-RateLimit-*        # rate limiting exists, but may not be atomic
X-Request-Id         # each request independently tracked
No Cache-Control     # stateful ops not idempotent

JavaScript Patterns to Grep

// Single-use action buttons with client-side disable
button.disabled = true
$('#btn').prop('disabled', true)
// Optimistic UI updates (state set before server confirms)
setState({ used: true })
// Sequential async calls without locking
await useVoucher(); await deductBalance();

Tech Stack Signals

• Ruby on Rails without with_lock / lock! — ActiveRecord doesn't lock by default
• Node.js with async/await chains — non-atomic DB reads then writes
• PHP without SELECT ... FOR UPDATE — common in legacy codebases
• Microservices — inter-service calls introduce natural TOCTOU windows
• Redis counters without Lua scripts or INCR atomicity checks
• Message queues — idempotency keys often missing

Step-by-Step Hunting Methodology

1. Enumerate one-time or limited-use actions — Map every endpoint that enforces a "once per user", "limited quantity", or "deduct balance" constraint. These are your primary targets.

2. Understand the state machine — For each target action, identify: (a) what state is read, (b) what state is written, (c) what validation sits between read and write. The gap between read and write is your window.

3. Capture a clean baseline request — Perform the action once legitimately with Burp Suite intercepting. Confirm you get the expected single-use behavior (e.g., coupon marked used, vote counted once).

4. Set up parallel request tooling — Use one of:

   • Burp Suite Repeater → "Send group in parallel" (Turbo Intruder for HTTP/2 single-packet attacks)
   • Turbo Intruder with engine=Engine.BURP2 for last-byte sync
   • curl with & backgrounding
   • Python threading or asyncio with pre-built connections

5. Execute the race — Send 10–50 identical requests simultaneously. Key technique: pre-connect and buffer all requests, release the final byte of all simultaneously (single-packet attack when HTTP/2 is available).

6. Analyze responses — Look for:

   • Multiple 200 OK where only one should succeed
   • Duplicate success messages
   • Database constraint errors (signals the race worked but hit the last-line-of-defense)
   • Inconsistent response times (one fast, rest slow = serialized; all same speed = parallel processing)

7. Verify the effect — Check the actual state: Was the credit applied twice? Did the vote count increment multiple times? Is the coupon still marked unused despite two successes?

8. Determine exploitability window — Re-run with decreasing parallelism (5 requests, 3 requests, 2 requests) to understand how tight the window is and reliability of exploitation.

9. Test across account types — Sometimes the race only works for new accounts, specific subscription tiers, or under specific server load. Test varied conditions.

10. Document reproducibility — Record exact timing, number of parallel requests needed, and success rate across 5 independent attempts before reporting.

Payload & Detection Patterns

Turbo Intruder — Basic Parallel Race

# turbo_intruder_race.py
def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=1,
                           engine=Engine.BURP2)  # HTTP/2 single-packet
    for i in range(20):
        engine.queue(target.req, gate='race1')
    engine.openGate('race1')

def handleResponse(req, interesting):
    if '200' in req.status:
        table.add(req)

curl — Parallel Requests (bash)

# Fire 15 simultaneous vote/redeem requests
for i in $(seq 1 15); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST "https://target.com/api/vote" \
    -H "Cookie: session=YOUR_SESSION" \
    -H "Content-Type: application/json" \
    -d '{"report_id": "12345", "vote": "up"}' &
done
wait

Python asyncio Race

import asyncio, aiohttp

async def race_request(session, url, payload, headers):
    async with session.post(url, json=payload, headers=headers) as r:
        return await r.text()

async def main():
    url = "https://target.com/redeem"
    payload = {"code": "GIFT50"}
    headers = {"Cookie": "session=XXXXX"}
    
    async with aiohttp.ClientSession() as session:
        tasks = [race_request(session, url, payload, headers) for _ in range(20)]
        results = await asyncio.gather(*tasks)
    
    for r in results:
        print(r[:100])  # print first 100 chars of each response

asyncio.run(main())

Grep Patterns for Source Code Auditing

# Look for read-then-write without locking
grep -rn "find_by\|where.*first" --include="*.rb" | grep -v "lock"
grep -rn "SELECT.*WHERE" --include="*.php" | grep -v "FOR UPDATE"

# JavaScript async without atomicity
grep -rn "await.*get\|await.*find" --include="*.js" -A2 | grep "await.*update\|await.*save"

# Python Django ORM without select_for_update
grep -rn "\.get(\|\.filter(" --include="*.py" | grep -v "select_for_update"

HTTP/2 Single-Packet Check

# Verify target supports HTTP/2 (prerequisite for single-packet attack)
curl -sI --http2 https://target.com | grep -i "HTTP/2\|h2"

Common Root Causes

1. Check-Then-Act without atomic operations — Developer reads state (if voucher.used == false), then writes state (voucher.update(used: true)) in two separate database operations. Any thread can read the same "unused" state before either writes.

2. Missing database-level locking — Using ORM methods like find or filter instead of SELECT ... FOR UPDATE. The fix is one line but developers don't think about concurrency.

3. Optimistic concurrency without version checking — Systems increment counters or mark records without checking if the record changed since it was read.

4. Microservice TOCTOU — Service A validates eligibility, Service B executes the action. No shared atomic transaction spans both services.

5. Client-side "protection" — Developers disable the button in JavaScript after first click, assuming that prevents duplicate submissions. Server-side logic is never hardened.

6. Counter increments outside transactions — votes_count += 1; save() instead of an atomic SQL UPDATE SET votes = votes + 1 WHERE id = ?.

7. Async background jobs — Eligibility checked synchronously, fulfillment done asynchronously. A second request passes the check before the first job completes.

8. Caching without invalidation — Cached "has user voted?" check returns stale false during a cache miss window when the first write hasn't propagated yet.

Bypass Techniques

What Defenders Implement (and How to Bypass)

Defense: Per-user rate limiting

• Bypass: Rate limits are checked before the action executes. Send requests simultaneously — all pass the rate-limit check before any is counted.

Defense: Idempotency keys / unique request tokens

• Bypass: If the server generates or reuses the token, try sending parallel requests without the token. Or check if the uniqueness check itself has a race window.

Defense: Database unique constraints

• Bypass: The constraint catches duplicates after the race. The first two may both succeed before DB enforces. Look for partial fulfillment — sometimes one succeeds and one errors but both are honored.

Defense: Short time windows / expiring tokens

• Bypass: Pre-stage all requests with valid tokens. Use single-packet HTTP/2 to release all in one TCP frame — server processes them in the same scheduler slot.

Defense: Queue-based serialization

• Bypass: Multiple queues (or multiple workers consuming the same queue) can pick up duplicate messages. Test by overwhelming the queue during the window.

Defense: Application-layer mutex / locks

• Bypass: Distributed systems running multiple app servers don't share in-process locks. Send requests to the same endpoint via different CDN nodes or load-balanced servers.

Defense: "Already used" checks in application code

• Bypass: The check and the update are separate. The check passes for both racing requests before either update completes. Only an atomic UPDATE ... WHERE used=false RETURNING id truly prevents this.

Gate 0 Validation

Before writing the report, confirm all three:

1. What can the attacker DO right now? Can you demonstrate — with screenshots or logs — that the same one-time action succeeded more than once? (e.g., vote count shows +2 from one user, credit balance shows double-credit, coupon shows redeemed twice)

2. What does the victim LOSE? Is there concrete, measurable harm? Financial loss (credits issued in excess), integrity loss (manipulated rankings/votes), or security loss (access granted beyond entitlement)? "The counter went up twice" is only valid if that counter has real-world value.

3. Can it be reproduced in 10 minutes from scratch? Can you write a 20-line script, run it against a fresh test account, and reliably demonstrate the duplicate effect at least 3/5 attempts? If it requires perfect timing you cannot reliably control, the exploitability claim is weak.

Real Impact Examples

Scenario 1: Social Platform Vote Manipulation

A bug bounty platform's "popular reports" feature allowed upvotes to improve report visibility and researcher reputation scores. By sending ~15 parallel upvote requests for the same report using a single HTTP/2 connection (single-packet attack), a researcher was able to register 10–15 votes from a single account. This allowed artificial inflation of report rankings, manipulation of researcher reputation scores, and distortion of the platform's crowdsourced prioritization system — directly undermining trust in the platform's core feature for triaging vulnerability reports.

Scenario 2: Major Social Network — Duplicate Promotional Actions

On a major social network (Facebook-scale), promotional or limited-use actions — such as adding a phone number for a one-time security credit, or claiming a one-time bonus — were vulnerable to simultaneous parallel requests. An attacker could race the claim endpoint and receive the promotional benefit multiple times, causing direct financial loss to the platform and allowing fraudulent accumulation of platform currency or benefits at scale. Given the user volume, even a brief window before patching represented significant financial exposure.

Scenario 3: Cloud Infrastructure Provider — Resource Limit Bypass

A cloud hosting provider enforced limits on the number of resources (e.g., droplets, projects, or API keys) a free-tier user could create. The limit check and resource creation were non-atomic operations. By racing the creation endpoint with 20 simultaneous requests, an attacker bypassed the enforcement logic and created resources far exceeding their tier limit. This translated directly to unauthorized compute consumption, billing fraud, and abuse of infrastructure — impacting both the provider's revenue and system stability for legitimate users.

Related Skills & Chains

• hunt-business-logic — Race conditions are the "concurrency arm" of every business-logic state machine. Chain primitive: business logic (coupon/promo) + race-condition single-packet attack → coupon redeemed N times → direct financial loss.
• hunt-mfa-bypass — OTP-expiry windows and replay protection are classic race targets. Chain primitive: race + MFA-validate endpoint → bypass OTP expiry by submitting N concurrent validations within the validity window.
• hunt-ato — Race conditions on password reset, email change, and account creation enable persistent ATO. Chain primitive: race on email-change endpoint + atomic-update missing → swap victim email + read reset token before user notice.
• hunt-api-misconfig — Wallet/balance/credit endpoints without atomic UPDATE are double-spend candidates. Chain primitive: race + atomic-update missing → double-spend balance → withdraw N× user balance.
• security-arsenal — Load the Turbo Intruder single-packet template, h2.cl smuggling for atomic submit, and curl --next parallel multi-request patterns.
• triage-validation — Apply the Statistical-Sampling gate: a single anomalous response is noise; require 1 successful + N duplicate / over-quota / stale-state demonstrations with response screenshots before reporting.