Chaining Improper Authorization To Race Condition To Harvest Credit Card Details : A Bug Bounty Story

Hey Guys . Hope you are doing well .

In this post I would be covering how I ended up finding an unusual race condition at an unexpected place due to a logical flaw .

I’ll not be too much technical here Since this issue is more of a logical issue than the usual technical vulnerabilities .

So Lets call our target app as redacted.com . It was basically a shopping website that allows the user to enter personal and CC details after selecting the product of choice .

So the vulnerable URL was something like :

https://www.redacted.com/checkout/36014f0cc44343434/details/)

This presented a screen as shows .

PS : I’ve taken the screenshots from the video so please don’t mind the clarity . I’ll try to explain everything .

The above 2 screenshots depict the checkout page .

PROBLEM

I found if some error occurs on the checkout page due to some input error after the person enters his details and hit the checkout button, the same page is returned asking user to fill in correctly (Server side validation: NICE :) ) .

I copied the URL (checkout) that had the partially filled form and pasted in another browser (Different account) and Boom ! I got the same partially filled information . This is a vulnerability . But We got problems :/

Now the problem was that how do I make a exploitation scenario out of it ? The Checkout URL (https://www.redacted.com/checkout/36014f0cc44343434/details/) was a having a random string . I spent few time trying to reverse it , but ended up in failure .

One Scenario came into my mind , What If the attacker sends the checkout URL to the victim and asks him to do the checkout . Then there may be a possibility that the attacker is able to see all the information that the victim is trying to type .

But we have a problem !! The checkout page will only spit out the pre-filled information if the person has made some mistake in filling any filed . How do I do that :/

So The exploitation scenario was like :

1. The Attacker sends the Checkout URL (https://www.redacted.com/checkout/36014f0cc44343434/details/) to the victim asking him to do the checkout . (Luring him of any offer )
2. The victim starts to enter the checkout details .
3. The attacker opens up the checkout URL in his window and keeps on refreshing the page constantly .
4. The victim does some mistake (syntactical ) in entering the detail and clicks on the checkout button .
5. The error pops up and the prefilled form is shown back to the victim .
6. The attacker also now sees the prefilled form and gets away with profit . (CC details were not masked ) .

But ………….. Ehhhh . This was not satisfying . Why will the victim commit mistake in filling the form . The scenario is too much dependent on the victim . If the victim does not commit mistake the attacker will not be able to see the pre-filled form . Damn !!

So I had to find a way that was not depended on the error . I spend the next couple of hours in finding a way .

I tried CSRF to force the victim to generate error . But that was stupid as I was the only one who was giving the pre-filled information . After some hit and trail my mind poped up with a strange Idea !!!

Enter the Race Condition :

What would be the server’s reaction if instead of doing a manual browser refresh at the attacker’s end multiple times I do it in burp intruder with a good amount of threads .

So I took the Checkout URL and Fired up Burp Intruder and began intruding with NULL payloads . (100 Threads) . Meanwhile I filed up the form at the victim’s end and hit Submit button . I was eagerly waiting for something to happen at the intruder’s end and …..

We got a different response length just after submitting the URL at the intruder’s end . The response after goes to 3xx which depicts that the checkout has been done and its moving to the final page . Now lets see what have I got here in the response .

Yesssssss !!! The CC number got leaked in the response !!!!!!!! Just to add this response has all the details that the victim has entered . :)

I just made a Dirty diagram that would help in understanding the issue better ( yeah its dirty , I’ve been writing for so long :( ) :

As you can see that the The attacker began requesting the response of the checkout URL in an extremely fast multi threaded manner . As soon as the victim submits full details to the server the server caches the details and inadvertently gives the response to the attacker (that the attacker has been requesting in a multi threaded manner)that has all the information of the form . So before going to the next page (3xx) , the response is sent to the checkout URL requester (Attacker) without the need of any error .

That was pretty much all of it .

See you guys . Take care .

A big Shoutout to the Indian Bug Hunter Community !!!