This post is from the Arxan blog and has not been updated since the original publish date.
How to avoid being the next Magecart victim
Earlier this year, TicketMaster reported that its customer data had been breached due to a partner company being attacked. On September 6th, British Airways disclosed it had been attacked, that the information of some 380,000 customers who used the BA Website and application had been compromised. Just weeks later, Newegg confirmed they had been compromised in the same way.
Through research conducted by RiskIQ and Volexity, it has been discovered that these attacks are part of a long-running cybercrime campaign by a threat group dubbed ‘Magecart’ which encompasses several sub-groups operating in similar ways.
What is a Magecart attack?
Here's a quick recap of how a Magecart attack takes place (based on the research cited above):
- The attacker gains write access to source code which is included in the web application. The method of gaining initial access varies from using stolen or weak credentials to compromising known vulnerabilities.
- The attacker inserts a ‘digital card skimmer.’ This component — a script that steals payment information — is inserted into the front-end of a target web application.
- The script intercepts customer payment data and sends it directly to the attacker. When a customer completes a checkout or payment form within the infected web application, the script is downloaded and executed on the client-side, sending customer payment card info to the attacker’s servers.
Generic versions of this card skimmer have been found on hundreds of websites, but recently the attacks are getting more targeted, and therefore harder to detect, as in the case of British Airways. As with every new or evolved attack method, the burning question is always: how can we protect ourselves and our businesses from these attacks?
First, we should examine the reasons why traditional security measures were ineffective in this case. Traditional security tools such as Web Application Firewalls (WAF) or Data Loss Prevention (DLP) systems look at data coming in and out of your servers via your network. They do not ensure the front end of your application has not been co-opted. The web app code itself is left unprotected. And, security tools in place do not watch what the browser sends to other websites. Regardless of the initial infiltration method, Magecart changes the code of the web app, making the end user’s browser send credentials directly to the attacker’s website. The data “exfiltration” happens before the data even goes through the network or the server.
Many of the known security best practices still apply to websites and infrastructure. Using strong authentication (preferably 2FA) and patching software are necessary. It is also common knowledge that businesses must employ a layered approach to security. Furthermore, putting checks and balances in place will limit damage if an attacker gains access to a system. Unfortunately — as was the case with TicketMaster, British Airways, and Newegg — attacks are often detected weeks, months, or years after the initial breach takes place.
With Magecart, detection time is critical: the longer a skimmer is active on your website, the more customers are impacted, and the greater the damage that’s done to the business.
Organizations need to have layered security already in place, but they also need to have the ability to quickly detect and remediate any breach that occurs. Discussions of the Magecart attacks have been surprisingly absent of clear detection and mitigation methods so far. For those reasons, let’s dive into what businesses can do to detect — and stop — Magecart and Magecart-similar attacks.
How to protect against a Magecart attack
Step 1: Detect targeted attacks before they begin
During the attack on British Airways, Magecart actors registered a baways.com domain first. This domain was used to collect card details sent from the British airways card skimmer a full six days before the skimmer itself started working. Based on this intelligence gained by website reconnaissance, the skimmer was then custom-fit to the specific payment form used on the BA website and app.
All of these steps point to a highly targeted attack: the Magecart actors had access to the site for some time. They were also able to identify how the website is structured, how to collect the information they desired, and how to hide their presence.
The data collection or reconnaissance phase of an attack represents a great opportunity for organizations to get ahead of threats, yet often it gets ignored. Here’s what you can do at this phase to protect your organization:
- Use obfuscation mechanisms to make your web applications harder to analyze.
- Get notified when potential bad actors perform dynamic analysis of your app.
- Create a remediation scheme when policy violations are detected so that appropriate action is taken to mitigate the risk of transactions performed from risky sources.
The most critical benefit here is advanced notification. This window of opportunity tells you who has compromised your system, and who is planning to do so. When implemented properly, these methods work well even in an environment already compromised by attackers.
But what if an attacker does manage to learn your app structure and inject a correctly-crafted skimmer into a page that collects sensitive data?
Step 2: Detect unauthorized changes to your app
The Magecart skimmer is a simple script: just a few lines of code injected into a payment form or a supporting resource. The attacker made a change to the app — and yet, the change wasn’t detected in time to stop an attack. It can be argued that not enough emphasis is being placed on defending the application from modification on the front end — especially as more logic and sensitive data is executed on the client-side of apps in order to deliver better web performance for customers.
The performance of your website has clear implications on customer experience, but the integrity of your website is just as critical to your business, as this recent wave of attacks have shown. In order to ensure bad actors are unable to compromise your website, or to inject a card skimmer into your app, your code must be able to protect itself. This goes beyond ‘secure coding:’ the application must be protected in a way that guarantees every single piece of functionality was inserted by your developers, not by someone else.
An effective strategy of this type involves a variety of protection mechanisms, from checksums and code tampering protection to detecting DOM tampering. These options work in real time to identify code modification, notify the organization, and help mitigate its impact. They also complement and protect each other, true to a layered security approach. If attackers have figured out your obfuscation technique, or managed to bypass the integrity checks, they will still trigger the other protection mechanisms multiple times along the way. These mechanisms give you a roadmap to the attackers’ strategy and alert you to the information they might be after.
Step 3: Alert, respond, adapt
Each of the protection mechanisms above is useful, and together they are extremely powerful. But the key piece in implementing a truly adaptive security system continues to be visibility. You must know what attackers are doing in your system in order to take action. Preventing debugging and analysis, and automatically repairing the script that gets modified, are not enough.
Closing the loop so your security can adapt to zero-day threats means having notifications on reconnaissance, tampering attempts, and analysis tools — and integrating those into your SOC systems. You probably already have a way to monitor who’s testing your firewall and who is trying to compromise your endpoints. Maybe you’re even checking for SQL injections and suspicious pattern of data access. If you add the visibility you get from monitoring your web and mobile applications, you can understand your risks and respond better to real-time, in-the-wild threats. By using tailored automatic capabilities you will be adapting your defenses over time to new risks.
Step 4: Handle third-party code correctly
While third-party code does not represent the full scope of the Magecart problem, it does have the potential to be a greater risk. First, it is much more difficult, if not impossible, to scrutinize someone else’s code. Also, a single compromised organization can have a knock-on effect and impact many others — an effect which may not be visible to you.
Researchers such as Kevin Beaumont have pointed out that organizations should be careful about partnering, and understand the risks introduced by third-party code. However, many organizations may not be equipped to assess these risks, and sometimes may face the decision between unknown risks and a missing critical functionality.
The good news is that you can use the tactics described above to protect third-party code running on your website. Every technique mentioned above is applicable to code from partners and even open-source libraries. Security experts are correct, however, that you should choose your partners carefully. One way to do this would be to inquire if they protect their code the same way. A vendor that wants to run code on your website should be diligent about their security practices. When someone else’s work is running on your servers, that work reflects on your organization and impacts your customers.
Vendors of third-party libraries — UI, analytics, utilities, (obviously) security, and others — may want to learn from the Magecart attacks and find better ways to protect their software as well, because malicious code injected into their library may impact the customers of many different organizations, as well as their own business.
The recent wave of Magecart attacks is placing a stronger emphasis on what we already know — software vulnerabilities, incorrect configuration, and other holes in defenses are not going away, and attackers can use your own software against you and your customers. While existing best-practices continue to be relevant, there are additional security mechanisms you can use to address the specific attack vectors used by Magecart and similar actors:
- Increase the amount of effort required to target your application by preventing analysis of your code to stop attacks before they begin.
- Detect unauthorized modification of your code, and react to it.
- Correlate application events into your larger security picture.
- Partner with third-party vendors who are likewise committed to proper security practices.
Digital.ai Application Protection for Web, formerly Arxan, allows you to protect your web application from Magecart, as well as many other types of attacks. You can apply protection seamlessly and have it run as part of your CI/CD infrastructure. To learn more, contact our team.