[BreachExchange] Common misconceptions about the rise of Magecart attacks

[Destry Winant]

https://www.techradar.com/in/news/common-misconceptions-about-the-rise-of-magecart-attacks

How time flies. Just this week I realised that the British Airways
breach (probably the de-facto poster child of Magecart attacks),
celebrated its 2 year anniversary. But even before the BA breach, I
had been investigating the advanced tactics that cyber criminal groups
use to infiltrate the client-side of websites.

Web skimming is a prime example of a highly effective attack. It’s no
wonder then that so many different groups follow the Magecart modus
operandi. Since the BA breach, I’ve analysed over 65 high-profile web
skimming attacks that affected thousands of different companies.
Worryingly, Magecart shows no signs of slowing down.

But today, fortunately, we know a lot more about web skimming attacks
than we did in 2018. So, in order to prepare businesses to be able to
properly handle this threat, I thought I’d present 5 of the biggest
misconceptions surrounding Magecart attacks.

Magecart only attacks Magento-based websites

At first glance, many make the connection between Magecart and Magento
- the Content Management System widely used in E-Commerce shops.
Indeed, the Magecart name was probably first coined because the
cybercriminal syndicate initially focused on Magento-based stores.
These were typically very poorly configured security-wise, with
default passwords galore and a lack of software updates. Those days
are far behind us. Today, industry associates Magecart with any web
skimming attacks that originate on any website and from any
third-party. As long as the attacker manages to inject the web skimmer
into the website, it’s good to go. And a new Magecart attack is born.

Magecart only attacks big websites

At the risk of repeating myself, Magecart attacks can target any
website. Most of us have heard of the high-profile breaches on
well-known names such as Macy’s and Warner Music Group. However, most
Magecart groups aren’t launching highly targeted attacks on specific
companies. And even those who are may end up infecting hundreds of
websites in a single attack, as they mostly go after the dependencies
and third-party code that is used by large, medium and small
companies. When Magecart casts its net over the web supply chain, it’s
typically aiming for both big and small fish alike.

Your website is not at risk if you develop and maintain it internally

There’s often the argument of “we develop everything in-house”, which
leads to the idea that your team controls every single aspect of your
website. However, today’s typical web application contains a huge
mashup of client-side code. According to recent stats, two-thirds of
the scripts used on the average website come from third-parties. Plus,
the development of these platforms typically integrates frameworks and
libraries that contain dozens of pieces of third-party code of their
own, creating a long chain of code dependencies. And each instance of
third-party code presents attackers with another possible way in. And
even in those rarer cases where the company is self-hosting everything
and has minimal reliance on third-party code, it’s still at risk.
There have been multiple instances of first-party Magecart attacks,
and those too remained undetected for weeks.

Magecart attacks can be mitigated with a Web Application Firewall

This is another misconception. Web Application Firewalls (WAFs) are
widely used to monitor and protect the network, blocking unknown or
untrusted connections. However, much like server-side defenses, a WAF
doesn’t detect whatever is happening on the client-side. And since
Magecart attacks originate from a source that is trusted by default -
a legitimate third-party supplier or a piece of first-party code - the
malicious web skimming code easily bypasses WAFs.

CSP and SRI are the way to go if you want to prevent Magecart attacks

I saved this one for last because it’s certainly the one I hear most
often. Content Security Policy (CSP) and Subresource Integrity (SRI)
are two techniques that are commonly employed to minimise exposure to
data exfiltration and third-party attacks. However, we now know that
these approaches aren’t the right answer to fight off Magecart. While
CSP does limit the external sources to which a website can connect, it
can be bypassed, allowing attackers to exfiltrate credit card details
anyhow. SRI adopts different tactics - it enables the website to block
external scripts when their file integrity changes. In this way, the
script would be blocked after the skimmer was injected. However, the
big downside to SRI is that it’s very challenging to get right and
ends up being a very high-maintenance solution that companies tend to
avoid.

I’d like to be able to say that these are the only misconceptions on
the topic of Magecart - sadly, there are still many more. On the flip
side, industry has learned a great deal about these attacks in the
past few years and we know that one of the most effective Magecart
mitigation strategies is detecting and blocking malicious client-side
behaviors in real-time. As more and more companies understand the need
for this new layer of client-side security, I’m confident that
Magecart’s days are numbered.