How I was able to get free ***** for months because of this bug.

Spideynati
4 min readNov 9, 2021

So,

This is my first blog, TBH I am a procrastinator (pro level), found this one weeks ago and thought waow this is an awesome bug to write a blog about but as I mentioned above that’s why writing it now maybe will complete in two days and will post it after a week or so ..🤷🏻‍♂️🤷🏻‍♂️, leave this lets talk about the bug.

So, I am a subscriber of this particular site for months now I pay monthly amount for the subscription, one day my transaction got unsuccessful, some error with the bank I guess. So since my burp-suite was open on another screen I thought why not try to trick the payment method of this particular site and I tried intercepting the request and tampering it by changing certain parameters it was so weak that I hacked it in only 5 mins or so.

So, the bug was in the site when the request was being forwarded to the monkeysite (lets call the site monkeysite). See finding the bug in payment gateway is tough (not impossible) but its always possible that you can be able to find a bug at the start when the monkeysite is transferring how much amount to be paid to the gateway or in the end by canceling the transaction and trying to make the failed request look like the successful one, this is what I did in this particular one.

In the 1.1 request you can see the transaction is unsuccessful I tried to change parameters but nothing happened since the request is of the payment gateway.

1.1

In request 1.2 as you can see I did the same thing and it worked the reason why this happened is I will tell at the end (Guess if you can it’s easy). BTW this particular request I edited into successful was in the endpoint of the payment gateway when the failure request was being forwarded to the monkeysite.

1.2

The 1.3 is the request that is generated by the monkeysite after 1.2 showing that the transaction got successful and after it I got the invoice of my payment obviously without paying it.!

1.3

Basic methodology behind this type of attacks: Always use the opposite of what failure request is about.

Example:

txn_failure = txn_success

transaction+failed = transaction+success

F = S

response 308 = response 302

response 0001 = response 0000(basic success code)

OR

You can simply see the parameters of the successful request first and simply edit the one in the failed one with the help of successful one.

So, you might think why the 1.1 worked and 1.2 didn’t its because of the checksum, the request of the payment gateway contained the checksum of the request parameters, tampering with it will give the error obviously in next request. But, the second request i.e. the endpoint one do not has the checksum to verify if the request parameters got tampered or not, that’s the main reason this bug took place in the first place.

If you are wondering no I was not paid any bounty for this, the site won’t even reply to my email what can I do there loss.!(they don’t have a bug program though but still “Hackers gonna Hack”)

That’s it that was the bug want some more tips simply google or you can always ping me (just don’t ask stupid questions though I got friends for that!)

Email: spideynati0@protonmail.com

(no I don’t use Gmail if its not needed)

--

--