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 resource: the script tag was added by the attacker.

However, SRI comes with a major pitfall: it’s notably complex to apply to dynamic code. And, as you may expect, most of these providers (like Inbenta) keep improving their services, which results on frequent changes to JavaScript source code. Adapting SRI to match this dynamic nature can be burdensome and, if SRI isn’t properly set up, it can block a perfectly safe third-party script and break the website.

2 — Content Security Policy

A second standard is Content Security Policy (CSP). CSP limits the external sources to which a website can connect. Trusted sources are whitelisted and every other connection is blocked.

CSP is commonly used to mitigate XSS and can be employed along with SRI to prevent malicious (external) scripts from being loaded.

Newegg’s incident would have been mitigated if a CSP was in place, disabling unsafe inline scripts and/or restricting allowed origins to retrieve resources from and/or send data to.

Still, CSP also has some limitations and brings new challenges, such as being vulnerable to open-redirect attacks and requiring substantial configuration and maintenance; we have also seen strategies that bypass CSP altogether.

Magecart 2.0 — A Very Real “What If”

All things considered, both SRI and CSP should be regarded for preventing malicious code injections.

But everything goes South when we add browser extensions to this equation.

Even if SRI and CSP were able to protect the website without breaking it, a simple browser extension can completely bypass these secure headers standards by stripping them. In recent news, we’ve seen cases such as the hacked MEGA extension, that show us just how powerfully damaging extensions can be.

Malicious extensions exploit the permissive nature of web browsers and become capable of modifying the webpage’s DOM during runtime.

Last year, at Jscrambler, we actually created a malicious browser extension and published it to the Chrome Web Store as part of our research. We made sure that its code wasn’t able to actually hack anyone — but the point is that the extension passed all security checks and was publicly available for download.

So far, Magecart has been using complex approaches and injecting their credit card skimmer in third-parties or directly in websites’ source code — and, as we’ve detailed, SRI and CSP could somewhat help prevent this. However, if Magecart starts using browser extensions as an attack vector (if they aren’t already doing it), SRI and CSP become absolutely powerless.

In an effort to show just how likely this is, we combined the intelligence we have over both the Magecart modus operandi and the malicious code of the MEGA extension to create a Magecart extension — Magecart 2.0.

On the image’s left side, we see the code for the malicious MEGA extension; the right side details a Magecart 2.0 extension. This approach is extremely simple and surely within reach of the hacker group.

The malicious MEGA extension was damaging enough by stealing passwords of 1.6 million users. What if an eventual Magecart 2.0 reached the same 1.6 million users and was able to steal credit card data in every eCommerce website they visited?

Mitigating Magecart and “Magecart 2.0” with Real-time Monitoring

This leads us to a third security approach — real-time monitoring of the client-side.

This strategy is substantially different from SRI and CSP. It focuses on providing complete visibility over the web page in real-time. So, whenever a threat is detected, this security system immediately notifies the website admin with precise information about the content and location of the malicious code.

That is precisely what Jscrambler’s Webpage Integrity achieves: full visibility over the website’s client-side and the capability to react in real-time to these threats.

In all the attack scenarios we covered so far, Webpage Integrity would effectively detect the injection the moment it happened, and empower companies to respond to the attack when it was first seen, preventing further losses. Unlike SRI and CSP, it can handle the dynamic nature of code, is simple to set up and maintain, and will not break the website.

Because Webpage Integrity monitors all threats to the client-side, it is able to extend its protection to more than credit card data theft: it effectively provides protection against MitB Trojans, Bots, and Zero-Day Threats.

Final Thoughts

The recent (and likely ongoing) wave of Magecart attacks comes to show how eCommerce businesses are severely unprepared, security-wise.

Approaches such as SRI and CSP should be considered, despite their drawbacks. Still, Magecart 2.0 — potential attacks featuring browser extensions as a vector — would be severely damaging to a wide number of eCommerce businesses, as SRI and CSP would be completely powerless to prevent it.

Jscrambler’s Webpage Integrity enables real-time monitoring and detection of Magecart, a potential Magecart 2.0, and numerous other threats, empowering companies to react immediately.

Timing is key. If eCommerce companies start detecting Magecart in seconds (and not months), Magecart’s days are numbered and Magecart 2.0 won’t live long enough to make any headlines.

Originally published at blog.jscrambler.com.