Technical Insight

Stopping Magecart Attacks

There have been a few high-profile breaches in the news lately related to Magecart, including British Airways, Ticketmaster, and Feedify.  For those who don’t know, Magecart is a hacker group whose modus operandi involves skimming credit card details with code tailored to the sites they infect (there is, in fact, some discrepancy in the press on whether “Magecart” refers to the group itself, or to the group’s malware).

The general flow of the attack looks like this:

The attacker first purchases a deceptive domain name – let’s call my company BeckerWare.com, so the attacker might purchase something like BeckerWareInc.com, – and gets an SSL certificate for the domain -> hacker compromises server and installs malicious JavaScript in the page -> malicious code siphons off payment information every time someone checks out, and sends it, encrypted, to the malicious domain (BeckerWareInc.com).

How exactly the Magecart code was injected into the recent victims’ websites is not clear yet, but XSS attacks on someone within the companies is a very likely scenario.  Once in, they added lightweight JavaScript code to the page that had been tailored to their victim’s specific site. This JavaScript then diverted traffic to their fake domains, which likely wouldn’t be noticed by most users – especially since it happened in a background request.

What makes this attack so deadly is how invisible it was.  Since the code was injected in production, we can surmise that SAST scans or DAST scans on staging environments would have been too premature to detect it.

So how can you protect yourself against similar attacks?

First, the oldest advice still stands most important. Train your employees regularly on security awareness and put in strong safeguards within the company.  If your employees can recognize phishing attempts, then the hacker can’t even get past step one.

Access controls aren’t just to stop malicious employees – they are engaged to mitigate damage in the case of an attack. If an employee in HR is compromised, the production shopping cart code should still be safe, since that employee should not have access to changing that code in the first place.  Proper logging and log analysis can also help catch anomalies within the organization.

Another key point to maintaining controls at every point in the software lifecycle is that scanning of internal codebases is just as important as scanning external-facing code.  If you think of running DAST scans on your external-facing website as protecting your customers, then think of scanning internal tools as protecting your employees. Even employees who can’t recognize phishing attempts are still savvy enough to not give out credentials to strangers – that’s why step two in most attacks is designed to target a victim inside the company in attempt to get them to click an XSS-loaded link, or to get them to visit a malicious domain (or both.)  If your internal codebase is hardened against XSS and other common attacks, this becomes much more difficult for the attacker.

The second part to Magecart’s attack was offloading the stolen data to their “fake” website.  The only way to catch this after the fact is to examine suspicious outgoing connections when browsing the website – which is as frustrating and error-prone as it sounds. Some IPS/IDS/secure web gateways are set to do this, some are not.

Of course, the fool-proof (and probably simplest) way to protect against this is to configure strong Content Security Policy (CSP) Headers.  This header controls exactly which domains are allowed to communicate with your website and what they are allowed to do.  With proper configuration, this header can stop all XSS in its tracks, even if the code itself is vulnerable, by directing the browser to reject all JavaScript that isn’t delivered from the pre-configured servers. Even if your site was infected with the Magecart code, the browser would refuse to send the stolen data to the imposter website, thus completely mitigating the attack. I don’t want to promise that CSP is a silver bullet (if anything, proper employee training is,) but it’s at least a bronze bullet.

Tags: DAST, exploit, Retail, Secure Coding, XSS