Magecart 2.0: Architecture of a What-If

This case study was developed by Jscrambler’s Research team.

During the past few weeks, we’ve been seeing an alarming number of attacks targeting several eCommerce and ticketing companies, stealing their clients’ credit card data.

Behind these attacks, we find a group of hackers named “Magecart”. In June 2018, the group attacked Ticketmaster and breached credit card data of 40,000 customers; two major attacks followed in September, affecting 380,000 British Airways customers and an unknown number of Newegg customers.

The modus operandi behind this series of attacks was very similar: injecting malicious JavaScript code which acts as a credit card skimmer. This code actively listens for events that happen on the web pages and triggers an action whenever credit card details are submitted (event hijacking). As so, Magecart was able to intercept this credit card data that users were inputting in the checkout pages and send it to the hackers’ servers.

While the result of these attacks was the same, Magecart used distinct approaches: in Newegg’s case, it directly compromised the eCommerce website’s server; in all others, it compromised a third-party tool that they were using.

With so many unanswered questions surrounding these attacks, we decided to delve into the topic. In this article, we clarify what happened and what could be done to minimize the impact of these and similar attacks.

How Can the Source Code Be Modified?

One key aspect of every Magecart attack is their ability to inject their own malicious code into JavaScript code that is running (or being loaded) in companies’ websites.

While this may seem like a complicated task — given the variety of security systems that most companies have in place — there are actually multiple ways to modify code, either directly in the server or in intermediary services (e.g. CDNs).

Compromising the Server

The most direct way of compromising the source code is directly accessing the server and modifying the files there. This can be achieved by gaining access to the server (either using stolen access credentials or brute forcing the authentication mechanism) or by exploiting server vulnerabilities leading to Remote Code Execution (e.g. known CMS vulnerabilities, outdated components, vulnerable plugins, among others).

Compromising In-transit Code

While the code is being sent from the server to the website, it’s also susceptible to modification. This can happen via Man-in-the-Middle attacks (not very frequent now due to HTTPS adoption), subdomain takeover and web cache poisoning.

Cache poisoning is especially relevant, given that it targets Content Delivery Networks (CDNs), which are widely used nowadays. When source code is loaded from a CDN, an attacker can craft a request that tricks the origin into producing a malicious version of the script with the same cache key as an innocuous request. This script may get cached and served to end-users.

Compromising Repositories

Developers rely on an assortment of repositories during their workflow. While this is the status quo of the development process, it can also serve as a vehicle for injections. There have been cases of exploits in NPM packages (Node Package Manager) and Chrome Web Store extensions.

How Does This Compromise Companies?

Both Ticketmaster and British Airways were attacked via a third-party module. This is a very common scenario — these third-party modules are part of a typical integration scenario and are usually employed to add/extend functionalities. Analytics, Ads, and UX tools are some of the most widely used. Specifically, Ticketmaster was loading a module from company Inbenta, while British Airways was loading “Modernizr”, a JavaScript library.

When Magecart was able to inject their credit card skimmer code on these third-party modules, all websites that were loading them became immediately infected. As so, they started unknowingly serving the infected code to end-users, which could then steal their credit card data.

It’s here that we identify the major cause for concern: companies have had zero control and visibility over this code and that’s why it takes them several weeks — or even months — to identify these attacks.

The attack on Newegg had a different approach. It wasn’t due to a compromised third-party tool or library: Magecart managed to compromise the company’s server itself. Unlike the previous two cases, where the malicious code was being run in every web page, Magecart was able to inject the 15 lines of malicious JavaScript directly in the HTML of Newegg’s checkout page.

Even though Newegg is fully in control of this code, it still had zero visibility over the attack, that spanned for a full month. It’s likely that Newegg has several security systems in place, and yet they failed to prevent and detect the attack in a proper timeframe.

Prevention Strategies

After understanding how these attacks were perpetrated, it’s possible to identify some prevention strategies. Below, we highlight two security standards that should be considered against Magecart (and similar) attacks.

We will also detail how Magecart can evolve to become more dangerous and present a single strategy to address Magecart and “Magecart 2.0”.

1 — Subresource Integrity

A first security standard to be considered would be to add Subresource Integrity (SRI) attributes to the script elements loading the external scripts.

By checking the file integrity, the website will not load scripts that are different from the original ones. As so, malicious scripts won’t be loaded from third-parties. If we frame this to the Magecart attacks we analyzed before, we’re led to the conclusion that the third-party scripts would be stopped the minute they became compromised. Newegg’s case is different, as there was no script tag loading an external JavaScript re