32.2.5 Quota reset timing attacks

The Principle of Reset Synchronization

At its core, this attack vector exploits the discrete nature of fixed-window rate limiting schemes. These systems typically define a quota (e.g., 100 requests) over a fixed interval (e.g., 60 seconds). When the interval ends, the counter resets to zero. This reset is not gradual; it is an instantaneous event.

A timing attack doesn’t try to break the limit during the active window. Instead, it aims to deliver a volley of requests in the tiny slice of time that bridges two consecutive windows. You exhaust the quota for Window A right before it ends, and then, at the exact millisecond Window B begins, you send another full quota’s worth of requests. To the system, this appears as two compliant sets of requests in two separate windows. To the target application, it feels like a sudden, high-volume burst that can overwhelm downstream resources or achieve an objective that relies on rapid, successive actions.

Primary Attack Vectors

Executing this attack requires precise timing and an understanding of the target’s reset mechanism. The approach varies based on how predictable the reset event is.

Vector 1: Fixed Interval Synchronization

This is the most straightforward scenario. The API enforces a quota that resets at a predictable, absolute time, such as the top of every minute (HH:MM:00) or hour. Your task is to synchronize your client to this server-side clock.

The attack sequence is as follows:

1. Determine the rate limit (e.g., 100 requests/minute).
2. Exhaust the quota for the current minute, finishing your last request at, for example, second :59.
3. Sleep your script until the exact moment the next minute begins.
4. Immediately launch another burst of 100 requests within the first few seconds of the new minute.

This effectively delivers 200 requests in a timeframe of only a few seconds, bypassing the intended rate of 100 per 60 seconds.

# Pseudocode for a fixed interval timing attack
import time
import threading

API_ENDPOINT = "https://api.example.com/v1/process"
QUOTA = 100

def make_request():
    # send_request_to(API_ENDPOINT)
    pass

while True:
    # Wait for the next minute to start
    current_time = time.localtime()
    seconds_to_wait = 60 - current_time.tm_sec
    time.sleep(seconds_to_wait)

    # Launch burst of requests using threads for concurrency
    threads = []
    for _ in range(QUOTA):
        thread = threading.Thread(target=make_request)
        threads.append(thread)
        thread.start()
    
    for thread in threads:
        thread.join()
    
    print(f"Burst of {QUOTA} requests sent at {time.strftime('%H:%M:%S')}")

Vector 2: Discovering the Reset Window

What if the reset doesn’t happen at a clean :00? It might be based on the timestamp of the *first* request in a window. In this case, you must first probe the system to discover its reset behavior.

The discovery process involves:

1. Make a single request to start the clock. Record the timestamp.
2. Immediately exhaust the rest of your quota.
3. Wait for slightly less than the window duration (e.g., 59 seconds for a 1-minute window).
4. Begin sending single probe requests at high frequency (e.g., every 50ms).
5. The first probe that succeeds reveals the exact moment the quota reset. You can now use this offset to synchronize future attacks.

This turns a black-box timing mechanism into a predictable one that you can exploit with the same bursting technique as in the fixed interval scenario.

Complications and Defensive Countermeasures

While powerful, these attacks are not foolproof. Network latency, clock drift between your client and the server, and defensive measures can all interfere with execution.

As a red teamer, your objective is to identify systems that rely on naive fixed-window counters. The presence of such a mechanism is a strong indicator of a brittle rate-limiting architecture that is vulnerable to resource exhaustion or abuse through carefully timed request bursts.