How to defend your website against card skimmers

Black Friday and the holiday season are approaching, and shoppers are forecast to spend record amounts again this year. Retail websites big and small can expect a lot of interest from shoppers looking for deals, and a lot of interest from cybercriminals looking to cash in on those shoppers, by stealing their credit card details with stealthy card skimmers.

Card skimmers, or web skimmers, are pieces of malicious software that criminals piggyback on to legitimate websites, so they can steal shoppers’ credit card details. The skimmers read the details as users type them into the sites’ payment forms, or replace the payment forms with convincing fakes. Attackers have even been seen adding entire checkout pages to sites that don’t take payments. Skimmers can steal card details in real time, as they are typed, even before the victim clicks “submit” on the payment form.

Skimmers allow criminal hackers to silently rob every customer that makes a purchase on an infected website, until they are discovered and removed. Malwarebytes products detect card skimmers, and our Threat Intelligence team tracks and investigates them. We know that card skimming activity tends to increase inline with busy shopping days, and shop owners need to be extra-vigilant heading in to the holiday season.

In this article we will explain the basic steps you should take to secure your website against card skimmers. Getting these basics right will also protect your website against a range of other cyberthreats too.

But before we look at how to secure your site, let’s look at why you should, if you’re only running a small mom-and-pop shop.

Why you aren’t too small to get hacked

If you think your website is too small to be of interest to cybercriminals, think again. They don’t care how small your site is. Really. In fact, they don’t care about you at all and may never even look at your website.

Cybercriminals don’t break into websites one by one, using their best guess to figure out your password like they do in the movies. They use computer programs to scan the Internet for vulnerable websites. There are millions of vulnerable websites out there, and scanning the entire Internet to find them is fast, cheap, and easy.

When they find a site they can break into, they inject a card skimmer, automatically.

Their objective is to break into thousands of websites at a time and the process is automated and can run continuously. It effectively costs criminals nothing to break into even the smallest website, so every website—no matter how small—is an attractive target.

Websites without a payment form can be still be targeted, or monetised in other ways, so even if your site doesn’t sell anything, it is still at risk.

Securing your website

With an Internet full of potential targets to choose from, you don’t have to do much to make your website less attractive to attackers. As the old saying goes, you don’t have to outrun the bear that’s chasing you, you just have to outrun the other people running away from the bear!

So, how do you move a little faster than the others?

Step 0, keep your computer secure

The first step in keeping your website secure is to make sure that your computer, and computers belonging to anyone else who administers the site, are secure. If your computer has malware on it, it doesn’t matter how secure your website is, because criminals can just steal your password or login in to your website from your computer, pretending to be you.

Keep your software up to date with security fixes, and install a modern antivirus solution, a password manager, and a securiity plugin for your browser, like BrowserGuard.

Set strong passwords. Never share them, never reuse them

One of the easiest ways to break into a website is to guess an administrator password for the software that runs the website—its Content Management System (CMS). If an attacker can do that, they can do anything they like to the website, including adding a card skimmer and dismantling any defences you have.

Just as they don’t search for websites manually, attackers don’t guess passwords manually either. They have computer programs for that too. And once their scanner finds your website, another computer program will happily plug away 24/7, trying to guess your password. They will move on eventually, but they may have made thousands of attempts before they do.

The good news is that you can seriously sharpen up your password game by avoiding a few bad habits:

• Bad passwords. Cybercrooks don’t guess passwords randomly, they use lists of popular passwords. The ten thousand most common passwords are full of easy-to-type sequences like 123456, 1111, and qwertyuiop, or they are made from names and common words like monkey, michael or trustno1. If your password is on that list, or looks like the passwords on that list, your website is in trouble.
• Shared passwords. If you share a password with somebody you have no idea if they are storing it securely, or who they might be sharing it with. The only way to ensure passwords stay secret is to never share them. Give everyone their own account, with their own password, and tell them not to share.
• Passwords you’ve used elsewhere. Alongside common passwords, criminals also use lists of usernames and passwords exposed in data breaches (this is called credential stuffing). Chances are you’ve lost at least one password in a data breach. If you never use the same password twice, you can’t be caught by credential stuffing.
• Everyone’s an admin. It’s often convenient to give everyone who works on a site an administrator account, so their work isn’t interrupted by being denied access to something. But every separate administrator login gives criminals another potential way in. Save administrator-level access for the people that need it, and aim for the smallest number of administrators you can get away with.

You can get to grips with most of these bad habits by adding two-factor authentication (2FA) to your site. 2FA forces users to provide another piece of information with their password when they log in, such as a one-time code from an app. Any decent website CMS will have a 2FA option built in, or 2FA plugins that are easy to find and install.

If your company uses a Virtual Private Network (VPN) to provide secure, remote access to company systems, you could limit access to your website login screen to company VPN users too.

Keep website software up to date, every day

Another easy way to break into a website is by exploiting a software vulnerability in the web server, CMS, or plugins your website uses. A vulnerability is a coding flaw that lets attackers do things they aren’t supposed to be able to do, such as adding files to your website, or accessing its back end without logging in. When software vendors find vulnerabilities in their software they provide a security patch that fixes the problem.

Your website is only secure against that problem when you apply the patch.

Criminals often reverse enginer patches to find out what vulnerabilities they fix, and then attempt to use those vulnerabilities to break in to websites that haven’t been patched yet. They can do this extremely quickly.

In 2014, Drupal, a very popular CMS, released an update for a serious security flaw. Criminals reverse engineered the update and were using it to take over websites within hours. Later, the Drupal security team made the extraordinary announcement that if you hadn’t updated your website within seven hours of the patch being released then you should “consider it likely your site was already compromised”.

Make sure you know whose job it is to keep the website patched. This may be something that the people who built and maintain your website will do for you, or a job you need to do yourself. Whatever you do, don’t just assume that somebody else must doing it.

If you use WordPress, it should update itself automatically with security fixes. You can check this by logging in and going to Dashboard > Updates. Note however, that WordPress will not update most plugins automatically. Vulnerabilities in plugins are common, and probably the biggest threat to your website, so if nothing else, you will need to make a point of logging in regularly to check for and apply plugin updates.

The same is true for other CMSes: You should log in regularly to see if there are updates that need to be applied. We suggest you also go to your CMS vendor’s website (and any plugin vendor’s sites too) and see if they have a mailing list where they announce patches. Sign yourself up so you are alerted if anything urgent needs your attention.

Finally, this advice applies to every website under your control. It is quite common for companies to run a number of websites on the same server. These could be different websites for different purposes, or test and staging versions of your principal site. If any one of those websites is compromised, it gives attackers a potential route to cross-contaminate all the other sites on the server. Test and staging sites are often neglected, and often exposed to the Internet accidentally, making them a particularly soft underbelly.

Use a Web Application Firewall (WAF)

A Web Application Firewall (WAF) is an appliance or Cloud-based service that filters the data that’s sent to your website, weeding out things that look malicious, such as XSS or SQLi attacks. They can also prevent unauthorized data (like credit card details from a server-side skimmer) from leaving your website if it is compromised.

WAFs use a rulebook to recognize malicious or unauthorized inputs and outputs, which means they can often provide protection far sooner than patching. All a WAF vendor needs to know to create a new rule is what input the attackers are using to compromise websites. To create a patch, a vendor needs to know what input the attackers are using, but also how that input affects their software, and how to fix it without breaking anything.

WAFs add complexity to your environment and may require regular updates, but they provide a useful extra layer of defence for your website. You should never use a WAF as an alternative to patching, but using one could save you if you miss a patch, are too slow to apply one, or if attackers are using a zero-day technique that your CMS or plugin vendor hasn’t patched yet.

Protecting users from rogue dependencies

Web pages are typically made up of multiple separate elements, such as scripts, images, like buttons, sharing widgets, and so on, drawn from multiple different places. In fact it is not uncommon for individual pages to have tens or even hundreds of such dependencies, and for them to be drawn from many different domains: Analytics and advertising code from Google perhaps, a Tweet button from Twitter, images pulled from a Content Delivery Network (CDN), and so on.

The different elements are only assembled into a single page at the last minute when it’s viewed in a web browser, and that process is repeated in each user’s machine, each time the page is viewed.

Each dependency is a potential backdoor into your web pages. If an attacker can compromise a site hosting one of your dependencies, they can use it to inject a card skimmer into your page when it is assembled by a web browser, without ever compromising your website. You can’t control the passwords or patching on the sites you depend on, so instead you must take steps to protect your users from compromised dependencies.

Subresource integrity

Subresource integrity is a form of tamper protection for scripts and stylesheets. If an attacker compromises a third-party script your website relies on, they can use it to inject a card skimmer into your pages.

In June 2019, Malwarebytes Threat Intelligence discovered exactly this kind of attack on the official Washington Wizards page of the NBA.com website. Attackers had managed to alter a script the site used that was hosted on an Amazon S3 storage website.

Subresource integrity protects against this kind of attack by using fingerprints (cryptographic hashes) to verify that elements loaded by <script> or <link> tags haven’t been altered.

For example, let’s say your website uses version 3.6 of the popular jQuery JavaScript library. Without Subresource Integrity, the script tag for it would look like this:

<script src="https://code.jquery.com/jquery-3.6.0.js">

With Subresource Integrity, the script tag looks like this:

<script src="https://code.jquery.com/jquery-3.6.0.js" integrity="sha256-H+K7U5CnXl1h5ywQfKtSj8PCmoN9aaq30gDh27Xc0jk=" crossorigin="anonymous">

When a browser assembles your page it will download the jQuery code and create its own cryptographic fingerprint from it, and match it against the fingerprint in the tag. If the fingerprints don’t match, the browser will assume the jQuery code has been compromised and won’t run it.

Content Security Policy

Sometimes, instead of changing an existing dependency, attackers can find enough leverage to add a new dependency to your site, from a website they control.

Content Security Policy (CSP) is a simple addition to your website that can protect against this form of attack. It works by sending web browsers a list of the domain names your website trusts, and what it trusts them to do.

For example, let’s say your website is example.com, and your website includes Google Analytics code, which is loaded from the analytics.google.com domain. Your CSP header would say you trust your own site to provide all forms of content, and it trusts Google Analytics to provide scripts, and nothing else. The actual instruction looks like this:

Content-Security-Policy: default-src 'self'; script-src analytics.google.com

If a cybercriminal sneaks a card skimming script on to your site that’s loaded from example.xyz, web browsers will refuse to run the card skimmer. So, even though your website has been compromised, it will not affect your users.

CSP isn’t perfect. In a serious hack, an attacker might gain enough access to your site to remove the CSP instructions altogether, but in many situations they won’t.

You can see if your website already has a CSP header (and other useful security headers too) by checking it on securityheaders.com.

Pulling it all together

Securing your site and its dependencies against attack are vitally important, but sometimes you don’t realise you’re vulnerable until it’s too late, or your Subresource Integrity and CSP silently block a rogue dependency and you don’t ever learn about it

In both cases you want something that tells you as soon as the problem starts. So the last step in securing your site is to use a third-party integrity monitoring service that sees your site from your users’ point of view. These services can find card skimmers that slip through the net and, most importantly, tell you that there’s something you need to fix.

Automated integrity checking services are like users that work on your behalf, periodically visiting important web pages, like your checkout, pulling in all the dependencies in real time, looking for anything that shouldn’t be there, and alerting you if they find anything.

Although we have gone into a lot of depth in this article, keeping websites secure is mostly a matter of setting up a few services, and then doing a some simple things, over and over again. By making these things a habit, you will strengthen your site enormously against card skimmers and other attacks, and keep your users safe through the holiday season and beyond.

* The fake checkout is on the left.

The post How to defend your website against card skimmers appeared first on Malwarebytes Labs.