Many clients that we work with host and operate ecommerce websites which are frequent targets of attackers. The goal of these attacks is to steal credit card details from unsuspecting victims and sell them on the black market for a profit. The online ecommerce environment is diverse, constituting many different content management system (CMS) platforms and payment gateways all of which have their own features and risks.

In this post I will attempt to demystify this cluttered environment, provide some context for the different attack vectors, and reasons how customer’s credit card details become compromised.

A Brief Overview of the Market

Before we jump into the thick of it let’s take a look at the broader ecosystem of ecommerce websites in order to get the lay of the land. As of 2021, the market looks something like this:

As we can see, WooCommerce (by far the most popular WordPress ecommerce solution) and Shopify together make up nearly half of the entire market of the top one million ecommerce websites. When this data is expanded to include all known ecommerce websites we see a much more granular picture:

This of course does not include larger ecommerce platforms such as Amazon, Etsy and eBay. This more granular data give us an idea of how prevalent some of the less common platforms like Prestashop and OpenCart are.

Security Risk of Ecommerce Platforms

Broadly speaking we can group these ecommerce platforms into two major groups: managed and unmanaged, with the latter group constituting by far the greatest risk in terms of their vulnerability to being hacked and falling victim to a carding attack.

Platforms such as Shopify are largely a managed service: the provider takes care of the back end, security, hosting, updates, and patches while the shop owner focuses only on their products. Since Shopify (and also, Etsy, Amazon, etc) has a full-time, dedicated team of people taking care of the back end we can consider them to be largely secure. No website or service can ever be considered 100% secure but these managed platforms are about as close as you can get.

On the other hand, the reason why unmanaged (or “self-managed”) websites are at such a higher risk of compromise is because the responsibility of maintaining and updating the website falls on the website owner. They may have a developer or website administrator to do that for them, or they might not, and the store owner may or may not be “tech-savvy”.

Let’s get into all the different risk factors that these unmanaged/self-managed websites face and why we so commonly see compromises on them.

Poorly Maintained Websites

We have said many times on this blog that the biggest source of compromise for websites is the use of out-of-date or vulnerable software. Some points of note:

• Websites require a great deal of (sometimes daily) maintenance.
• Owners of ecommerce websites are not always tech savvy.
• Ecommerce website developers tend to be expensive.
• Some platforms such as Magento are not always easy to update and patch.
• The use of weak passwords is very common.
• Whoever was responsible for the creation and/or maintenance of the website may no longer be available.

Quite often businesspeople who want to sell their products online have websites by necessity. Shopping for products online is of course increasingly common, and in order to stay in business these folks need to reach these markets. However, these store owners do not always know the amount of work and responsibility that it takes to properly and securely maintain a website. These sites can very quickly fall into disrepair, leading to the presence of sometimes multiple security vulnerabilities that can very easily be exploited by attackers.

Passwords are also frequently seen as a nuisance rather than something there to protect you. Many people choose a password based on their ability to remember it easily rather than a randomly generated one stored in a password manager. It’s also very common for people to reuse passwords passwords across different platforms. This is problematic because when a database for one website is leaked attackers will usually try those same passwords for that same user across different platforms.

Out of the Box Security Configurations

What is secure tends to be inconvenient and what is convenient tends not to be very secure. Content management systems, for example, are designed to be convenient and easy to use. The creators of these systems want website owners to use their platform, and website owners want to use something that is easy and convenient. I do not blame them, but this of course leads to a plethora of security problems.

Websites have little security built in other than password authentication. While on one hand their code may be securely written and not exploitable by any vulnerabilities (that we know of), websites can be hacked in all sorts of different ways. Take, for example, the administrator panel.

If you go to a random website and type in /wp-admin into the URL, there is a good chance you will be prompted with a login screen to enter the administrator username and password. Why are we able to see this from any computer in the world, by default? This renders these websites wide open to brute force attacks, and by default most CMS platforms do not have any limit on the number of times that you can enter the wrong password. Security plugins and extensions can be installed to improve this, limit access, and change the default admin login path, but the onus is on the website administrator to do this themselves.

It’s worth mentioning that WordPress (where WooCommerce is used) was never really intended to be an ecommerce platform. It grew in popularity to such a huge degree that what was originally purpose built as a blogging platform was transformed into something that could handle payments. In addition to the admin panel being wide open to password-guessing attacks, another feature that is very unsafe is the fact that – by default – files on the server can be directly edited from the admin panel. Therefore, if an administrator account is compromised through brute force a credit card swiper can very easily be placed within one of the files present on the checkout page, or even within the database by editing the posts, pages or theme / plugin options. The following can be placed within the wp-config.php file to prevent direct file editing, but once again, the onus is on the website developer to do that themselves:

define( 'DISALLOW_FILE_EDIT', true )

Keeping all plugins, themes and security patches up to date is labour intensive at the best of times, and we frequently see WordPress environments with many out-of-date pieces of software, despite this platform being considered very easy to use and update.

Magento is a different beast altogether, with the installation of security patches all the more cumbersome and more complicated than a simple click of the “Update” button. While patches can be installed directly from the admin page it’s usually recommended to install via an SSH connection in the command line. This is not very user friendly for folks that aren’t already familiar with this functionality.

Legacy Software

Website owners sometimes pay small fortunes for a perfect, custom coded website or theme. We see this in a lot of Magento websites but also with WordPress themes. What often ends up happening is that the site owner gets “stuck” using an old version of Magento, or an old vulnerable piece of software because updating it may break the website due to this custom code.

Developers are not cheap to say the least. Many business owners and owners of these websites do not have tens of thousands of dollars just laying around and are unable to have their developer migrate their site over to Magento2, or to the most recent version of WordPress or whatever other CMS platform they may be using. Migrating a Magento1 website to Magento2 can cost anywhere from $5,000 to $50,000. It should be mentioned that “custom coded” by its very nature is not future proof, so when for example newer versions of PHP or their CMS come out they cannot update without the support of the original developer.

Magento1 had its official end of life in 2020, however we still see many many of our clients using this old software. Adobe (the owner of the Magento CMS platform) has been desperately trying to get website owners to migrate their old sites over to Magento2, and in doing so actually took the security patches for Magento1 completely offline. This, as you could imagine, was not whatsoever helpful for website owners stuck in or otherwise unable to migrate away from Magento1. The only current alternative for those owners to download the existing patches is to rely on third parties like github repositories which makes it impossible to guarantee the integrity of the patches which has its own array of risks.

0-Day Vulnerabilities

A piece of software can be considered perfectly safe one day and an absolutely massive liability the next. These are often called “0-Day” vulnerabilities, because between the time the vulnerability is discovered and the time when a patch is issued there have been exactly zero days since the software has been released (in other words, there is no patch yet).

New vulnerabilities are discovered all the time. In fact, it is some people’s job to find them. Some of those people are good guys who are security analysts like myself, or software developers. However, others are attackers whose job it is to find and exploit these vulnerabilities and profit off of them. By far the most severe (and amazing) such vulnerability which briefly broke the entire Internet was Shell Shock. While this vulnerability was not directly related to online credit card theft, I think it is the best example of the generally fragile, volatile and chaotic nature of software.

The Shell Shock vulnerability was a bug in the code that was unknowingly introduced into the Bash shell in 1989, and it sat there unnoticed for twenty five years. A curious fellow by the name of Stéphane Chazelas managed to uncover this bug and it rendered nearly every Linux webserver completely vulnerable to remote code execution by any computer anywhere in the world. It was quickly patched but it’s a great example of how code can be considered safe one day and unsafe the next.

Taking into consideration that the ecommerce environment comprises many different CMS platforms which use hundreds of potentially vulnerable plugins and extensions,  it is clear the online retail space for self-managed websites is much different than the polished and meticulously designed checkout pages that customers see in their browsers.

Stay tuned for our next instalment on credit card swipers where we will review the different types of malware which can affect self-managed ecommerce websites!