Hello everyone,
Thank you for showing a lot of support and appreciation for my first write-up. Please check it out if you haven’t yet “https://twitter.com/VasuYadaav/status/1310161326157762562?s=20”.
One of the first bugs that I had found once I started bounty hunting was a parameter tampering bug on an e-commerce website. This write-up will share similar features, focusing on various payment gateway vulnerabilities.
1. Exploiting the “Add Money” Wallet Feature.
I had tested the app and found several account takeover vulnerabilities, but I wanted to try to attempt to exploit a financial feature. I tried tampering with the order price by changing the amount, quantity, etc but it did not work.
Then I saw an option to add money in my wallet:
I didn’t expect to be able to exploit the “Add Money” feature. I tried adding 1 Rupee to my wallet, I selected payment methods and then I paid 1 Rupee. At the time of intercepting the request, I saw a POST request to the callback endpoint.
I quickly sent the POST request to repeater and navigated to my wallet. It had 1 Rupee, as expected. I again forwarded the same POST request from repeater and the status response was 200 OK and I received a message that 1 Rupee has been added. WTF no way!
I wanted to see if I could take this vulnerability to the next level. I changed the amount to 10K. It worked. I ended up with 3,000,000+ Rupees in my Wallet.
I bet that I had the same thought as you might have had.
“Oh man, he must have bought something expensive…I know what I could do with this money.”
You know what I did? I bought an Air Conditioner.
Now I don’t have to worry about the temperature in the Summer. HAHA, I am just kidding. I did not place the order, but I did mess with my friends by sending screenshots.
I believe that everyone should do the ethical thing. If you were to find a vulnerability like this, make sure you report it to the company. Don’t expect anything though, Indian Companies don’t know how to appreciate a hacker’s efforts.
When they deducted the 3 Million, I was like :/
2. Modifying Item Prices through Response Manipulation
Many people do not run into this scenario often, but it was unique! I’ve only seen this vulnerability once.
The website allowed the application of coupon codes for discounts. This is what the request looked liked:
When I intercepted the POST request to apply the coupon this is what I saw:
Normally, parameter tampering through response manipulation doesn’t work for me. When I tried to change the final amount it didn’t work.
Instead, I added a cheap item and then applied the Coupon Code, copying the entire response. I then removed that Item and added an expensive one and applied the coupon, replacing it’s response with the previous one. The whole order bill successfully changed, it worked!
Proof via the order confirmation email:
3. Exploiting Item Quantity for Price Modification
It’s been noted that more secure website don’t typically utilize the quantities parameter. Even though it’s rare to see, it can possibly be exploited.
While I was testing an e-commerce application, I attempted parameter tampering by changing the quantity from 1 to -1 and I forwarding the request to the server.
OK, but how exactly would that work?
The total price given in the Order Summary panel is actually calculated by multiplying the “dealid” parameter by the “qty” parameter. This resulted in a negative Order Summary.
The damage is now done, but I was still not able to place the order. The negative total prevented me from doing so. The fix?
I added another item to my cart and the -175.00 was deducted from the price of the other item. Resulting in a checkout cost of $264.00
($439.00-$175.00 = $264.00)
Essentially, I could now get free items.
Here’s another tip:
If the Company is aware of IDOR vulnerabilities, they may attempt to block a negative quantity. This isn’t the best fix because you can attempt to bypass by changing the Quantity (“qty”) parameter to 0.5, resulting in half-off of the total price.
4. Abusing Encoding to Modify Prices
Occasionally, Software Engineers will use encoding to define a product price. Encoding is never a good method of preventing exploitation it. Software Engineers may not think of the potential of a threat actor decoding and abusing the function.
I found this vulnerability while I was testing against a company that sells Domain Names. The company was using encoding to define the cost of purchasing a domain.
Easy. I captured the request of the cheaper domain, copied the “amount” parameter’s encoded value, and replaced a more expensive domain’s “amount” value with the value of the cheaper domain.
5. Other Indirect Object Reference Possibilities
There are many ways to exploit Web Application logic to tamper with parameter values:
1.Changing Price Parameter
In several instances you can tamper with the “price” parameter simply by changing the value of parameter. This will only work if price validation occurs on the client-side and not the server-side.
2. Changing Shipping Price
I once was able to change the shipping price by tampering with the shipping parameter, and changing it to a negative amount. It also helped deduct from the total order price.
3. Race condition on Coupon Codes
If a coupon code is not invalidated on use, a threat actor can apply the same coupon code multiple times, resulting in a much lower price. You can use turbo intruder for checking Race conditions.
As you can see — a lot of damage can be done with Indirect Object Reference Vulnerabilities. If you know of any other vulnerabilities like this, please drop a comment.
Thank you for reading. If you liked this write-up, please like, comment or follow me on Twitter/LinkedIn/Medium.
Your support inspires me to write!
If you have any questions, please contact me:
Twitter-”https://twitter.com/VasuYadaav”
Linkedin-”https://www.linkedin.com/in/vasu-yadav-82ba701a0/”
Thanks to John-”https://twitter.com/johnjhacking” for the edits :) .
