Over the last couple of months, there has been an alarming number of attacks on eCommerce and ticketing companies, with the resulting theft of customer credit card data. Those responsible for these attacks are a group of hackers called “Magecart”. In June 2018, the group attacked Ticketmaster and breached credit card data of some 40,000 customers; there followed two major attacks in September, which affected 380,000 British Airways customers and an unknown number of Newegg customers.
The modus operandi in these attacks was very similar: to inject malicious JavaScript code which could then act as a credit card skimmer. This code actively monitors events on web pages and triggers an action whenever credit card details are submitted (event hijacking). In this way, Magecart was able to intercept credit card data from customers in the checkout pages and send it to Magecart’s servers.
Pedro Fortuna, CTO, Jscrambler
Whilst the outcome of these attacks was the same, Magecart varied its approaches. In Newegg’s case, the eCommerce website’s server was directly compromised. In all the other cases, a third-party tool was compromised. There are many unanswered questions regarding these attacks. What happened exactly and what can be done to minimize the impact of these and future attacks?
“A key aspect of every Magecart attack is their ability to inject their own malicious code into the JavaScript code that is running (or being loaded) on a company’s website.”
A key aspect of every Magecart attack is their ability to inject their own malicious code into the JavaScript code that is running (or being loaded) on a company’s website. While this may seem like a complicated task — given the variety of security policies that most companies have in place — there are actually multiple ways to modify code, either directly in the server or via intermediary services such as Content Delivery Networks (CDNs).
The most direct way of compromising the source code is by 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 by brute force with the authentication mechanism) or by exploiting server vulnerabilities leading to Remote Code Execution (e.g. known CMS vulnerabilities, outdated components, vulnerable plugins, among others).
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 (rarer now due to HTTPS adoption), subdomain takeover and web cache poisoning.
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.
Content from our partners
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 typical integration projects and are usually employed to add or extend functionalities. Analytics, Ads, and UX tools are some of the most widely used. Specifically, Ticketmaster was loading a module from a company called Inbenta, while British Airways was loading Modernizr, a JavaScript library.
As Magecart was able to inject their credit card skimmer code onto these third-party modules, all websites that were loading them immediately became infected. As a result, they started unknowingly serving the infected code to end-users, which was then able to steal their credit card data. This is the major cause for concern: companies have zero control or visibility over this code which is why it takes them several weeks — or even months — to identify these attacks.
The attack on Newegg adopted a different approach. In this case, Magecart managed to compromise the company’s server itself. Unlike the previous two cases, where the malicious code was being run on every web page, Magecart was able to inject 15 lines of malicious JavaScript directly into the HTML of Newegg’s checkout page. Even though Newegg was fully in control of this code, it still had zero visibility over the attack that lasted a full month. Newegg probably has several security systems in place, and yet they failed to prevent and detect the attack in a proper time frame.
Prevention Strategies
By understanding the methodology of these attacks, it is possible to identify prevention strategies.
The first security standard to be considered should be to add Subresource Integrity (SRI) attributes to the script elements loading the external scripts. 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, resulting in frequent changes to JavaScript source code. Adapting SRI to match this dynamism can be a burden and, if SRI isn’t properly set up, it can block a perfectly safe third-party script, crashing the website.
The second standard is Content Security Policy (CSP).
CSP does have its limitations though and means new challenges ahead, such as being vulnerable to open-redirect attacks and requiring substantial configuration as well as maintenance; we have also seen strategies that bypass CSP altogether.
SRI and CSP should be considered, despite their drawbacks. Still, potential attacks featuring browser extensions as a vector for instance would be severely damaging to a wide number of eCommerce businesses, as SRI and CSP would be completely powerless to prevent them.
This leads us to a third security approach that is crucial — real-time monitoring of the client-side. This strategy focuses on providing complete visibility over the web page served to the end-users in real-time. So, whenever a threat is detected, this security system immediately notifies the website owner, giving precise information about the content and location of the malicious code.
The technology behind Jscrambler’s Webpage Integrity enables real-time monitoring and detection of Magecart and numerous other threats, including completely new exploits, 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 new attacks that go through the client-side won’t live long enough to make any headlines.
