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.
yaml
1id: race-condition-testing
2
3info:
4 name: Race condition testing
5 author: pdteam
6 severity: info
7
8requests:
9 - raw:
10 - |
11 POST /coupons HTTP/1.1
12 Host: {{Hostname}}
13 Pragma: no-cache
14 Cache-Control: no-cache, no-transform
15 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
16
17 promo_code=20OFF
18
19 race: true
20 race_count: 10
21
22 matchers:
23 - type: status
24 part: header
25 status:
26 - 200
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.
yaml
1id: race-condition-testing
2
3info:
4 name: Race condition testing with multiple requests
5 author: pdteam
6 severity: info
7
8requests:
9 - raw:
10 - |
11 POST / HTTP/1.1
12 Pragma: no-cache
13 Host: {{Hostname}}
14 Cache-Control: no-cache, no-transform
15 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
16
17 id=1
18
19 - |
20 POST / HTTP/1.1
21 Pragma: no-cache
22 Host: {{Hostname}}
23 Cache-Control: no-cache, no-transform
24 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
25
26 id=2
27
28 - |
29 POST / HTTP/1.1
30 Pragma: no-cache
31 Host: {{Hostname}}
32 Cache-Control: no-cache, no-transform
33 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
34
35 id=3
36
37 threads: 3
38 race: true
39
40 matchers:
41 - type: status
42 status:
43 - 200
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:-
bash
1git clone https://github.com/projectdiscovery/php-app-race-condition.git
2cd php-app-race-condition
3docker-compose up
Running nuclei template to exploit race condition vulnerability:-
bash
1echo http://localhost | nuclei -t race.yaml
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:-
Got some questions? Feel free to tweet us to @pdnuclei or jump in our discord server to discuss more about security and automation.