Limit Overrun Race Conditions in Web App Penetration Testing | 2023

The most well-known type of race condition enables you to exceed some kind of limit imposed by the business logic of the application | Karthikeyan Nagaraj

Limit overrun race conditions

The most well-known type of race condition enables you to exceed some kind of limit imposed by the business logic of the application.

For example, consider an online store that lets you enter a promotional code during checkout to get a one-time discount on your order. To apply this discount, the application may perform the following high-level steps:

1. Check that you haven’t already used this code.
2. Apply the discount to the order total.
3. Update the record in the database to reflect the fact that you’ve now used this code.

If you later attempt to reuse this code, the initial checks performed at the start of the process should prevent you from doing this:

Now consider what would happen if a user who has never applied this discount code before tried to apply it twice at almost exactly the same time:

As you can see, the application transitions through a temporary sub-state; that is, a state that it enters and then exits again before request processing is complete. In this case, the sub-state begins when the server starts processing the first request, and ends when it updates the database to indicate that you’ve already used this code. This introduces a small race window during which you can repeatedly claim the discount as many times as you like.

There are many variations of this kind of attack, including:

• Redeeming a gift card multiple times
• Rating a product multiple times
• Withdrawing or transferring cash in excess of your account balance
• Reusing a single CAPTCHA solution
• Bypassing an anti-brute-force rate limit

Limit overruns are a subtype of so-called “time-of-check to time-of-use” (TOCTOU) flaws. Later in this topic, we’ll look at some examples of race condition vulnerabilities that don’t fall into either of these categories.

Detecting and exploiting limit overrun race conditions with Burp Repeater

The process of detecting and exploiting limit overrun race conditions is relatively simple. In high-level terms, all you need to do is:

1. Identify a single-use or rate-limited endpoint that has some kind of security impact or other useful purpose.
2. Issue multiple requests to this endpoint in quick succession to see if you can overrun this limit.

The primary challenge is timing the requests so that at least two race windows line up, causing a collision. This window is often just milliseconds and can be even shorter.

Even if you send all of the requests at exactly the same time, in practice there are various uncontrollable and unpredictable external factors that affect when the server processes each request and in which order.

Burp Suite 2023.9 adds powerful new capabilities to Burp Repeater that enable you to easily send a group of parallel requests in a way that greatly reduces the impact of one of these factors, namely network jitter. Burp automatically adjusts the technique it uses to suit the HTTP version supported by the server:

• For HTTP/1, it uses the classic last-byte synchronization technique.
• For HTTP/2, it uses the single-packet attack technique, first demonstrated by PortSwigger Research at Black Hat USA 2023.

The single-packet attack enables you to completely neutralize interference from network jitter by using a single TCP packet to complete 20–30 requests simultaneously.

Although you can often use just two requests to trigger an exploit, sending a large number of requests like this helps to mitigate internal latency, also known as server-side jitter. This is especially useful during the initial discovery phase.

Understanding the Complexity of Limit Overrun Race Conditions

In the ever-evolving world of web application security, understanding the intricacies of vulnerabilities is paramount. Limit Overrun Race Conditions, often referred to as “race conditions” for brevity, are a category of vulnerabilities that exploit the timing and synchronization issues within a web application’s code. These vulnerabilities are subtle, elusive, and require a keen eye to detect.

1. The Essence of Race Conditions

At its core, a race condition occurs when multiple threads or processes access shared resources concurrently, leading to unpredictable outcomes. In web applications, this typically involves multiple users or components attempting to modify or access the same data simultaneously.

2. The Dangers They Pose

Race conditions can have severe consequences. They can lead to data corruption, unauthorized access, privilege escalation, and even system crashes. Attackers often target these vulnerabilities to gain an upper hand in compromising a web application.

Exploring Types of Limit Overrun Race Conditions

To effectively address race conditions in web application penetration testing, it’s crucial to understand the various forms they can take. Here are some common types:

1. Time-of-Check to Time-of-Use (TOCTOU) Vulnerabilities

In TOCTOU vulnerabilities, an attacker manipulates the time gap between when a resource is checked and when it is used. For instance, they might exploit a brief window where the system believes a resource is secure, but it is actually vulnerable.

2. Double-Checked Locking

This race condition involves the improper use of locks in multithreaded code. Attackers can exploit this vulnerability to bypass security checks.

3. File Race Conditions

When a web application involves file operations, race conditions can occur if multiple users or processes attempt to access the same file concurrently. This can lead to data corruption or unauthorized access.

4. Session Race Conditions

In session-based web applications, attackers can exploit race conditions to manipulate user sessions, gaining unauthorized access or impersonating other users.

Mitigating Limit Overrun Race Conditions

Preventing and mitigating race conditions requires a combination of sound coding practices and rigorous testing. Here are essential steps to address this vulnerability:

1. Code Review and Testing

Thoroughly review code to identify potential race conditions. Use static analysis tools and conduct dynamic testing to simulate real-world scenarios.

2. Proper Synchronization

Implement robust synchronization mechanisms like locks, semaphores, and mutexes to control access to shared resources.

3. Input Validation

Always validate user input and sanitize data to prevent attackers from injecting malicious payloads that could trigger race conditions.

4. Rate Limiting

Implement rate limiting to restrict the number of requests a user or component can make within a specified time frame, reducing the likelihood of race conditions.

5. Session Management

Secure session handling is critical. Use strong session identifiers and implement session timeouts to minimize the window of opportunity for attackers.

Conclusion

In the complex and ever-evolving landscape of web application security, understanding and mitigating Limit Overrun Race Conditions is of paramount importance. These elusive vulnerabilities can have severe consequences, making them a prime target for attackers. By following best practices in coding, testing, and security measures, organizations can fortify their web applications against the threats posed by race conditions. Stay vigilant, and stay secure.