Five E-Commerce Security Myths (Part 2)

In part 1 of this series I gave an introduction into how most merchants accept payments and how most bad guys steal this data. In this post, I'm going to delve into the misconceptions about e-commerce security that we hear every day.

As part of our role delivering incident response services we have to speak to compromised merchants, inform them that they may have been compromised and help them to remediate the security issues they may have. Almost every merchant that we speak to will tell us that there is no way that their data could have been compromised. They will cite the following reasons:

• I don't store credit card data
• All of my credit card data is encrypted
• My site is secure because I purchased an SSL certificate
• My data is safe because I work with a PCI-DSS certified third-party
• No one would bother hacking me - I'm too small

For those in the information security field, at least some of those responses will have prompted a smug chortle. For most merchants though, these are completely understandable responses. Let me delve into each of them in detail.

I don't store credit card data

When a merchant tells us this, we understand that what they mean is "I don't intentionally store credit card data long-term". Most merchants are well aware that they don't need credit card data after the point in time when they process a transaction. Those merchants using a "Store and Download" model do however need to store this data until such time as they can process the order. The normal process for most merchants is that they then "delete" this payment card data from their ordering system.

In our experience this data is rarely ever completely gone. Because developers have an aversion to ever losing data, many merchant systems are just set to mark an order as shipped and hide the details, rather than to actually delete the payment card data. Other merchant systems we've seen contain functionality to automatically create database backups periodically.

Regardless of this - the point is moot. If the data is being stored at all, even for a few seconds, it may be possible for an attacker to steal it. Merchants tend to imagine an attacker sitting at their keyboard manually downloading their data. Our experience shows that attackers make heavy use of automation to save time and effort. If they need to return to a website to check for new orders every 5 minutes, no problem, they will write a script to do it for them.

We also see stored data attacks in API environments. In these cases we most often see card data being accidentally stored in log files. The merchant usually genuinely did not intend to store this data, but were caught up by some built-in logging functionality, often left over from the time when they were implementing and testing their site.

All of my credit card data is encrypted

When we're told that the credit card data is encrypted, our next question of a merchant is "great - so how do you see the data". Their response is usually that the data is just displayed on the screen for them, decrypted, of course. This is somewhat obvious, as for the credit card data to be of any use to the merchant, they have to have a method of decrypting it so that they can process it.

Although it is possible for credit card data to be encrypted in a manner that would make it possible for a merchant to access it but very difficult for an attacker to access it (The LiteCommerce shopping cart, for example, has a nice asymmetric encryption module based on GPG) more often than not any encryption is done with a single symmetric encryption key. This means that the data is encrypted and decrypted with the same piece of secret data that necessarily is stored in a location that can be accessed by the web application. I say necessarily as it is the web application that needs to encrypt the data as it saves it to the database, and decrypt it to show it to the merchant.

This type of symmetric encryption is essentially useless if an attacker manages to gain access to your website.

If an attacker encounters encrypted payment card data, they will simply look for the piece of website source code that performs the encryption and decryption on this data. Armed with a copy of this source code, and with a copy of the encrypted data, it is simple for the attacker to reverse the encryption and obtain the clear-text payment card data.

My site is secure because I purchased an SSL certificate

SSL certificates are an important part of the security of an e-commerce site. They are intended to protect data as it is transmitted between the merchant's servers and their customer's computer. Unfortunately, they have no effect on the security of the data once it has reached the merchant's server. They also have no effect on the ability of hackers to compromise a merchant's website.

Many merchants have misunderstood what an SSL certificate can offer them. For many smaller e-commerce merchants, purchasing an SSL certificate is their investment in security - they mistakenly believe that purchasing an SSL certificate will protect against all security issues and secure their data against all threats.

My data is safe because I work with a PCI-DSS certified third-party

Many merchants using API, hosted or direct payment methods will be working with a third-party that is PCI-DSS compliant. Oftentimes these merchants assume that because their processor is compliant, they do not need to worry about security.

This is unfortunately not true - the security of the merchant's own website is still important to the security of merchant's customers' payment card details. The reason for this is simple - if an attacker can compromise the merchant's web server, they can modify the source code responsible for sending customers or card data off to the payment gateway.

In an API model, the attacker could have the checkout process email a copy of the card details used with each order to them at the time that they are being authorised by the payment gateway.

In a hosted or direct model, the attacker can imitate the legitimate payment gateway and divert customers to their fake gateway. The attacker can then take a copy of the payment card data as well as send a copy to the legitimate payment gateway so that the merchant still receives payment for the order.

No one would bother hacking me - I'm too small

This is perhaps the biggest cause for the growth in e-commerce compromises. Almost all of the smaller merchants we speak to are operating on the mistaken belief that they are not a target since they are not a large brand name. They imagine an attacker sitting down at their PC scratching their head, thinking of the next big corporation to target.

In reality, the bad guys rarely target an e-commerce organisation because of who they are. Instead, attackers focus on specific security flaws that they know can give them access to systems used by e-commerce merchants. They develop tooling that means that it is easy for them to compromise systems with these security flaws, before scan the Internet for as many victims as they can locate.

Attackers are opportunistic too. If they compromise a system that only stores the details of 10 payment cards, they will happily compromise those 10 cards and move on. Due to the automation that they use, the cost to the attacker is very low.

Unfortunately, this means that small merchants with little or no security budget are in fact very common targets for attackers. These merchants tend to run commonly used cheap or even free software, and they tend not to maintain this software very frequently.

So what are the lessons from all of this for e-commerce merchants? With a few relatively simple steps e-commerce merchants can reduce their susceptibility to compromise:

1. Do not store payment card data. There are very, very few situations where merchants really require payment card data to be stored. Smaller merchants in particular are far better making use of a hosted or direct payment model where payment card data never touches their systems.
2. Keep your shopping cart software up to date. In most cases, attackers make use old and well known security vulnerabilities to compromise merchant web sites. Its usually the case that a simple software update on the merchant shopping cart would have prevented the attacker from being able to leverage this vulnerability.
3. Check your website regularly. As discussed in this post, merchants are never completely safe, even when using a hosted or direct payment model, as an attacker may divert customers off to alternate locations. Merchants should also consider making use of a file integrity monitoring package to monitor for unauthorised changes to their site. In this isn't possible, merchants should at the very least perform a test transaction each day and confirm that payment card data is sent to the expected location.