Exploiting Race conditions with Nuclei

What Is a Race Condition Vulnerability?

A race condition attack happens when a computing system that’s designed to handle tasks in a specific sequence is forced to perform two or more operations simultaneously. This technique takes advantage of a time gap between the moment a service is initiated and the moment a security control takes effect. This attack, which depends on multithreaded applications, can be delivered in one of two ways: interference caused by untrusted processes (essentially a piece of code that slips into a sequence between steps of a secure programs), and interference caused by a trusted process, which may have the "same'' privileges. Without proper controls, different processes can interfere with each other. Other names used to refer to this vulnerability include Time of Check/Time of Use or TOC/TOU attacks.

Testing Race Condition Vulnerability?

Most often this bug class gets ignored as part of the testing workflow because it requires a complex setup. All the bytes for all the requests are sent at once except for the last one. This is sent together with all requests synchronizing the send event using gate mechanism as implemented in turbo-intruder.

Nuclei engine has a dedicated module to replicate this behavior with a simple YAML template. Like any other Nuclei template, you can define RAW request of your interest to test for race condition vulnerability under request block. You can also instruct the engine to use the race module by defining race: true, and race_count. This lets you define how many HTTP requests you want to send.

Here is a sample nuclei template for testing race conditions against a single POST request. You can also configure the matcher based on the expected response of a valid attempt.

Race condition chained with Multiple HTTP requests

Sometimes, a single HTTP request is not enough to complete the exploitation of race condition vulnerability. With nuclei, you can configure the template to execute a series of HTTP requests and execute all of them simultaneously.

Here is an example of a template for testing race condition that includes multiple HTTP requests: In this case, race_count will be replaced with threads. The threads count is always the same as the number of HTTP requests you are making with the template. For this example, there are three. As the template makes three HTTP requests, you can also use payloads with fuzzing to test for a race condition. You only need to make sure that the threads count is always the same as the number of HTTP requests you are making with the template.

DEMO?

We have prepared a vulnerable docker environment including nuclei template to exploit based on vulnerable code shared at https://defuse.ca/race-conditions-in-web-applications.htm

Setting up vulnerable insurance:-

Running nuclei template to exploit race condition vulnerability:-

Observe that less than $1280 were accounted for withdraw from the balance ($10 *128 requests) with a variable net gain.

For more details check the nuclei template documentation for writing templates for testing race conditions.

References:-

• https://www.veracode.com/security/race-condition
• https://defuse.ca/race-conditions-in-web-applications.htm
  

Got some questions? Feel free to tweet us to @pdnuclei or jump in our discord server to discuss more about security and automation.