Race Condition Bug In Web App: A Use Case
Hey guys
Today I am going to write about a specific vulnerability that i found in some of the web applications I came across .
The vulnerability is race condition .
Background
Just to give a brief background about what actually a race condition is . A race condition occurs when multiple threads simultaneously access the same shared code/resource without locking or synchronization . This may result in inconsistency of the output. While developing the application the developer things that the concurrency is managed by the server itself while the server guys think that the devs would be responsible for dealing with concureent thread execution . So its like a typical IT company situation . 😁
Following diagram shows the execution of processes over the same shared resource .
Source : https://securingtomorrow.mcafee.com/technical-how-to/testing-race-conditions-web-applications/
A theoretical example
Citing a race condition example directly from Owasp
Race conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of other events. In a web application environment, where multiple requests can be processed at a given time, developers may leave concurrency to be handled by the framework, server, or programming language. The following simplified example illustrates a potential concurrency problem in a transaction web application and relates to a joint savings account in which both users (threads) are logged into the same account and attempting a transfer.
Account A has 100 credits.
Account B has 100 credits.
Both User 1 and User 2 want to transfer 10 credits from Account A to Account B. If the transaction was correct the outcome should be:
Account A has 80 credits.
Account B has 120 credits.
However, due to concurrency issues, the following result could be obtained:
User 1 checks the value of Account A (=100 credits)
User 2 checks the value of Account A (=100 credits)
User 2 takes 10 credits from Account A (=90 credits) and put it in Account B (=110 credits)
User 1 takes 10 credits from Account A (Still believed to contain 100 credits) (=90 credits) and puts it into Account B (=120 credits).
Result: Account A has 90 credits.
Account B has 120 credits.
Bug That I found
While there were many race condition bugs that I found which were pretty straight forward to exploit but I would be discussing about one specific bug that would give you an overview as to where to search for these kinda bugs and what all techniques you can use if you are haulted somewhere .
Accessing multiple consoles by free user
So there was this site that provides free consoles to the users and some limited space and bandwidth . It had 3 tiers of accounts . A free account , and 2 paid accounts having different set of benefits .
One restriction of the free account was the no. of consoles the user can create . It was limited to 2 consoles / user .
When you create a console a get request to the creation of the console was sent .At seeing this i thought would it be possible for the attacker to bypass this limited no. of consoles .
I fired up the intruder with maximum possible no. of threads and started to intrude the GET request (Using Null payloads ) to see what the server will behave .
Unfortunately this didn’t worked well . I was getting valid response for the first two requests . Then after that I started getting fixed length responses saying that the console limit is reached .
Now the problem with race condition bugs is that its not executed in one go . It depends on various types of factors like current no. of threads on the server , the load on the server , your own internet speed and other factors .
I tried shooting that request multiple times with over 100 threads but I got the same reply from the server . (Only two consoles were created ) .
Then I tried the following workaround :
I tried simulating the same attack but this time I removed one of the console manually from the UI while the threads were being executed .
As you can see in the following screenshot that 3 requests got the same response . So we successfully bypassed the console limit of the free account .
Finally
So the key factors that are to be kept in mind are:
- Race condition bugs are mostly on those endpoints which deal with adding/removing/changing of a particular resource .
- They may /may not be replicated on one go . Try again and again .
- The best use case is to test is by executing parallel threads and making changes on the particular resource at the same time . There are higher chances you can get it executed .
- Ideally you should shoot up 100+ threads (If you are testing in burp).
Thanks for reading ! Have a great day :)
