You won't want to miss out on the world-class speakers at TNW Conference this year 🎟 Book your 2 for 1 tickets now! This offer ends on April 22 →

This article was published on March 9, 2020

Focus on the client-side to protect your company from Magecart attacks

The 3 steps required to shield your company from a Magecart attack


Focus on the client-side to protect your company from Magecart attacks

Magecart refers to a cyber-crime syndicate that specializes in cyber-attacks involving digital credit card theft by skimming online payment forms. Gaining mainstream media attention over the last year or so, their most recent high profile attack was on photography retailer, Focus Camera. Their website got hacked by Magecart attackers who injected malicious code that stole customer payment card details – the script loaded at checkout to capture billing information and send it to the attacker’s server.

Focus Camera just added their name to the growing list of well-known organizations that have fallen victim to similar attacks (British Airways, Newegg, Macy’s) during the last year, with hundreds of thousands of customers typically having their card details stolen.

The Magecart credit card skimming approach is often to insert the malicious skimmer’s code into their target’s third-party providers (which has come to be known as web-based supply chain attacks). The attack on British Airways, but also Equifax, Forbes and thousands of others were all achieved via malicious code that was injected into company websites via third-parties and then run in its users’ browsers. In this way, a company’s website or web app has become the perfect stage from where to steal customer data.

And let us not forget the huge financial downside for those companies attacked. After the attack on British Airways for example, it was announced that the Information Commissioner’s Office (those responsible for upholding the UK’s information rights in the public interest), announced their intention to fine British Airways (BA) £183.39 million for breaches of GDPR. And whilst 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 a high profile attack is difficult to calculate and there are signs of ambulance-chasing outfits seeking to reimburse those individuals affected – a kind of PPI-style payout scenario. The stakes therefore, are very high.

So what can organizations do then in the face of such large-scale attacks with such far-reaching consequences?

Uncover your security blind spots

If you are serving your customers via any kind of e-commerce platform or website, then are you sure that the website content that your customers are receiving is what you expect them to receive? That is to say, is the website that your potential customers are interacting with, a bona fide site and not one that has already been tampered with by hackers? Typically, neither business owners nor security teams have a definite answer to this question.

A decades-long focus on server-side security has resulted in mostly everything that happens on the client-side (i.e. the browser and the environment where Magecart attacks operate) going widely unnoticed.

Enough postmortem analysis of Magecart attacks have been made that we now understand that there’s no guaranteed way of preventing these types of attacks altogether. We can, however, shift our attention to what is happening on the client-side. If organizations still can’t clearly answer the question of, “what code are my users receiving when they visit my checkout page?”, then they have a massive client-side security gap where Magecart thrives.

Understand and fill the client-side security gap

Not all Magecart groups use the same strategies to breach e-commerce websites. Some opt for a first-party breach – either directly by breaching the 1st party server, or indirectly by infecting code that is later pulled to the server as part of the build process – but the majority pursue an attack via third-parties, considered as the weakest link.

This weak link often refers to scripts that companies run on their websites, such as live chat, widgets, analytics, or other utilities – and so companies that use them actually have zero control over their security. Because the attack originates from a source that is trusted by default – a legitimate third-party supplier – this malicious code easily bypasses firewalls.

The enterprise should definitely vet third-party code and their suppliers’ security (or lack thereof). However, this often loses priority to product development. The job ultimately falls to client-side security systems in place – often sadly, none seem able to prevent Magecart.

Magecart attacks are growing more sophisticated with each iteration. Recent versions of Magecart are using bot detection techniques to avoid detection by some security solutions, making it even harder to stop the skimmer in its tracks. Clearly, it makes sense that the way we address these attacks evolves in a similar fashion.

Protect against future attack

So what can actually be done to mitigate such Magecart style attacks? Considering an evolving security mindset, instead of looking for a solution that prevents un-preventable malicious code injections, the enterprise should seek to be able to detect these injections and quickly block Magecart attacks.

Third-party management and validation is a good start, but not enough. Vetted scripts can change behavior, so the key is to only trust these scripts if they don’t change their behavior. A live chat script has no business touching the payment form. A script that never sends information out should never be able to send data to an unvetted domain. More than vetting the code, restricting these behaviors is what makes a good defense, by employing a defense-in-depth strategy.

And this is where organizations are failing. Some Magecart attacks have remained undetected for longer than six months and, as we learned from the British Airways breach, it only took (allegedly) 15 days to steal credit card details of over 380,000 customers. This makes it very clear that organizations don’t really have a way of knowing when a malicious skimmer is running on their websites. And so this is the issue that should be addressed most urgently – when a Magecart skimmer somehow finds its way into a company’s website, the company must be able to instantly detect it, block the code, and keep its users safe.

To achieve this, organizations should put in place a web page monitoring solution, so that they gain real-time visibility of malicious code and pave the way to automating Magecart mitigation.

The ongoing wave of Magecart attacks shows precisely just how unprepared e-commerce businesses are, security-wise. Timing is key. If e-commerce businesses gain the ability to detect Magecart in seconds (rather than months), then we are looking at a decade where Magecart’s headline-making days are numbered.

Get the TNW newsletter

Get the most important tech news in your inbox each week.

Also tagged with