Race Condition On Everywhere

source: wallarm

WHAT IS RACE CONDITION

Race conditions are vulnerabilities that appear in webs that limit the number of times you can perform an action.

For example, let’s think of a playground that has a swing game, but this time there is a vulnerability that makes the time limit rule not applied properly.

Imagine there are two children who want to use the swing at the same time. They compete to get the first turn. However, there is no monitoring mechanism that ensures that only one child can use the swing at a time. This creates a race condition vulnerability in the playground.

Now, let’s apply this to a website that has a feature that limits the number of actions that can be performed. For example, there is a website where users are given a daily quota to perform certain actions, such as sending messages or uploading files.

However, in a web implementation that is prone to race conditions, there is no security mechanism that ensures that the limit is applied correctly. If two or more concurrent users attempt to exceed the quota limit quickly, they may be able to do so because there is no proper synchronization to control access and quota updates.

This is similar to children on a playground racing to use a swing simultaneously without clear rules to organize turns. As a result, quota restrictions that should govern the number of actions that can be performed at one time can be violated, allowing users to perform more actions than they should.

In these cases, race condition vulnerabilities on the web can be exploited by irresponsible users or attackers to perform excessive actions, unfairly consume resources, or manipulate data in unintended ways.

To prevent race condition vulnerabilities, the web should implement proper synchronization mechanisms, such as locking or semaphores, to ensure that only one user can access and modify quota limits at a time. This will avoid a race between users and ensure that action limits are applied correctly and fairly.

PRACTICAL STUDY CASE RACE CONDITION

I will provide a study case of a race condition vulnerability that I encountered in a bug bounty program. so in the first study case I encountered it in one of the well-known platforms for uploading our journals let’s call it redacted.com

STUDY CASE 1 | Race Condition Lead To Get Unlimited Likes

So, I found a race condition vulnerability where we can affect the number of likes of a post, this vulnerability can affect how the algorithm works. because they have features where when our post has the most likes it will automatically be at the top recommendation.

Steps To Reproduce

go to a post https://redacted.com/post/test-1then try to give them likes and intercept with burpsuitesoutput

3. send to intruder and set positions like this

output

4. set payloads as null payloads and set to 20. and then start attack and see response on your likes.

NOTE: You can perform this attack on any target that has likes, whistlists, etc.

BAB 2 | Race Condition Lead To Bypass Batas Maksimal Peminjaman Buku

I found this vulnerability when I tried to borrow a book at one of the libraries, so let’s call it https://perpustakaan.redacted.go.id. they have a feature that limits each loan and the maximum limit of borrowing books is 2. However, we can bypass this maximum loan limit through a race condition vulnerability.

Steps To Reproduce

go to the post of a book we want to borrowthen try to borrow 3 books and you will get a warning.

3. then click the book we want to borrow back and intercept with burpsuite

output

4. send to intruder and set positions like this

output

5. set payloads as null payloads and set to 20 and then start attacks

6. see response

Note : if you find a feature has a maximum limit try to test the vulnerability race condition.