For decades, companies focused their security budgets heavily on protecting their servers against intruders. Everything inside the firewall became sacred ground, especially after GDRP brought forward record-breaking fines for data breaches.
But the past months brought forward a new threat that is catching small and large corporations alike unprepared: Magecart. As attackers evolve their M.O. to avoid having to penetrate companies’ firewalls, they identified that companies have spent little effort in securing the client-side of their web applications. This growing wave of Magecart credit card skimming attacks has proved time and time again how even large corporations like British Airways or Forbes can fall prey to client-side attacks.
The success of these Magecart campaigns comes from attackers picking the weakest link of a web supply chain: infecting third-party code suppliers rather than infecting target companies’ own code. With this methodology, attackers breach a small company with lesser security and inject their malicious code into a script that is sourced to multiple other companies. Think of an analytics service or even a live chat feature as examples. When these companies downstream in the supply chain are compromised, the malicious script is integrated directly into their scripts, and they immediately start serving it to their own end-users.
The recent British Airways $240 million fine following a Magecart attack put companies on alert. Now they are seeking to learn what they can do today to prevent these attacks, as protecting the server and its periphery are not enough. Within this scope, we can highlight five major steps enterprises can take now towards mitigating Magecart web supply chain attacks.
Webpage Monitoring
A post-mortem analysis of Magecart attacks to date highlights a common metric that severely increased their dimension: the very long time between infection and detection. The Ticketmaster Magecart attack remained under the radar for five months, and newer Magecart web supply chain attacks such as the one on Amerisleep and MyPillow took two months to be discovered.
Clearly, companies have zero visibility over what’s happening on the client-side of their websites. A Magecart attack is based on malicious code that grabs the credit card details that users input on a checkout page - which means that the malicious code runs on the web page without companies or users being aware.
In the current panorama of application security, there’s no infallible way of being sure malicious code or markup isn’t injected into companies’ applications. The next best thing is to gain visibility about malicious injections and be able to react in real time.
A web page monitoring solution detects any tampering to the web page independently of its delivery mechanism. As such, it detects in real time when any malicious code is injected into a web page. Some more advanced solutions can even block the attack altogether. This dual approach is a major line of defense against web supply chain attacks like Magecart.
Content Security Policy (CSP)
CSP limits the external sources to which a website can connect, by whitelisting trusted sources and blocking every other connection.
The success of Magecart attacks depends on sending the skimmed data to attacker-controlled servers. At first sight, CSP appears to solve this problem by blocking the external address to which attackers were sending stolen data. However, despite its ease and effectiveness, CSP presents some limitations, such as substantial configuration and maintenance, and the fact that it can be bypassed, namely when Man-in-the-Browser (MitB) trojans and browser extensions are used as an attack vector.
Subresource Integrity (SRI)
SRI checks the integrity of files, enabling the website to block external scripts when this file integrity changes, like what happens when attackers inject malicious code into the scripts. In the scope of Magecart, this can potentially be used to block third-party code that contains credit card skimmers.
However, SRI also comes with some drawbacks. Most third-party script providers keep improving their services, which results in frequent changes to the script itself. Adapting SRI to match this dynamic nature can be challenging and can result in blocking perfectly safe third-party scripts when they receive much needed updates. Also, SRI can be bypassed when a Man-in-the-Browser trojan is used as an attack vector.
Limiting Third-Party Code
While today it’s inconceivable for a modern web app to abstain from using third-party code, this still is the most straightforward approach to prevent Magecart web supply chain attacks altogether. Businesses should take a lean approach to using third-party code, identifying what is crucial to the business and what may be developed internally, with special focus on avoiding risky or deprecated scripts.
Assessing Third-Party Suppliers’ Security
Even considering the many benefits of a leaner approach to using third-party code, at the end of the day, enterprises will still need to rely on crucial services such as analytics, ads or accessibility services. This doesn’t mean, however, that organizations should lose control over this.
A suitable approach is to assess the security level of third-party suppliers during the procurement phase, especially looking at how they protect their code, their servers and the communication with external sources.
In conclusion, these strategies individually will each have their own shortcomings and may not be the complete answer towards preventing a Magecart data breach the size of British Airways. As companies up their security game on the client-side, the most advisable form of Magecart mitigation is a combination of the strategies defined above.
As far as financial penalties go though, British Airways is just the tip of the iceberg. We can expect to see many other heavy new fines for the thousands of other Magecart-related data breaches.
It’s time for everyone to make this a top level priority and to gain full visibility and secure their web supply chain.
