The Magecart saga continues

The Magecart saga continues

Last month we learned about another unfortunate victim of the Magecart hacking group, Newegg.com. For over a month, Newegg customers had their credit card information skimmed whenever they made a purchase on the Newegg website. The attack was facilitated by malicious code inserted into Newegg’s own JavaScript. For a detailed explanation of how the attack worked, check here.

What should we learn from this attack?

Modern websites are made up of many cloud services and external code libraries - and this is a good thing. Cloud services and third-party code provide advanced functionality like personalization, optimization, and chat that greatly improve consumer experience. These are services that few companies outside of Amazon can afford to develop and maintain in-house.

Today, it is not uncommon for a single website to be made up of code that is created and operated by as many as 50 different companies.  Code that is developed in-house and runs on your own website is called 1st party code. Code that comes from other companies is called 3rd, 4th, or even 5th party code.  At Instart, we are seeing more and more websites where as many as 75% of calls made by the browser are from sources other than your company.

So the question is — how do you really know what’s going on when your website is relying on code from 50 different cloud services, hosted by 50 different organizations?

This is the trap that many retailers have fallen into. Leveraging many services to deliver a content rich experience to your customers is great until one of your trusted partners is compromised. A vulnerability anywhere is a vulnerability everywhere. What’s the good news? If you can improve control (actual control) and visibility into all your code and content — 1st party, 3rd party, and so on - then you can protect your customer's information. The key insight is that all of this code only comes together when it is assembled in the consumer’s browser.  So if you cannot see and control what is going on inside the consumer browser, you are vulnerable.

And unfortunately, all of this code is able to access valuable information about your customers and their transactions, and to exfiltrate this information elsewhere for malicious use. This new attack by Magecart shows us that 15 lines of code can steal hundreds of thousands of credit cards. But it also shows us that your vendors’ code can be used as an attack surface into your site.

How often do you review what code is actually executed on your customers' browsers? This is an impossible task — the only option is to understand and control what’s happening in your customer’s browser when they visit your site.

The future of Magecart & other attackers

It is easy to imagine a world where Magecart compromises several different sites simultaneously via a 3rd party JavaScript file, transforming it into a 4th or 5th party attack that is even harder to detect and prevent. As a result, many more customers would have their data stolen, and the brand damage to both the firms whose customers were compromised and the third party who was initially attacked would be severe. Think Equifax — but with consequences.

Because of the complexity of this interwoven web, trying to defend yourself by ensuring that none of your servers, none of your 3rd party partner servers, and none of their 3rd party partners get hacked is not feasible. Instead, only by gaining visibility and control into all the content that is assembled in the browser can you detect and prevent these types of attacks.

How to protect your website and your customers' data

Cloud services like Instart, which enable you to gain visibility and control into all the 1st, 3rd, 4th, and 5th party code that is assembled in the browser, will help you:

  • Understand which scripts actually load on a customers browser and which piece of code eventually loaded Magecart’s attack snippet — and then remember how the code got there.
  • Prevent exfiltration of customer data by preventing the Magecart code from connecting to the data exfiltration site
  • Block 3rd party services from running if they have been compromised, or prevent these services from accessing secure fields and exfiltrating data
  • Understand which scripts cause performance issues at the browser for customers

Instart maintains a presence in both the cloud and the browser, therefore we receive telemetry from the browser regarding exactly what scripts are running, how each script is initiated, and where each script is trying to communicate to. We also provide control of these resources, with the ability to allow individual JavaScript calls, defer them, or block them all together.

Takeaway

You need visibility into what is happening in your customer’s browser. Ideally you should also know what all of the code on your site is doing — why is it there?.  3rd, 4th, and 5th party services make that difficult, however, Magecart’s most recent victim shows us that some companies don’t even know what their 1st party code is actually doing. Having visibility and control into all resources that make up your website from the perspective of the consumer browser is the best way to prevent attacks like this.