In my previous post about ecommerce credit card swipers I described the general overview of the online ecommerce environment as well as some of the reasons behind why websites become compromised with this type of malware. In this post I will go into some more detail of the taxonomy of web-based credit card swipers, review some good online resources on vulnerabilities as well as some steps to protect yourself, your website and your customers.

Different Types of Swipers

Now that we have reviewed the broader ecommerce web environment in the previous post, let’s take a look at some actual swipers and the different “flavours” that they come in. There are, by and large, four different types:

• Javascript injection
• Javascript file modification
• PHP file modification
• Compromised server

Javascript Injection

A Javascript injection is usually by far the easiest to spot and easiest to clean, but it’s also the easiest for attackers to place on a website. That is due to the existence of areas within admin panels for “miscellaneous scripts” in Magento and widgets in WordPress. Here is an example of such an injection in a Magento website:

These areas of the admin panel (which are by default wide open to brute force attacks as we reviewed earlier) are intended for things such as Google verification meta tags, Facebook tracking pixels and the like, but are easily misused by attackers to place credit card swipers.

These are easy enough to see in your browser, particularly if you are using a security extension such as NoScript (which I cannot recommend enough) and easy enough to clean. If the domain is added to our blocklist it should also be detected by SiteCheck. Naturally, the attackers are frequently swapping out these domains in place of new ones in order to avoid detection. It’s a constant, never-ending cat and mouse game.

These are surprisingly common and I have seen more than a couple fairly large companies impacted by this type of attack.

Similar types of injections can also be injected into the database of WordPress websites, in this case into the wp_posts table, specifically targeting their WooCommerce checkout page:

In this case, it was base64 encoded in order to avoid detection (that’s also just how some plugins store their data). When decoded it looks like this:

Loading malicious javascript from a bogus domain, and pretending to be Google Tag Manager.

How to remediate and prevent:  Delete the code from the administrator panel or database, flush the cache, change your admin passwords and protect your admin panel with two factor authentication. You will also want to run a security scan for other backdoors or other malware that may be present in the site.

Javascript File Modification

This type of credit card swiper is a little bit more sneaky, but can be detected in the browser and by some computer anti-virus programs. Here’s an example of a Magento swiper that has affected a .js file:

These injections tend to be heavily obfuscated and can be tricky to decode. These don’t necessarily have to target the ecommerce plugin files either. As long as the file loads on checkout then the payload can be delivered to the victim. Plenty of plugin and extension files load on checkout, so the culprit is sometimes difficult to track down.

The attackers need to have access to the file system in order to inject these in most cases (which, friendly reminder, is enabled by default in WordPress environments for admin users)!

A traffic inspection program can be very helpful in tracking down these files. Some anti-virus programs will generate warnings for these malicious files as well.

How to remediate and prevent: Remove the malicious code, change all access point passwords, update all software on the website and install all security patches. If it’s WordPress, disallow file editing. You will also want to run a security scan for other backdoors or other malware that may be present in the site.

PHP File Modification

This type of credit card swiper can be a bit trickier to track down because nothing actually displays within the browser. PHP is a server-side programming language, as opposed to Javascript which is browser side. All the malicious shenanigans happen on the server on which the website resides.

Here’s one targeting a WordPress / WooCommerce website lodged in a “wpusercleaner” plugin file:

As you can see, not all malware uses fancy pants encoding, and this one is mostly just in plain text with the exception of the exfiltration destination. However, it’s also very common to see advanced and complicated obfuscation being used:

This one being a Session.php file in a compromised Magento website. Again, with this type of malware, the attackers need access to the file system in some capacity, or need to exploit a vulnerability that allows them to access that. This can be anything from a breached admin account in certain CMS platforms, a compromised FTP, cPanel or hosting account password, or even an infected laptop/workstation that is used to administer the website.

How to remediate and prevent: Remove the malicious code, change all access point passwords, update all software on the website and install all security patches. If it’s WordPress, disallow file editing. You will also want to run a security scan for other backdoors or other malware that may be present in the site.

Compromised Server

By far the most devastating and catastrophic type of credit card swiper occurs when the attackers are able to completely take over and “root” the server on which the website resides. Tracking down this type of infection is very difficult and requires the usage of very specialised SSH tools such as strace to find.

Thankfully, these are very rare and do not often happen because they require a very serious vulnerability within server software or access to the server’s root account which would grant attackers full control over them. These tend to be most common on virtual private servers (VPS) since they are usually the least professionally managed environments (on account of the website administrators themselves needing to apply updates and patches, rather than the hosting provider).

What we have seen with this type of malware is that the attackers will replace one or more of the binaries on the server and have the credit card details spirited away to the exfiltration domain or IP of their choosing, all done in the background surreptitiously. Another reason why this type of attack is so devastating is because it is able to exfiltrate transaction details inputted on any form in use on the website. This even applies to payment services which handle the transaction itself which the webmaster believes was expressly designed to be immune from swipers and other security issues. Any and all payment information entered onto the website will be compromised.

How to remediate and prevent: Migrate the website files and database to a new server and nuke the old one from orbit, install all security patches and updates before deploying the site. Do not reuse any passwords, binaries or SSH keys from the old server. Always ensure that security patches are issued as soon as possible.

Let’s Review: How do sites get hacked?

This is of course a complicated question to answer because there are so many vulnerabilities and ways that a compromise can occur, but it tends to boil down to these main points:

• Vulnerable software in use on the website
• Brute force attacks / compromised passwords
• Lack of good security practices on the part of website owners

It’s worth noting that attackers tend to go after low hanging fruit. Most attacks are automated and just go after any and all websites with certain vulnerabilities present in them. It’s where the law of averages comes into play: the more websites you can compromise, the higher the chances of a successful capitalization of it.

That being said, I have seen (more than a couple of times) malware which seems to have been involved in a targeted attack on certain websites. In fact, some malware I have seen was purpose built for specific websites. This almost universally happens with credit card swipers on mid-market and above level websites. The attackers know that if they can compromise a larger ecommerce website that conducts a lot of sales then the rewards will be potentially huge.

It’s also worth noting that the good guys need to win 100% of the time while the bad guys only need to win once.

Vulnerability Resources

The following websites are great resources if you would like to learn more about online credit card theft and other website security issues:

• https://cve.mitre.org – This online database of all known vulnerabilities is the central location on the web for such information. If there is a known vulnerability in a piece of software it will be listed here.
• https://www.wpvulndb.com – This website is for WordPress specifically, listing all known plugin and theme vulnerabilities, as well as known vulnerabilities in the WordPress core files in previous versions.
• https://wpscan.com – A very useful WordPress security scanning tool.
• https://magereport.com – This site is great for scanning Magento ecommerce websites. It will list any missing security patches that can be identified, whether or not the site is running the most up to date version of Magento as well as any javascript based credit card swipers that it can find.
• https://blog.sucuri.net – You’re here already, so you already know.
• https://sitecheck.sucuri.net – This is our remote website security scanner which will comb through the outward-facing code on a website and report anything malicious (for which we have a signature written) that it can see. I would recommend running this scan on a website before you make a purchase on it, it might just save you a headache.

I’m an ecommerce website owner: How do I prevent an attack from happening to me?

Security can never be taken seriously enough. Most importantly, it should be a concern from the very beginning. Most of the clients that I work with do not even consider security at all until after their site has been blacklisted by Google and is belching out malware to all of its visitors and their clients are complaining that their credit card information was compromised after using their website.

Keeping a website secure can be a chore, I’m not going to lie, but that is much better than the alternative. Focus on these key points

• Keep all software on the website up to date, this can sometimes be a daily chore
• Use strong passwords, preferably long and randomly generated locked in a password manager
• Limit access to admin areas (use 2FA and an IP allow list)
• Have a secure hosting environment: Limit the number of sites in a single hosting environment and ensure secure file ownership and permission configuration
• Consider installing security plugins to help improve your overall posture
• Put your website behind a website firewall

If you want no part of any of those steps or feel overwhelmed by this I might recommend a managed ecommerce solution like Shopify or Etsy to cover almost all of it for you. Managed hosting – and even our own security solutions – can help ease some of the load if you want the extra control and can commit to being some part of the defense against attacks.

Stay tuned for more website security content!