In a recent penetration testing engagement I happened to stumble across a interesting vulnerability that allowed for an end user to manipulate sales prices of products for a industrial supplier. This was a very interesting finding especially since the web application happened to be securely locked down besides this vulnerability. After identifying the vulnerability, we were able to change the price of a product and successfully purchase the item for the tampered price.
I thought I’d share the methodology used to find this vulnerability and how to successfully exploit this vulnerability. To keep the client anonymous, I will be utilizing PortSwigger’s labs to imitate the vulnerability in the wild.
Please, only use this for educational purposes and do not attempt to use this for nefarious reasons!!
Discovering The Vulnerability
This external assessment was going pretty rough because midway through our allowed time we did not find anything interesting. Personally, whenever I am performing any sort of recon on a web application I like to have all my requests performed be logged using Burp’s Logger++. I decided to go through my logs and see if there was anything interesting that may have not been visible to a normal user. To my surprise, there was a hidden gem!
The above HTTP requests displays that when adding the product to our cart, the quantity amount and the price of the product are being passed via parameters. This means that a user has the ability to manipulate the values of these parameters using a proxy such as Burp Suite. Before sending this request to Burp Suite’s Repeater functionality, let’s display our cart now with the original price of productId 2.
We can now send this request to Burp’s Repeater tab by pressing the buttons “Control (CTL) + r” or by turning your proxy intercept on and adding the item back to your cart again. You will be brought to a screen displaying the POST method of adding the item to your cart. Let’s attempt to change the price of the item to an arbitrary value and see if the applications accepts the new value.
After sending the new price of the BBQ Suitcase, we get a 302 response meaning that the page is attempting to redirect us to another page. After hitting the “Follow redirection” we end upback at the BBQ Suitcase page where we would normally hit the button that would add the item to the cart.
We can now go into the web application and now see the contents of our cart and see that the price that we entered previously is now being accepted. ;)
Finally, we can submit the order and see that our price has correctly been charged regardless of the BBQ Suitcase original price. We can verify this, by seeing that our store credit, which is $100 in this given example, has been changed to $96.51 since we changed the price of the item to $3.49 (100–3.49).
As shown above, user input should never be trusted!! If user input needs to be taken for whatever reason, the input needs to be checked to make sure that nothing can go wrong.
Our client however was able to identify the price change due to their internal process of having a sales person contact the customer a couple of days before the items arrive ensuring that all their business needs were met. Overall, we managed to help the client mitigate this business flaw and discover a pretty cool bug!
HAPPY HUNTING FOLKS!
