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.
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?
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.
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.
By understanding the methodology of these attacks, it is possible to identify prevention strategies.
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.