Logic Loopholes: The Fun Flaws

Hello, my fellow ingenious hackers! Your friendly neighborhood 4li is back with a bag full of intriguing vulnerabilities. My latest obsession is business logic vulnerabilities, and I’ve unearthed a few juicy ones in a target that I’ll be sharing with you in this write-up.

You see, university life and studies have been keeping me rather busy these days. But fear not! I’ve been stealing moments here and there to poke and prod at my target, an e-commerce website. The website is a veritable Pandora’s box of functionalities, and boy, have I had fun exploring them! I’ll give you a quick tour of the website and then we’ll dive deep into the vulnerabilities I’ve discovered.

Picture this: a website where any user can register a store of their own. It’s like having your personal mini-mall! But, hold your horses, the store needs an approval stamp from the website’s administration. Once approved, the user can list products (all virtual, mind you!) for sale. We’re talking accounts, services like boosting likes, members, both fake and real, and a whole lot more. For some services, like account purchases, the buyer can directly download a file containing the username and password for immediate use. However, for other services like boosting views, the user needs to open a ticket to send information such as the post link.

Now, hold on to your seats, folks. It’s time to dive into the vulnerabilities.

But, hold on! If you haven’t read the first write-up yet, do yourself a favor and read it here. Trust me, it’s a good one! :D ❤

The first vulnerability was like a trail of breadcrumbs that led me to a surprising discovery. To leave a comment on any store, one has to make at least one purchase. I charged up my account, made a purchase, and voila, the comment feature was now my playground. I tried stored XSS, but no dice. But then, I had a brainwave. I manipulated the HTTP request cookies with a second account and sent the request. And guess what? The comment was posted from the second account, which had made no purchases.

You might be wondering, where’s the fire? While it’s not a blazing inferno, it could lead to a store posting fake negative comments to tarnish a competitor’s reputation or a scammer posting a string of positive comments for their own store. The net result? The entire platform’s credibility takes a hit.

This vulnerability was hiding in plain sight! The feature for sending messages to stores was supposed to be a one-way street, only users could initiate conversations. But by tweaking the HTTP request to start a conversation on behalf of the store and changing the recipient ID to the user’s ID, it was like a secret backdoor into the conversation from the store’s side. This loophole allowed stores to send promotional messages and spam to users by creating a second store (which didn’t need approval), leading to a potential user uprising on the platform.

For this one, I had to sweet-talk the administration to get my store approved. I added a product for sale and bought it with my second account, all in the name of research. After a bit of exploration, I found nothing. So, I decided to get a refund to replenish my second account’s balance. That’s when lightning struck. I sent an HTTP request for a refund using the cookies of the second account, which was the buyer. BOOM! My balance was restored! I pinched myself. Was this for real? Such a vulnerability in an endpoint? I tested it again, and yes, it was real. All you needed were the price and purchase ID parameters, both of which, ironically, could be easily guessed by the buyer. This was a ticking time bomb! An attacker could buy any product, receive it, and then request a refund for themselves. While writing the report, another test popped into my mind. I sent the request with an account that was neither a buyer nor a seller, and it was still vulnerable. It was like being Robin Hood, refunding money to all the people who bought something from this platform. Now, that’s an intriguing vulnerability.

After spending a good amount of time with the program, I realized that all POST requests had a bouncer, a middleware that didn’t let the request proceed without a CSRF Token. I thought to myself, “What if there’s an API available via GET that allows me to bypass the CSRF Token?” I discovered that the request to delete a comment was made via GET but still had a CSRF Token added to it. I removed the token, sent the request, and voila, the comment was deleted. 😂😂

Just like last time, the request to transfer money from the account to the insurance was a GET request, which did not require CSRF and was easily exploitable. You might ask, what’s the risk? Well, the money that goes into the insurance is stuck there, but a quick ticket to the support department fixes the problem. But hey, a vulnerability is a vulnerability.

The target had recently added a product rating system to the comments section. The average of these ratings was displayed on the main store page, thereby boosting the credibility of stores among buyers. However, we were only allowed to submit one comment per store.

I decided to test for a race condition for the first time. I captured the HTTP request for submitting a comment and fed it to Turbo Intruder. A few seconds later, I found that 18 comments with 1-star ratings had been submitted, and the store’s rating had plummeted.

The impact? A drop in buyer trust due to the store’s low rating.

After my previous test, I wondered, why not test the refund functionality? I did the test and saw a significant amount added to my balance. I purchased again, refunded again, and my balance increased again. Was I dreaming? Did I just stumble upon an infinite money glitch? HELL YEAH!!

I tested the purchasing section in the same way as the previous test, and lo and behold, multiple products were added to my account.

The target was made up of two websites: the main website where I performed all my tests, and a secondary website with a different domain and purpose. The secondary website had previously caught my attention as its API returned JSON responses with a content-type of text/html, which was a red flag. I had reported some issues because of that, but the primary issue wasn't addressed.

I noticed a new feature that allowed products from the main website to be displayed on the secondary website via their API. However, a fee was required to show products from the main website on the secondary website. I examined the API and found that product names and descriptions were being directly embedded in the JSON responses. I created a product with an XSS payload in its name and paid the fee to have it displayed on the secondary website’s API.

Guess what happened next? The XSS payload was executed.

Well, that’s all the vulnerabilities I’ve unearthed so far. While they may not be technically complex, finding them has been quite the thrilling rollercoaster ride. I’ve spent around 5 to 6 months on this target, getting to know it like the back of my hand. I would check it daily and sometimes weekly when my schedule was packed. If anything was added or removed, I would notice and test it. Business logic vulnerabilities might not always have a significant impact, but finding them is a thrill in itself. I highly recommend giving it a go.

That’s all folks! If you have any questions, feel free to ping me on Telegram.

Oh, and by the way, my friend has written a new write-up too, so be sure to check that out as well! :D

me on twitter (i only tweet in persian :D❤)