Published on August 26th, 2019 📆 | 2107 Views ⚑0
Five strategies to stop Magecart
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.
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
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
Security Policy (CSP)
CSP limits the external sources to which a
website can connect, by whitelisting trusted sources and blocking every other
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.
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.
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.
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
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
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.