4 E-commerce Security Failure Case Studies
4 E-commerce Security Failure Case Studies… and what you can learn from them!
Right off the bat, you might believe the idea of this article is preposterous. Maybe you are an established online retailer, counting the cash for years now, without any problems stemming from malicious intent. Perhaps you are currently still developing your website, thinking that with all the money going into custom works, not only you will get special attention to your security needs but also nobody could even know the back-door to your one-off online application.
It is more likely, even, that you went for the off-the-shelf solution, thinking the developer, with his superior economies of scale, has managed to seal off any possible security holes and provided you with a well-rounded product, covered by years of warranty and service contracts.
However, one who too easily dismisses the notions in this article must ask himself: if giants like Ebay, Sony, ProPayand PayPal have managed to fall for these ones, is he not at least slightly affected by hubris?
Truth of the matter is that those heavy hitters have simply fallen for the oldest tricks in the book, mostly due to management agility falling behind the speed at which attackers adjust to new applications and defenses.
The reader is invited to examine 4 notorious cases of security breaches, brief explanations of the damage done, the attack methodology and goals as well as effective countermeasures that can be applied immediately.
1. Fortune Five-hundred Failure: e-Bay, (possibly) millions of passwords stolen, damages in the $M’s
Somewhere in the beginning of March 2014, the C2C giant had noticed an unsolicited database session in their main servers, scanning password files. It was later officially announced that an undisclosed slice of the +120 million users have been compromised for credentials and personal information.
How did they get there? Well, e-Bay themselves acknowledged that one of their own has succumbed to a behavioral engineering trick known as Phishing, where the attacker would ask the password from someone who knows it, either pretending to be the original site or another, completely irrelevant, site but relying on the fact that most of us use the same password everywhere.
The goal of the perpetrators was to obtain e-Bay staff credentials and with that, to access their database and steal user personal information. From there, they could either collapse the entire e-Bay operation, by using the commandeered user accounts to wreak havoc in the site or, more probably, use that info for personal Phishing attacks (presenting themselves as e-Bay to the user, proving that with valid secret information and then asking for credit card numbers).
e-bay neglected two crucial security principals:
A. Two-factor authentication for staff, AKA: “what you know and what you have”. Staff cannot log in unless they know the password but they are also in possession of a physical device such as asymmetric public key generator or a USB key.
B. Constant training protocol. Had the staff been made aware of the trickery behind Phishing, they would most likely never use a common password and they would have been aware of what’s a legitimate e-Bay page and what is a Phishing attempt.
Unfortunately, in the aftermath of this is not only the time spent on damage control and a few rolling heads at the IT department but also a critical hit to e-Bay’s reputation, amid rising competition from other similar websites. No significant malicious use has been performed with the stolen data but e-Bay’s shares have lost great value.
2. A million tire-kickers walk into a store… PayPro suffers A day’s worth of DOWNTIME.
This isn’t the beginning of a joke, unless the punch line is a substandard DDoS protection layer.
Online retailers share many risks with physical shops: people who want to walk out with the goods without paying, vandals breaking the shop's windows and other malevolent entities.
One crime more specific to e-commerce sites is DoS, which stands for: Denial of Service. Often, this is abbreviated as DDoS - “Distributed DoS” (multiple "fronts" of attack).
Going back to brick and mortar terminology, this is the equivalent of a horde of deadbeats filling the shop to the brim, occupying all the staff, each unwelcomed customer holding on to some item on sale, not leaving anything for real customers to inspect but also not actually buying it.
Even worse: imagine prospective customers walking by, noticing the store is jam-packed and deciding they would simply not stand in the queue there, but rather shop somewhere less populated.
PayPro, a leading international provider of e-commerce was subject to such an attack. In this particular case, it was a layer 7 attack, meaning that the application was overloaded.
For example, a DDoS can make many requests to the network, hogging network access at the expense of other users who want to connect - this is network level. Another DDoS can use up very little network - just one session but a session that requests the application to process a large amount of data - that’s an application level DDoS.
The goal of such attacks can be:
1. Ideological - to stop a site from running
2. Distraction - while the security team is busy with unblocking the net, a more time-consuming attack, such as brute-force-method cracking may go on unnoticed
3. Extortion - attacking a website for a short period of time and then sending a “ransom note”, asking for cash to prevent another, much longer attack.
Luckily, protection from DDoS doesn’t require a fully dedicated engineer, singling out bad connections or requests and allowing only proper customer flow through. New software developments allow cost-efficient software to hook up to the e-commerce website with relatively little effort.
This is another case where an ounce of prevention beats a pound of cure, with the increase of DDoS attacks clearly becoming a staple for online sabotage.
3. Playing games with peoples credit cards, is what many accused Sony of doing, having exposed 77 Million user accounts with personal information and 12 Million unencrypted credit card numbers. On top of all that, add a MONTH of downtime and the damage becomes unmeasurable in exact monetary values.
From simple SQL injections, where the developer left a field for an attacker to exploit, by entering live code into it and executing queries and commands on the website through it, to highly sophisticated hacks, Back-doors may initially seem as rookie mistakes until one has been long enough in the industry to know that perfect knowledge exists only in retrospective. On one side, the online entrepreneur wants a website to bring the world together, no matter the platform, country, time and language, on the other, one that is sealed to any intrusions.
Considering how functionality tends to grow faster than fixes, it’s a tall order indeed. Nevertheless, some websites have never been hacked, and not because there weren’t serious attacks on them.
Some industry best practices:
1. Data security: Data should be encrypted against unauthorized reading
2. System alerts: Raising the alarms whenever a sensitive operation takes place, legitimately or maliciously triggered
3. Regular system updates: With developers eager to publish money making functionality and worry about fixing holes later, you want the newest version of your software at all times!
4. Regular back-ups
4. Cut the middleman! Millions of PayPal accounts victim to Man-in-the-middle HTML injections.
Eavesdropping is not the only risk when the connection between the customer and the web-shop is tampered with. The customer, while browsing, sends requests to the webserver and if there’s an attacker sapping the line, the response HTML pages can be intercepted, augmented and presented to the customer seeming absolutely fine.
Specific for this incident (which the author of this article witnessed himself) is the double log-in page. A prerequisite for such an attack is a way for the attacker to have a way to sniff and tamper connections to the victim site. Usually done by intercepting a cable to the server or, more commonly, an unsecure Wi-Fi connection, once the user logs in, instead of receiving the regular PayPal Welcome screen, the attacker managed to slip in a bogus, second, login prompt, which looks and feels quite like the PayPal one but obviously sends the password to the attacker’s database.
What saved me was an atypical typo in the bogus screen, which made me immediately suspicious of the authenticity of the supposedly American-made webpage. What a web developer could do, to make it easier for the user to detect similar attacks:
1. Disallow operations from an insecure WiFi or cable connection
2. Set up a system to block login attempts from uncustomary locations (for example, a user whose sole login origin for 5 years has been in The States, one day tries to login from Ukraine
3. Transfer layer protection such as SSL - to prevent eavesdropping and spoofing of communication and to filter-out unwelcome network traffic
4. Educate the users to only perform important web transactions while the https, not http, prefix is in the address bar. Google supports this initiative by increasing visibility of sites that are SSL-certified and use https.
The following article is from one of our external contributors. It does not represent the opinion of Benzinga and has not been edited.