SKILL: Race Conditions

Metadata

• Skill Name: race-condition
• Folder: offensive-race-condition
• Source: https://github.com/SnailSploit/offensive-checklist/blob/main/race-condition.md

Description

Race condition (TOCTOU) testing checklist: identifying timing windows, Burp Suite Turbo Intruder, Last-Byte sync technique, rate limit bypass, double-spend attacks, and concurrent request exploitation. Use for web app race condition testing or bug bounty time-of-check-to-time-of-use bugs.

Trigger Phrases

Use this skill when the conversation involves any of: race condition, TOCTOU, timing attack, Turbo Intruder, last-byte sync, rate limit bypass, double spend, concurrent request, race window, time of check, time of use

Instructions for Claude

When this skill is active:

1. Load and apply the full methodology below as your operational checklist
2. Follow steps in order unless the user specifies otherwise
3. For each technique, consider applicability to the current target/context
4. Track which checklist items have been completed
5. Suggest next steps based on findings

Full Methodology

Race Conditions

Shortcut

• Spot the features prone to race conditions in the target application and copy the corresponding requests.
• Send multiple of these critical requests to the server simultaneously. You should craft requests that should be allowed once but not allowed multiple times.
• Check the results to see if your attack has succeeded. And try to execute the attack multiple times to maximize the chance of success.
• Consider the impact of the race condition you just found.

Mechanisms

Race conditions occur when the behavior of a system depends on the relative timing or sequence of events that can happen in different orders. In web application security, race conditions happen when multiple concurrent processes or threads access and manipulate the same resource simultaneously without proper synchronization.

sequenceDiagram
    participant Thread1 as Thread 1
    participant Resource
    participant Thread2 as Thread 2

    Thread1->>Resource: Read value (100)
    Thread2->>Resource: Read value (100)
    Thread1->>Thread1: Calculate new value (100-10=90)
    Thread2->>Thread2: Calculate new value (100-10=90)
    Thread1->>Resource: Write new value (90)
    Thread2->>Resource: Write new value (90)
    Note over Resource: Expected final value: 80<br/>Actual final value: 90

A race condition becomes a security vulnerability when it affects security controls or business logic. The critical types include:

• Time-of-Check to Time-of-Use (TOCTOU): When a check is performed, but circumstances change before the result of the check is used
• Read-Modify-Write: When multiple processes read, modify, and write back a shared resource without coordination
• Thread Safety Issues: When multithreaded applications improperly handle shared resources
• Resource Allocation Races: Competition for limited resources like database connections or memory

graph TD
    subgraph "Common Race Condition Types"
    A[Race Conditions] --> B[TOCTOU]
    A --> C[Read-Modify-Write]
    A --> D[Thread Safety Issues]
    A --> E[Resource Allocation]

    B --> B1["Check balance, then debit"]
    C --> C1["Update counter or balance"]
    D --> D1["Shared cache or session data"]
    E --> E1["Limited coupon or inventory"]
    end

Common vulnerable scenarios include:

• Account Balance Manipulation: Making multiple withdrawals/transfers simultaneously
• Coupon/Promotion Code Reuse: Using a single-use code multiple times
• File Upload Processing: Uploading and accessing temporary files before validation completes
• Registration Processes: Creating multiple accounts with the same unique identifier
• Token Verification: Using authentication tokens multiple times before they're invalidated

Hunt

Identifying Race Condition Vulnerabilities

Target Functionality Selection

Focus on features handling state changes, limited resources, or critical operations:

• Financial Transactions: Fund transfers, withdrawals, purchases
• Inventory Systems: Stock allocation, reservation systems
• Coupon/Points Systems: Redeeming coupons, points, or rewards
• Voting/Rating Systems: Likes, upvotes, downvotes, polls
• Membership/Subscription Actions: Inviting users, joining/leaving groups, following/unfollowing users
• Registration Systems: Account creation with unique attributes
• Resource Management: Uploading, processing, or accessing resources
• Rate-Limited Actions: Password resets, login attempts, API endpoints with usage limits

Testing Prerequisites

1. Tools for sending parallel requests:

   • Burp Suite Turbo Intruder or Repeater (multi-threaded)
   • Custom scripts with threading capabilities
   • Race condition testing frameworks (e.g., Racepwn)

2. Request capturing and analysis capabilities:

   • HTTP proxy for intercepting and modifying traffic
   • Response analysis tools for detecting race-related anomalies

3. Network Proximity: Consider the physical or network location of your testing infrastructure relative to the target server. Minimizing latency (e.g., using a VPS in the same region/provider as the target) can significantly increase the chances of winning a race condition.

Testing Methodology

flowchart TD
    A[Race Condition Testing] --> B[Baseline Analysis]
    A --> C[Race Condition Detection]
    A --> D[Timing Manipulation]
    A --> E[Proof of Concept]

    B --> B1[Identify state-changing operations]
    B --> B2[Document normal transaction flow]

    C --> C1[Send identical requests simultaneously]
    C --> C2[Observe state changes]

    D --> D1[Identify critical timing windows]
    D --> D2[Vary delays between requests]

    E --> E1[Create reproducible exploit]
    E --> E2[Document impact scenarios]

1. Baseline Behavior Analysis:

   • Identify state-changing operations
   • Understand normal request/response patterns
   • Document application's standard transaction flow

2. Race Condition Detection:

   • Send identical requests simultaneously (10-100 threads)
   • Observe effects on application state
   • Look for anomalies in responses or state changes

3. Timing Manipulation:

   • Identify critical timing windows
   • Target synchronization points
   • Test with varying delays between requests

Advanced Testing Techniques

API-Based Race Condition Testing

1. Identify stateful API endpoints
2. Create automated scripts for parallel API requests:

import requests
import threading

def make_request():
    requests.post('https://target.com/api/redeem',
                  json={'coupon_code': 'ONCE123'},
                  headers={'Authorization': 'Bearer token'})

threads = []
for _ in range(20):
    t = threading.Thread(target=make_request)
    threads.append(t)
    t.start()

for t in threads:
    t.join()

Transaction-Based Race Condition Testing

1. Identify multi-step transactions
2. Find the critical state change requests
3. Execute the final step in parallel before state updates propagate:

   Step 1: Start purchase (single request)
   Step 2: Apply coupon (single request)
   Step 3: Send 20 simultaneous "confirm order" requests
   

Thread Synchronization Testing

Create coordinated attacks that target specific timing windows:

import requests
import threading
import time

start_gate = threading.Event()

def synchronized_request():
    start_gate.wait()  # All threads wait here until flag is set
    requests.post('https://target.com/api/withdraw',
                  json={'amount': '100'},
                  headers={'Authorization': 'Bearer token'})

threads = []
for _ in range(50):
    t = threading.Thread(target=synchronized_request)
    t.daemon = True
    threads.append(t)
    t.start()

# Release all threads simultaneously
time.sleep(2)  # Ensure all threads are waiting
start_gate.set()

Network-Level Timing