Exploiting Race Condition using Turbo Intruder

 In web security, a race condition refers to a scenario where the behaviour of a web application is influenced by the sequence or timing of events, potentially leading to unintended security vulnerabilities. This occurs when multiple processes or threads access shared resources concurrently, and the outcome depends on the order in which these operations are executed.

Table of Contents

·      Key features

·      Testing on a vulnerable application

·      Application's intended behaviour

·      Application's unintended behaviour

·      About the vulnerability

·      Conclusion

Key features

Following are the key features of the Race Condition:

·      Concurrent Access: Race conditions occur when multiple processes or threads access shared resources simultaneously in a web application. These shared resources could include database records, files, or variables stored in memory, among other crucial components.

 

·      Unpredictable Behaviour: Because of the asynchronous and parallel nature of web applications, the timing and sequence of concurrent operations can differ. As a result, this can lead to unpredictable behavior, where the outcome of an operation is affected by factors such as request timing, system load, or network latency.

Testing on a vulnerable application

To demonstrate the Race Condition, we will be using a vulnerable application and try to perform the intended application logic without any concurrent requests and then will try to perform the unintended action using multiple concurrent requests. The vulnerable application can be downloaded from here: https://github.com/projectdiscovery/php-app-race-condition

Application's intended behaviour: The application's intended logic is that the user can withdraw money from the account and the balance amount will be shown to the user. Initially the total amount is $10,000.

As per the application logic if a user withdraws $10, 80 times the leftover amount in the account should be $10,000 - ($10*80) = $9200.

This process can also be seen through the outcome of Burp Intruder by setting the concurrent requests to 1 and withdrawing the amount 80 times.

Application's unintended behaviour:

The application's unintended behaviour can be seen after multiple concurrent requests are sent using Turbo Intruder extension. The turbo intruder extension inside Burp Suite can be downloaded from the Bapp Store.

After installing the extension, the target request can be sent to the Turbo Intruder extension.

 

Inside Turbo Intruder, we will use the race-single-packet-attack.py default script however we will change the configuration as per our needs. Same action of withdrawing $10, 80 times is performed but here the concurrent requests are set as 15 and the engine is set to Engine.BURP.

After configuration is complete, click on Attack to start the attack. Observe that after 80 requests the amount which is left in the account is $9600 which is more than the desired amount.

About the vulnerability

It might seem unexpected that a web application developed in PHP, a language without native multi-threading support, could be susceptible to race condition attacks. However, they can indeed occur. This exploit is viable because web servers such as Apache handle queries asynchronously. This means that if two requests arrive almost simultaneously, they will either be executed concurrently on a multi-core CPU or interleaved by the operating system's CPU time-sharing mechanism. Therefore, instead of the expected $9980 balance after both requests are processed, the balance becomes $9990. This discrepancy arises because the second request is processed while the first one is still in progress. Although both withdrawals function correctly resulting in a total withdrawal of $20, only $10 is deducted from the balance.

 

Conclusion

In conclusion, race conditions pose a significant risk to the security and reliability of web applications. Hence, comprehensive testing and robust coding practices are imperative for effectively mitigating these vulnerabilities. The above scenario is shown keeping the concurrent requests as 1 in the Burp Intruder, since the application is of small size and lesser functionalities. In real life testing, the Turbo Intruder can prove to be a very valuable extension as it gives a feasibility on the attack configuration.