Why Magecart Continues to Succeed at Harming Companies
A group known as Magecart has come to light as companies such as Ticketmaster, British Airways, Newegg, most recently Sotheby’s and others have announced that their websites and/or applications were compromised. Like many of today’s advanced threats, Magecart is getting past traditional defenses. However, mechanisms are available that can help stop these attacks. So why aren’t companies putting the right defenses in place?
What’s New About Magecart Attacks
The fact that websites are being compromised—and that data is being breached—isn’t new. What’s new about Magecart is how the sites are compromised and data is exfiltrated. In a typical data breach, data is stolen from servers on the organization’s network. But in the case of Magecart, customer data isn’t being stolen from the servers. It’s being stolen at the point of entry—before anything suspicious hits the network layer and triggers traditional security defenses.
An attacker obtains write access to a web application’s source code by exploiting known vulnerabilities, or by using stolen or easily compromised credentials.
The attacker inserts a “digital card skimmer” in the web application’s source code. A digital card skimmer is script that steals payment information.
When a customer completes the payment form on the infected web application, the digital card skimmer downloads and executes on the client side. The script intercepts the customer’s payment card data and sends it to the attacker’s server. The rest of the transaction processes as normal. The business is paid, the customer receives their purchase, and both are none the wiser that a crime has been committed.
What’s the Problem?
While Magecart attacks are becoming more targeted (as in the case of British Airways), generic versions of the digital card skimmer have been detected on hundreds of websites. The problem is that traditional security solutions don’t detect or stop Magecart attacks. Traditional controls are insufficient because they only come into play at the network level — they haven’t adapted to new attack methods and they don’t protect client side and web app code right at the edge. Traditional security tools like Web Application Firewalls (WAF) and Data Loss Prevention (DLP) systems monitor the network for data coming out of the servers—not the client side. The tools that are used to secure code, like vulnerability scanners, are run at a point in time. But an attack that happens after code is deployed.
There’s also a general lack of awareness and knowledge about protecting client side and web app code. Companies tend to believe their assets are on the server, not the client. That’s just not the case. In fact, developers are executing more and more logic and sensitive data on the client-side of apps in an ongoing effort to improve the user experience and web performance. Even if it was true that all of the company’s assets are on the server, the client is where attacks begin. Client-side compromise leads to server-side impact, and server-side impact leads to customer impact.
Finally, there’s the issue of threat intelligence sharing within the security industry. Companies understandably need to manage their image and therefore share only what they have to by law. While legislation like the General Data Protection Regulation (GDPR) ensures timely notice to victims of a data breach, it doesn’t provide provisions for intelligence sharing. As a result, the technical details regarding attacks are scarce. The details that do emerge usually come from third-party researchers. We only know what we know about Magecart due to the efforts of RiskIQ, Veloxity, and others.
What You Can Do
As I said at the start of this post, there are technologies and methods that can help stop attacks that target web app code. First, we need to start treating the app like an endpoint. For all intents and purposes, the web app is the new endpoint. It’s the furthest connection to your assets, and that connection can be on hundreds of thousands of devices around the world. It doesn’t really matter how secure those devices are if your app is still vulnerable to code manipulation.
Treating an app like an endpoint means obtaining real-time awareness of threats and implementing adaptive security precautions. Organizations should have mechanisms in place so that the proper personnel are notified when attackers analyze their web apps, and automated responses are executed to make it harder for attackers to learn about the system. In addition, organizations should have mechanisms and controls in place that can identify code modification, notify the SOC, and mitigate the impact. The information learned from these attacks should be used to continually adapt the organization’s security strategy. Finally, organizations should make it a point to work with third-party providers who share the same mentality and approach to securing their code.
Organizations need to get smart about how they protect their client side and web app code. That’s really the only way we’re going to stop attacks like Magecart from taking down multiple targets. Apply the same approach we know is necessary for identifying advanced threats on the network to your client side: make security real-time and adaptive, and apply what you learn to an evolving security strategy.