Magecart, a consumer payment credentials stealing operation, has been one of the most effective cybercrime attacks of 2018 and 2019. Often defined as a loosely coordinated group of hackers or as a particular exploit or attack, Magecart has managed to steal millions of consumer credit card information records across dozens of separate campaigns all against varying targets in the e-commerce market.
Magecart represents the popularization of a new kind of application security risk, one that is different from the traditional OWASP Top Ten risks, as the scope of the action moves from the server to the client.
This BORN SECURE post, along with an accompanying whitepaper, provides a technical introduction to the general client-side application security idea. In particular, we apply the techniques used by Magecart as a case study to show how to mitigate these generic types of client-side malware from an application security point of view. BORN SECURE has covered other important risks in detail such as Indirect Direct Object References (IDOR), Insecure Deserialization, and XML External Entity.
Client-side application security
The transition towards client-side apps
One of the differentiating factors of Magecart is that the main exploit takes place on the client-side. As more and more functionality moves to the client-side, including the processing of high-value data such as payment credentials, it should not come as a surprise that malware and malicious code has followed.
The main characteristic of this relatively new family of risks is that no data is directly taken from the target server. Rather, the breach is indirect and sometimes completely separated from the target server via a compromised external dependency. This happens mostly on the client-side, including traditional web browsers and API clients, such as mobile apps.
The main difference with similar Javascript injection risks such as XSS is that Magecart typically compromises the supply chain that the target server relies on, as opposed to the target server itself.
Legacy AppSec solutions are not enough
The client-side AppSec security market is immature and mainstream legacy application security tools are not well equipped to find, mitigate, and protect client-side risks.
One of the main reasons for this is that external code and dependencies (i.e. code that is not maintained by the organization) are often overlooked. This includes architectural frameworks, open-source components, and outsourced parts of the application.
Another reason is that in order to protect from client-side attacks, a continuous runtime approach is much more effective.
In particular, Static ASTs (SAST) that review the source code do not help once the application has been pushed to production because SASTs are only enabled to review a simple snapshot of your code. This means that if the application changes (either forcefully or according to its roadmap) after the scan, SASTs will not see those changes. These drawbacks also apply to Software Composition Analysis tools (SCAs) that find vulnerabilities in the dependencies of the application.
Dynamic AST (DAST) scanners present a different problem. DASTs focus on attacking the server infrastructure, but there is no emphasis on client-side risks. Due to this design, DASTs can’t help find risks that enable Magecart-type of attacks. A detection approach involves comparing snapshots of the site itself at regular intervals to detect changes in the HTML and JS, but this approach is not very practical due to the dynamic nature of most, if not all, sites.
Lastly, in terms of protection, Web Application Firewalls (WAF) have difficulties detecting the signatures associated with client-side vulnerabilities as their blacklists are quickly outdated, and the processing power to parse and analyze the code is immense and not-scalable.
Client-side browser malware case study: Magecart
Magecart is the most representative and successful family of attacks focusing on client-side execution. At Hdiv, we believe that other types of client-side browser malware will follow.
The goal of Magecart is straightforward. Instead of capturing personal data or stealing intellectual property, Magecart is purely money-driven. In particular, Magecart scrapes consumer-facing e-commerce sites to capture payment credentials including credit card numbers, holder names and addresses, and credit card security codes. Essentially, Magecart searches out all of the information required to process an electronic credit card payment.
As in most client-focused attacks, no server data is breached.
Magecart anatomy
The anatomy of Magecart includes three different subsystems and 5 main stages:
1. Magecart compromises code base
First, the “supply chain” of the application must be disrupted. This means that somehow the code that composes the targeted application and/or API must be compromised. This can be achieved in a variety of ways such as exploiting an XSS vulnerability to inject a Javascript reference. Another method is to breach the code repositories of legitimate third-party dependencies that the targeted system includes like Magento scripts.
2. Magecart scrapes and steals data
Once the malicious javascript code is injected into the target system, it will activate once the user is inputting payment credentials in the client browser. The code then scrapes these variables and communicates to a ring of hosts that receive the stolen credentials. The size of this injected code is very small, sometimes no more than 15/20 lines total.
3. Magecart collects and packages stolen credentials
Finally, the ring of hosts that receive the stolen credentials will consolidate and store the bounty. To avoid exfiltration protections, these hosts will appear to be part of the legitimate system, including domain names related to the target application and even valid TLS Certificates that make the exfiltration appear legal. As many as 500 sites affiliated with the Magecart collecting data network have been identified to date.
Notable Magecart campaign examples
Components of Magecart have been found across millions of websites and although not all of them have been successfully exploited, the potential of the strategy used by Magecart becomes more and more obvious.
- British Airways: one of the best-known cases, around 380K stolen along with payment credentials. The supply chain vulnerability seems to be related to XSS and it targeted the payment sections of the travel site.
- Ticketmaster: affected around 5% of customers. Magecart code was injected in the code base of an external developer for Ticketmaster, Inbenta, that provides a customer support chatbot.
- Newegg: scrapping happened in the payment system leveraging the same Magecart code found in the British Airways campaign.
Hdiv RASP client-side malware protection features
Hdiv Security AppSec approach
The protection philosophy of Hdiv Security is rooted in the idea that effective application protection should be holistic (protecting from all kinds of risks), automatic, developer-friendly, and based on positive models, as opposed to blacklist rules.
Hdiv Protection (RASP) protects against Magecart
Hdiv Protection (RASP) works during runtime as part of your application server infrastructure to protect from attacks to the vulnerable parts of applications, APIs, and microservices.
Implementing a runtime approach is crucial for the correct mitigation of Magecart-type attacks. This approach is deployed by an agent that instruments key parts of the execution flow.
Depending on the configuration of the system,Hdiv RASP has the capacity to not only monitor and detect the presence of Magecart code but to also block the attack from succeeding.
We can help
What is your experience with Magecart? Are you looking for an efficient way of securing your apps against client-side browser malware? Let’s talk! drop us a line at daniel at hdivsecurity dot com.