Magecart 2.0: Architecture of a What-If
September 28th, 2018 | By Jscrambler | 8 min read
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.
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.
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.
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.
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.
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.
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.
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 allowlisted 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.
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?
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.
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.