How To Protect Your Organization From Magecart

The cybersecurity attacks on the likes of British Airways, Macy's, and Forbes, amongst others, have been widely reported.

They all had in common the fact that they were targeted by Magecart. The Magecart attack involves a plurality of cybercrime groups whose modus operandi are cyberattacks involving digital credit card theft.

Magecart attacks are typically carried out by having the skimmer load at checkout, thereby capturing billing information and forwarding it to the attacker's server.

Another recent high-profile attack was on hardware retailer Robert Dyas. In this instance, their website was hacked by Magecart attackers, who injected malicious code to steal 20,000 customer payment card details over the course of 23 days. This attack hit the hardware store especially hard as it occurred during a period when e-commerce sales were enjoying significant growth.

The Robert Dyas attack is just another big feather in the cap for the Magecart massive.

Unfortunately, though, these are not victimless crimes. Typically, each attack results in the theft of credit card details for hundreds of thousands of customers (or other personally identifiable information, or PII).

Each of these affected individuals may be surprised by credit card fraud and have to go through a difficult remediation process.

For companies, such an attack often causes permanent damage. Apart from possible data privacy fines and lawsuits, breached companies often experience a significant loss in revenue due to negative PR and customer distrust.

Understanding the client-side security gap

Not all Magecart attacks follow the same approach to infected websites.

There are several known instances of first-party breaches, where attackers either directly breach the first-party server or inject code that is later pulled to the server as part of the build process. However, as attackers prefer to go after low-hanging fruit, third-party attacks, commonly known as web-based supply chain attacks, provide a more attractive way in.

In a third-party Magecart attack, attackers have no need to directly breach the first-party server they are targeting; instead, they insert the malicious skimmer’s code into one of the third-party scripts that their target uses, for example, live chat, widgets, or analytics; companies that use them actually have zero control over their security. This malicious code will be called directly from the server of the infected third-party and because it comes from a legitimate third-party supplier, it will not be seen as a threat.

Such Magecart attacks have been largely successful because they exploit the lax attitude that most businesses have towards third-party code. And so we reach a point where an organization’s website or web app has become the ideal place for criminals to steal customer data.

The danger posed by third-party code has highlighted the need for vetting third-party code and the security of these code suppliers.

While code vetting is definitely a good practice to have, it is not nearly enough to stop Magecart, and companies often forgo vetting to make room for faster development. The job often falls to client-side security systems such as Content Security Policy or Subresource Integrity; however, these are often unable to counter Magecart, especially considering the new wave of evolved web skimmers.

Magecart attacks keep getting more sophisticated with each new iteration. More recent versions of these web skimmers go as far as employing bot detection techniques to become much harder to detect. It makes sense, therefore, that the way we address such attacks needs to evolve accordingly.

Where are your security blind spots?

The first question you should ask yourself if your website handles credit card payments is: do you know if, under the hood, your website is behaving normally in each of your customers’ sessions? In other words, are your clients interacting with a clean platform instead of one that may have been compromised by attackers?

It’s likely that you won’t have a definite answer to these questions. Companies sadly can’t control everything that happens between their customers opening their website and paying for an order. There’s a whole lot happening on the client-side (i.e., in the context of the browser) that companies are completely oblivious to.

On the flip side, we now have enough analysis of past Magecart attacks to begin to understand how to shield companies from this threat. And one of the biggest conclusions we can draw for now is that there’s no guaranteed way of preventing these types of attacks altogether, especially with these ever-evolving web skimmers.

Protection Tactics

What can organizations actually do to fix this blind spot and mitigate Magecart-type attacks?
The road to Magecart mitigation starts with a security-in-depth mindset.

Managing and validating third-party code is a good start, but it comes short. Even vetted scripts can suddenly start displaying malicious behavior, so trust must be maintained whenever this change occurs. For example, a vetted live chat script can play an essential role on an e-commerce platform, but if it suddenly starts meddling with a payment form, that is a strong indicator that the script has somehow gone rogue. And even with more complex scripts that frequently send data out to trusted domains, there’s a clear indication of compromise when they start sending data to unknown domains.

These scenarios are just a few of many where organizations are still failing. Some Magecart attacks have remained undetected for longer than a year, and attacks like the one on British Airways showed that 15 days is enough time for attackers to siphon the credit card details of over 380,000 customers. Such long-standing attacks make it very clear that companies have no way of knowing when a malicious skimmer is running on their websites.

Gaining client-side visibility should be a top priority in the fight against Magecart. This way, whenever a Magecart skimmer somehow finds its way into a company's website, the company has enough time to respond to the attack.

The next step is to be able to restrict these malicious behaviors in real-time so that the attack doesn’t do any real damage.

With a behavior control of the webpage, companies can couple full client-side visibility with the ability to block the vast array of malicious behaviors that Magecart attacks display. Besides allowing businesses to block Magecart attacks, this behavior control approach enables following the least privilege principle by locking each third-party script to their allowed behavior and nothing more.

Achieving this level of protection makes huge financial sense too. For example, after the attack on British Airways, the Information Commissioner’s Office announced its intention to fine British Airways nearly £183 million for GDPR breaches. And while BA offered to reimburse customers who suffered financial loss as a result of the breach, they never actually admitted liability for this breach.

Reputational damage arising from such high-profile attacks cannot be easily calculated, but there is a financial loss associated for sure.

With this continuing surge of Magecart attacks, which keep happening every week, we see just how vulnerable eCommerce businesses continue to be from a security point of view.

It’s crucial that companies focus on in-depth security with code vetting, web page monitoring, and client-side behavior control to detect and block Magecart in seconds (rather than many weeks). Then perhaps we can see the first nails appear in Magecart’s coffin.

Originally published on ITProPortal by Pedro Fortuna.