Hacking An E-Commerce Site - For Fun Or Profit?

Having testing a number of e-commerce sites in recent times, I wanted to share some of the vulnerabilities encountered, and the reasons why someone would seek to exploit them. Recent high profile hacks in the media have rightly made retailers sit up and take notice of security - whilst PCI DSS attempts to mandate a certain level of assurance, the risk of losing substantial amounts of money and seriously damaging reputation focuses the attention on security more than any overarching standard.

In essence, this post includes many of the OWASP Top Ten vulnerabilities (yes even the largest retailers fall foul of such common classes of vulnerabilities), with specific examples of how these apply to typical e-commerce sites. If you are implementing a web site and intend on taking online payments, I urge you to read and understand these issues. If you're a penetration tester, you have probably encountered most if not all of these issues first hand, though this post may help understand the motivation and techniques that real attackers are actually using. So let's get started...why would someone attack an e-commerce site?

Steal Credit Cards
It's a fair assumption that the primary motivation of a typical cyber criminal is financial gain. When referring to e-commerce sites, this would normally be credit card details. SQL injection is the most common vulnerability exploited to obtain this goal.

SQL injection involves crafting input to an application, with the intention of breaking out of a SQL clause in server side executed code to manipulate the statement sent to the back-end database. There are two main classes of SQL injection, blind and non-blind; the risk impact of both is identical, probable full database access and in some cases even the ability to run operating system commands. Whilst blind injection is considered harder to exploit by many, a skilled attacker, or a script kiddie with well-written tools, should be able to exploit either without much trouble.

I've noticed a decrease in injection attacks over the last two years, though a finger in the air guess would suggest around 20% of sites tested are still vulnerable. A successfully exploited SQL injection attack often reveals further security issues, such as plain-text or easily crackable passwords and storing of excessive information, for example CVV2 numbers - a clear PCI DSS fail.

A reasonable sized e-commerce site would trade many hundred transactions a day, with the largest retailers trading multiple transactions per second. Whilst the value of a stolen credit card is surprisingly low (less than £0.40p per card), when you've stolen millions of cards, it's quite clearly big business.

Contrary to popular belief, cross-site scripting (XSS) can also be used to steal credit cards via a couple of different methods. XSS essentially refers to the ability of running arbitrary JavaScript (though any script or HTML content could be injected) in the victim's browser. As the script is reflected or stored by the target site, the script will run with the same security context as the site itself. That means it is often possible to hijack sessions, intercept keystrokes (credit card numbers FTW), deliver browser exploits and much more. It is possible to make XSS keystroke interception persistent across subsequent pages after successful exploitation, so the vulnerability can exist anywhere on the site - it doesn't need to be on the actual payment page.

The difficulty of exploiting XSS in this manner varies, and it often becomes easier if other [common] low risk issues are also present on this site. For example, careful session management such as issuing new identifiers post authentication and sensible session expiration times helps reduce, but not eliminate the problem. Likewise, scoping session cookies correctly ('Secure', 'HTTPOnly' and 'Scope') makes life more difficult to an attacker, but doesn't mean they can't succeed. That said, if you're transactions are carried out on a separate domain (i.e.https://secure.someretailer.local) and you haven't scoped your cookie to *.someretailer.local, the attacker will be limited to [seamlessly] redirecting you to a third party site to capture your details rather than reading them straight from the page.

Finally, it may be possible to use stored credit cards if unauthorised access can be gained to an account. Fairly low risk of this happening in practice, as a change of delivery address normally requires the credit card to be re-entered. Downloadable purchases may be the only avenue of attack here.

Buy Things Cheaply
Manipulating check-out prices is an obvious concern to retailers and is quite clearly a risk, though I suspect is actually very rarely exploited. The reason for this is quite simple; an attacker exploiting such a vulnerability is relatively easy to track down; when they purchase tangible items the goods must be delivered somewhere. For this reason, today's attacker is more interested in stealing personal details rather than knocking a few pounds off the checkout price.

There is still one interesting attack here, and that is exploiting the trust relationship between the retailer and merchant. I haven't seen this one in the wild myself, but have heard a few examples of big retailers not verifying confirmation codes from payment processing companies (e.g. PayPal). The attacker would buy a low valued item, intercept and keep note of the confirmation code sent by the processing company. They would then proceed to buy the items of their choosing, but rather than handing over card details, they would simply replay the captured confirmation code from the earlier checkout. To the backend processing it appears the order was paid for in full. The implementation error of course relates to the lack of verifying the confirmation code for each order.

Cause Reputational Damage
Surprisingly common these days, sites will get hacked by groups that oppose an ethical viewpoint, or just for the sheer fun of causing disruption. Many vulnerabilities can lead to reputational damage, even denial of service attacks knocking a site offline for a period of time is going to seriously annoy customers. Real site defacement however is relatively rare as it normally requires the ability of manipulating server side code; with this level of access why not steal cards/personal data and run? Fact of the matter, any exploited vulnerability that makes it to the public domain will be damaging to an organisation. In recent times Play.com received a tremendous amount of bad publicity after a hack of a third party marketing company, not even infrastructure under their control!

Steal Personal Details (ultimately resulting in financial gain)
This is the big one. Over the last 12 months I have carried out two forensic investigations where the primary target was personal details; name, address, telephone number and most importantly, username and password. It is a well know fact that users will reuse passwords. Most sites encourage users to sign up with an email address, meaning if an attacker were to compromise a site and gain access to such information, chances are they would be used elsewhere. Such as the victim's bank, their PayPal account and their GMail account. Once an email account has fallen, normally all other sites will follow in close succession as it is a simple case of following forgotten password procedures. At a minimum, expect large number of email address to be sold for spam, but the real consequences are much worse.

SQL injection is again probably the easiest way to obtain this information, but other routes to compromise do exist. XSS for example would allow sessions to be hijacked, keystrokes to be intercepted and sent to an external domain. Inadequate access controls (lack of checks to see whether a given user has access to certain information) sometimes permits access to account management pages based on weak cookie or URL values. For example, what would happen if an attacker were to change "123" in the following URL - http://www.somesite.local/accountmanagement.php?userID=123?

Lower risk vulnerabilities can again compound each other to raise the overall risk profile of an organisation. One site I recently tested had an interesting and rather strange vulnerability; the user's password hash was returned to the browser if they happened to return to the 'register' page and view the source. This doesn't seem like such a big deal, but it told me that the passwords weren't salted, and that it was a straight MD5. A subsequent SQL injection vulnerability to retrieve the hashes would mean a large number of accounts could be easily cracked.

Discover Sensitive Information
Multiple sites I've tested have had poor access controls over order tracking pages. By manipulating the URL directly, all historic orders could be accessed, which in one instance had full name, address and order details. The URL was constructed similar to this - http://www.somesite.local/ordertracking.php?orderID=1234567. Any competitor, or shareholder, could access this information and obtain commercially sensitive information regarding the performance of the retailer, shopping habits of customers, and of course, personal data that should be protected under the Data Protection Act.

Conclusions

When it comes to e-commerce sites, attacker motivation usually boils down to financial gain. An attacker can obtain credentials, credit card details and other sensitive information by exploiting a number of unique vulnerabilities. They are all surprisingly common, despite the security features of modern application frameworks. A good application penetration test should uncover most if not all of these issues, but a mandated ASV scan will struggle to identify most of the issues discussed in this post. Has anyone else in the industry noticed more retailers asking questions since the recent bout of hacks have been published in the media?