Remember this , a famous dialogue from a Bollywood movie 3 idiots. In a race the one who cross the finishing line 1st becomes 1st.
Ever thought if all the participants completes the finishing line at the same time. Sounds nice… But is it practical in a real life scenario ? That’s the interesting part.
What is race condition?
A race condition occurs when multiple threads can access shared data and they try to change it at the same time. Because the thread scheduling algorithm can swap between threads at any time, you don’t know the order in which the threads will attempt to access the shared data. Therefore, the result of the change in data is dependent on the thread scheduling algorithm, i.e. both threads are “racing” to access/change the data.
Let’s take an example to understand this scenario .
Here 2 goroutines are fired and they are provided a simple task just to initialize in a value in “value” variable and increment & print that value. Finally when both goroutines complete , the value of “counter” variable should print.
Expectations : The expected output should be
Yes , we got as expected . But wait a moment, hit the same code multiple times and observe the output.
Now we understood what exactly is the problem. Both the goroutines are trying to access the same memory location simultaneously . Although this issue can be resolved simply by adding mutexes to handle this concurrency. But here we are highly interested on how this race condition can be useful for an attacker .
Where Can I look for such scenario ?
Bug hunting is all about understanding the flow of a web application or a mobile application. The more you understand the target, the easier will be to exploit that as well.
The critical sections that can be vulnerable to such type of scenario where two or more sources tries to access the same resource. The most common attack vectors are the section which contains coupon code, invite code, or any other data that can be used only once for a particular user. well this makes sense now…..
How I found a similar bug in a bug bounty program!
So, I was looking in a public program that was present for a long time in Bugcowd. I started with the recon phase. While my recon was in background I was observing the functionalities and behavior of that web app .
There was a section on invite friends as this feature comes now in most of the companies . I was interested in what will happen if I invite some friends. They had multiple rewards for this depending upon the country .
Like there was one option for UK , whenever a user invites 3 friends and they spend 200 GBP (each) . The user who invited them will get a reward of 50GBP(pounds).
How this invite works?
while inviting I saw 2 options
- Invite through link
- Invite through coupon code
I thought let’s play with the coupon code . Here an idea came in my mind how about the friend I’ve invited hits the coupon code again and again & server accepts those requests but I can see user can hit these code only once.
Then I thought to look for race condition, but how this can help here?
Suppose I have invited 18 users so when these 18 users will spend 200GBP each (i.e 18*200 = 3600GBP) , I’ll get 50GBP for each 3 users(i.e 6*50=300GBP) .
Time to attack
Requirements :
- Two user accounts (user1 , user2)
- Turbo Intruder (BurpSuite’s plugin)
Turbo Intruder is way much powerful tool that has the ability to send 30,000 requests per sec If it is configured in that way.
For installation and usage of turbo intruder , I’ve found the perfect tutorial here : https://portswigger.net/research/turbo-intruder-embracing-the-billion-request-attack
From user1 account I took the invite coupon.
There was an option in profile if you forget to enter your invite code while signup then you also have an option to enter it afterwards.
So, I sign up with the user2 account and went to the section to enter invite code, that I’ve copied from user1 account.
Then I entered that coupon code and captured that request in Burp proxy. In the body section I can see the request like this
{“referralToken”:”invitecode”}
Double click on the invite code to select and send the request to turbo intruder
Then I could see the request like this
POST /gateway/v1/virality/guests/18343692/referrals HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0
.
.
Cookie: {cookie_value}
{“referralToken”:”%s”}
As we can notice, turbo intruder set the selected invite code as %s
Turbo intruder supports the python script to configure and run the request as we want. I hit the script in script section.
Run the attack
We can see there are around multiple responses that has 200 status code and rest 40x
Now to confirm if these requests are accepted by the server and invitation reflects in the user1’s profile. I switched in the user1 account and checked my invited users .
Yes, the race condition vulnerability was exploited successfully.
Now the Impact
As we can see user1 has invited user2 multiple times (Let’s say 18) . So when user2 will spend 200GBP , here all the 18users are same (u1,u2…u18=user2) user 1 will get 50*6=300GBP(i.e 50*{total_invite/3}).
