One of the least known vulnerabilities among the top vulnerabilities is Race Condition. Usually, resources are shared in an application to different processes to access. But, there is a high risk involved here. Let’s look more at them with some examples.
This vulnerability occurs mostly in multi-threaded applications when more than one thread is allocated to access one shared resource TOCTOU [Time of check and Time of Use]. Consider thread 1 is accessing the resource and updating the value. Same time thread 2 tries to access the same resource and update. It will result in TOCTOU. There should be a sequence given to the threads in order to make no harm to the system.
What if both the thread’s process at the same time? With an example, we’ll see.
Also Read : What is Threat Intelligence – Importance , CTI Lifecycle & Pyramid of Pain
Mobile data recharge should be a classic example. The order of recharge is as follows once the request is submitted to the payment gateway provider:
- Payment gateway receives request to recharge the x number for amount 500.
- Payment gateway sends OTP to customer bank linked mobile number to access the account.
- Once OTP is submitted, Payment gateway system should first check for sufficient balance in the account.
- After that sum of 500 should be debited from the account and credit it to the data provider.
- Then data provider confirm the payment receive notification from payment gateway system and complete the customer recharge process.
If there is a change in the sequence on step 4 and step 5, then it will result in a race condition.
In Step 4 and step 5, two threads are allocated to do the process.
Thread 1 has to check the account for sufficient balance.
Thread 2 has to debit the requested amount from the account.
Now, due to multiple threading if two threads process at the same time then it will result in an issue. If Thread 2 debits the required amount 500 from the account first and then Thread 1 tries to check the account balance. It will return the request back to the customer saying that insufficient balance. You will think about how it is possible for threads sequence change.
As we are discussing HTTP protocol attacks here, we will look at that focus. Nowadays servers and web frameworks are built-in high efficient to carry multiple requests at a time. If the client clicks multiple submits, then this may issue may occur.
There are some resources to test it manually in a testing environment. But, it is hard to set up and test.
Race conditions attacks can lead to serious data leaks and attackers who studied the system well can even grant access to them in compromising the server/services. Granting access to sensitive data can bring a big impact on business loss. This small misconfiguration has lead to a big attack on Citibank.
Geeks will know a workaround for this multithreading. They will implement a lock mechanism while one thread is accessing the file. This way the thread can’t do any modification. But, what about more thread 1 requests that comes in. Yes, this attack is carried in such a way only. This attack occurs when a check and open process is submitted where no lock can be done during this phase. So, locks created during this time can be ignored/bypassed by malicious processes. A good attacker who has well-known information on a system can use this attack to gain more.
Also Read: Soc Interview Questions and Answers – CYBER SECURITY ANALYST
Prevention:
- Try to avoid multiple shares first if it’s not going to cause business slow down.
- Synchronization of thread can be used.
- Using Insert statement over update statement should do good.
- Kernel level file locking can be used( windows: flock and linux: lockf)
- To avoid multiple requests at same time, csrf tokens can be used in web servers as validations. Were web server won’t process until right token matches. But, locking in right way should work fine as these are extra secure steps.