[BreachExchange] The three steps required to shield your company from a Magecart attack

[Destry Winant]

https://www.itproportal.com/features/the-three-steps-required-to-shield-your-company-from-a-magecart-attack/

Magecart refers to a cybercrime syndicate that specialises in
cyberattacks involving digital credit card theft by skimming online
payment forms. Gaining mainstream media attention over the last year
or so, their most recent high profile attack was on photography
retailer, Focus Camera. Their website got hacked by Magecart attackers
who injected malicious code that stole customer payment card details –
the script loaded at checkout to capture billing information and send
it to the attacker's server. Focus Camera just added their name to the
growing list of well-known organizations that have fallen victim to
similar attacks (British Airways, Newegg, Macy’s) during the last
year, with hundreds of thousands of customers typically having their
card details stolen.

The Magecart credit card skimming approach is often to insert the
malicious skimmer’s code into their target’s third-party providers
(which has come to be known as web-based supply chain attacks). The
attack on British Airways, but also Equifax, Forbes and thousands of
others were all achieved via malicious code that was injected into
company websites via third-parties and then run in its users'
browsers. In this way, a company's website or web app has become the
perfect stage from where to steal customer data.

And let us not forget the huge financial downside for those companies
attacked. After the attack on British Airways for example, it was
announced that the Information Commissioner’s Office (those
responsible for upholding the UK’s information rights in the public
interest), announced their intention to fine British Airways (BA)
£183.39 million for breaches of GDPR. And whilst BA offered to
reimburse customers who suffered financial loss as a result of the
breach, they never actually admitted liability for this breach.
Reputational damage arising from such a high profile attack is
difficult to calculate and there are signs of ambulance-chasing
outfits seeking to reimburse those individuals affected – a kind of
PPI-style payout scenario. The stakes therefore, are very high.

So what can organizations do then in the face of such large-scale
attacks with such far-reaching consequences?

Uncover your security blind spots

If you are serving your customers via any kind of eCommerce platform /
website, then are you sure that the website content that your
customers are receiving is what you expect them to receive? That is to
say, is the website that your potential customers are interacting
with, a bona fide site and not one that has already been tampered with
by hackers? Typically, neither business owners nor security teams have
a definite answer to this question. A decades-long focus on
server-side security has resulted in mostly everything that happens on
the client-side (i.e. the browser and the environment where Magecart
attacks operate) going widely unnoticed.

Enough post-mortem analysis of Magecart attacks have been made that we
now understand that there’s no guaranteed way of preventing these
types of attacks altogether. We can, however, shift our attention to
what is happening on the client-side. If organizations still can’t
clearly answer the question of, “what code are my users receiving when
they visit my checkout page?”, then they have a massive client-side
security gap where Magecart thrives.

Understand and fill the client-side security gap

Not all Magecart groups use the same strategies to breach eCommerce
websites. Some opt for a first-party breach – either directly by
breaching the 1st party server, or indirectly by infecting code that
is later pulled to the server as part of the build process – but the
majority pursue an attack via third-parties, considered as the weakest
link. This weak link often refers to scripts that companies run on
their websites, such as live chat, widgets, analytics, or other
utilities – and so companies that use them actually have zero control
over their security. Because the attack originates from a source that
is trusted by default – a legitimate third-party supplier – this
malicious code easily bypasses firewalls. The enterprise should
definitely vet third-party code and their suppliers’ security (or lack
thereof). However, this often loses priority to product development.
The job ultimately falls to client-side security systems in place –
often sadly, none seem able to prevent Magecart.

Magecart attacks are growing more sophisticated with each iteration.
Recent versions of Magecart are using bot detection techniques to
avoid detection by some security solutions, making it even harder to
stop the skimmer in its tracks. Clearly, it makes sense that the way
we address these attacks evolves in a similar fashion.

Protect against future attack

The ongoing wave of Magecart attacks shows precisely just how
unprepared eCommerce businesses are, security-wise. Timing is key. If
eCommerce businesses gain the ability to detect Magecart in seconds
(rather than months), then we are looking at a decade where Magecart’s
headline-making days are numbered.

So what can actually be done to mitigate such Magecart style attacks?
Considering an evolving security mindset, instead of looking for a
solution that prevents un-preventable malicious code injections, the
enterprise should seek to be able to detect these injections and
quickly block Magecart attacks.

Third-party management and validation is a good start, but not enough.
Vetted scripts can change behavior, so the key is to only trust these
scripts if they don’t change their behavior. A live chat script has no
business touching the payment form. A script that never sends
information out should never be able to send data to an unvetted
domain. More than vetting the code, restricting these behaviors is
what makes a good defense, by employing a defense-in-depth strategy.

And this is where organizations are failing. Some Magecart attacks
have remained undetected for longer than 6 months and, as we learned
from the British Airways breach, it only took (allegedly) 15 days to
steal credit card details of over 380,000 customers. This makes it
very clear that organizations don't really have a way of knowing when
a malicious skimmer is running on their websites. And so this is the
issue that should be addressed most urgently – when a Magecart skimmer
somehow finds its way into a company's website, the company must be
able to instantly detect it, block the code, and keep its users safe.
To achieve this, organizations should put in place a web page
monitoring solution, so that they gain real-time visibility of
malicious code and pave the way to automating Magecart mitigation.