Buying Stuff For Free From Shopping Websites

Last updated at Fri, 04 Oct 2024 20:01:30 GMT

Rapid7 is often tasked with evaluating the security of e-commerce sites. When dealing directly with customer financials, the security of these transactions is a top concern. Fortunately, there are ample pre-built e-commerce platforms one can simply purchase or install. From an attacker’s perspective, these are annoying to attack since they're tested so often by the vendors maintaining the e-commerce platform.

So how do you exploit a site that’s already been thoroughly tested? There are many ways, but we’ll go over two.

One exploitation path is through insecure custom code added to the e-commerce framework. Often, the framework won't come pre-installed with a business need of the organization and it's up to your team to create custom code to perform it. If this code isn't tested and secure, there’s a chance a vulnerability can be introduced.

Another way is the leaking of secrets or guessable credentials (yes, it still happens in 2024 ). Think an admin password being somewhere it shouldn't be, credentials sold underground from a data breach, or a password that’s just the company name.

A web application security scanner can often find straightforward vulnerabilities, such as outdated software easily, but other types often require a more human touch.

What follows are two real-world examples from the Rapid7 Penetration Testing team.

Site 1 - Insecure Custom Code:

The site we were testing was geared toward both businesses and consumers using a moderately customized e-commerce platform. Business customers received special offers and bulk deals, while non-business customers didn’t. The first instinct here is to sign up as a fake business in order to get discounted products. Easy, right? But this wasn’t possible because business customers were verified manually by the site’s sales team before they could create an account, verifying the customer by asking for an account ID and invoice ID from a previous purchase. Business accounts had the ability to assign roles within their account to other users, so sales users under the business account could be configured by admin users within the business account. In theory, everyday consumers had no way of getting a business account.

As our testing continued, this functionality stayed in the back of our minds while the application was enumerated to find other functionality. The more complex the site becomes, the more functionality exists to be found, and the more likely a vulnerability is to exist. Enumeration is a tedious process, but it answers questions like: What’s in the JavaScript files? How are invoices served? How did the developers plan the authentication flow? Are there quirks with the website framework that the developers didn't think about? Every factor is considered, because you can't hack it without understanding it. Even if you don't know the code, you have to at least guess what's going on.

Eventually we found an API request in the site's JavaScript which returned the account ID of your current company along with the last 10 invoice IDs. This was not that interesting, since we didn't have a company account, so it was assumed it wouldn’t return anything. After leaving it on the backburner for a while we thought, “let’s run it anyway... for fun.”

We discovered we could create a modified version of the request that returned a company ID and 10 invoice IDs. Running the request as a separate consumer account also returned the same IDs, which could only mean one thing: One business account contained a large number of individual consumers as users..

Once the IDs were found we went through the business account creation flow as the average business user would with the two IDs. The result was admin privileges over every consumer user — all 11,000 of them. This also allowed access to user addresses, phone numbers, emails, and even invoices.

From here, it would be fairly trivial to buy things as other users by managing their settings.

This vulnerability was reported to the client and mitigated by requiring business users to go through a more stringent verification process.

Site 2 - Leaked Credentials:

This site was just a normal e-commerce site; you login and buy the product you need, and then logout. That’s it. It had virtually no custom code implemented, so most of the site was limited to the standard functionality that came with the framework. Not much complexity meant not much room to play around with vulnerabilities.

Even though few high severity vulnerabilities were found, it is important that every avenue for exploitation be attempted — within scope, of course.

This includes open source intelligence (OSINT), and when it comes to web applications there's plenty to look for.

For web applications, this typically comes down to searching Google and Wayback Machine for URLs. From a hacker's perspective, it's a good idea to have as many URLs as possible to access just to increase the attack surface. One can’t really hack a website if one doesn't know its URL.

Another target to search is the developer’s previous project. Any code they’ve ever written becomes fair game. You can often find code posted online related to the thing you're hacking. Which is exactly what we found! A developer was posting test code in a public GitHub repo, and included a folder they shouldn’t have. Inside this testing code were credentials to pull the source code for the real site from another code repository site.

Inside that source code for the site were approximately 5,000 gift card codes, worth an average of $200 each.

This vulnerability was reported to the client and was mitigated by simply deleting the GitHub repository and changing the leaked credentials.

Conclusion

These are just two examples of what a successful pen test of an e-commerce site looks like. Most e-commerce platforms are heavily tested for security issues since they hold payment information, but custom code and/or configurations can often create security holes due to the additional complexity. An extremely complex exploit chain sometimes isn't really necessary to perform an exploit with high financial impact. All it really takes is a solid understanding of enumeration and a hacker's mind to process potential security holes.