Case Study

The Volusion Supply Chain Attack

In early September 2019, attackers modified a JavaScript library served by Volusion, an e-commerce platform provider, and added a payment card skimmer to it. By the time it was cleared on 10 October, 6,589 merchant stores were confirmed to have been serving it.

Not one of those 6,589 businesses was breached. Their vendor was. Their customers' cards were stolen anyway, and their brands carried it.

The same crew that took British Airways

Trend Micro attributed the attack to FIN6, which MITRE's ATT&CK catalogue lists under G0037 with Magecart Group 6 as an alias — the same actor behind the attacks on British Airways and Newegg.

Read those three pages together and there is a strategy visible. British Airways was one airline. Newegg was one retailer. Volusion was the conclusion that it is considerably more efficient to compromise the platform than to compromise its customers one at a time.

The same people who took British Airways decided it was cheaper to take your platform vendor instead.

- The pattern, from 2018 to 2019

How it worked

The modified library closely resembled the legitimate code, which is the reason a passing glance at it would not have helped. It loaded a second stage hosted on Google Cloud Storage, and the skimmed data went to volusion-cdn[.]com — a lookalike of the real CDN hostname, and the same typosquatting trick used against Newegg a year earlier.

What was taken was payment card data along with names and other personal information including phone numbers.

It was found by somebody doing their shopping

The compromise was spotted by Marcel Afrahim, a researcher at Check Point, who noticed it while buying something from the official Sesame Street Live store. It was not found by Volusion, and it was not found by any of the 6,589 merchants serving it.

For 6,589 businesses, the detection strategy turned out to be luck — that somebody with the right expertise happened to be a customer, and happened to look. It is worth asking honestly what your own answer would be if the same thing happened through one of your vendors tomorrow.

Unlike most of these stories, this one has a receipt

Most write-ups of an attack like this end at "data was exposed", which is easy to file away. This one does not. From November 2019, Gemini Advisory tracked 239,000 card-not-present records from the breach being offered for sale on dark web markets.

That is what the compromise of a single JavaScript library at a single vendor converted into.

Where it was visible

This attack is unusually well covered by the things a browser can see, which makes it a useful counterpart to the harder cases.

The second stage came from a host that had never served the checkout before, and the skimmed data went to another one. Both are new entries in an inventory of what a page loads and where it sends data — which is what Script Watch and Data Watch exist to surface, and neither depends on recognising the payload or knowing about the campaign.

Browsers already tell us the answer. With CSP Integrity, every script a real browser executes is reported to us with a content-addressed fingerprint alongside its URL — so the same address serving different code is a different fingerprint, arriving from the session where it actually ran. We keep a verified copy of each version in the JavaScript archive, which is why the question “what exactly was on the page at 14:00?” has an answer rather than a shrug.

If you are a platform rather than a merchant, the uncomfortable reading is the right one. Your customers inherit whatever your JavaScript does, they cannot see it changing, and they will be the ones explaining it. Shoptet and Paddle both run our monitoring across the stores they serve for exactly that reason.

How we can help

You don't need a mature Content Security Policy to start. Script Watch gives you the inventory of what executes on your pages, Data Watch gives you the destinations receiving data from them, and CSP Integrity adds the fingerprint of each script as it ran. One line of code or config to deploy.

Reach out to sales@report-uri.com if you want a demo or a trial with no commitment.

Script Watch

Script Watch will monitor all JavaScript dependencies across your entire site and immediately notify you of any changes. A new JavaScript dependency could be the start of a Magecart attack.

Because Script Watch leverages the browser native Content Security Policy, there is no code or agent to deploy and running in the browser means we analyse your site in real-time as your users are browsing. We don't have the same limitations as external scanning services such as authentication or pay walls, geo-sensitive content or an attacker potentially serving safe content to the crawler.

Data Watch

Data Watch will monitor all of the locations that your webpages are sending data to. If your website starts sending data to a new location, it could be the start of a Magecart attack.

With Script Watch and Data Watch combined, you can monitor for clear indicators that your site has been compromised. Attackers will always want to inject their hostile JavaScript, and they'll always want to exfiltrate their stolen data.

The CSP Wizard

We often find that creating a CSP is the first difficult step that organisations face. Having a complete list of all resource dependencies across your entire site like images, scripts or styles, from both 1st-party and 3rd-party locations, is tough to achieve.

The CSP Wizard was created to solve this problem, and in seven days or less, it can give you a complete list of all resources used across your entire site.

With the list of all resources you use on your site, and our easy-to-use tool, creating a viable Content Security Policy is easier than ever with just a few clicks.

Documentation

The CSP Builder

All Content Security Policies will need to be tweaked at some point. New resources may be added to the site or old resources removed, and the policy needs to be updated to reflect those changes and kept up to date.

You can import your existing policy into the CSP Builder and use our fully featured tool to make any changes that you require right there in the UI. When you're done, hit Generate, and the CSP Builder will provide you with your new, updated policy.

CSP Builder

Content Security Policy

Script Watch and Data Watch will allow you to rapidly detect and respond to a Magecart attack and combined, that capability puts you ahead of the field. If you want to take it a step further, Content Security Policy can mitigate a Magecart attack and stop it from even happening.

Deploying an effective Content Security Policy can be difficult, but our CSP Reporting allows you to gather feedback and safely test a policy before deployment. Once deployed, an effective Content Security Policy will block a Magecart attack and stop the hostile JavaScript from even running.

Threat Intelligence

We subscribe to various feeds of Threat Intelligence data, along with managing our own internally generated feeds, to keep apprised of the latest threats that exist online.

Using this Threat Intelligence Data, we can better analyse the sources of JavaScript on your website and detect malicious activity sooner.