Payment skimmers sneaking on to websites via third party code

With all the recent fuss about the alleged hacking activities of Russian intelligence, one could be forgiven for missing the unfolding story of ‘Magecart’.
It’s not clear whether Magecart is a loosely-affiliated cybercrime group or just the modus operandi of a few disparate cybercriminals using the same toolkit.  Whatever it is, it’s been blamed for several high-profile payment card breaches this summer, including TicketMaster.
In the latest development, security company RiskIQ says it recently stopped Magecart from pulling off a cyberattack that could have affected a sizeable group of companies using the Shopper Approved customer rating plug-in on their websites.
According to the company, attackers somehow compromised Shopper Approved’s servers to implant malicious JavaScript pointing to a domain under Magecart’s control. Why? To skim card numbers and data as it is entered by customers into payment forms.

Almost the perfect crime?

This is almost the perfect crime because the host website is unlikely to notice the skimming until defrauded customers (or a security company) tell them, not least because it’s inside a third-party plug-in.
RiskIQ says on 15 September it spotted the malicious domain which was also used in a recent attack on push notification service Feedify:

As soon as we detected the Magecart skimmer on Shopper Approved, we reached out to them via email, phone, and even LinkedIn to see if we could help provide them with information to remediate it.

The malicious code was removed two days later, after which Shopper Approved began its own investigation. Wrote co-founder Scott Brandley:

After a thorough investigation, we were able to determine that only a very small percentage of our clients were involved, and we have already reached out to those clients directly in an effort to help them remediate any issues.

As with previous Magecart attacks, the nerve-wracking question that should worry Shopper Approved and its clients is how long the script was in place before it was detected and whether this resulted in anyone losing money.

First they came for Magento

The incident highlights the size of the problem Magecart has become – according to RiskIQ, malicious code will continue to function after it has been removed if sites forget to flush pages cached through Content Delivery Networks (CDNs).
When Magecart was first noticed in 2015, it targeted smaller sites using Magento – these days it is not only aiming big but seems to have taken larger companies by surprise.
These companies are now increasingly prohibiting third-party code on sensitive pages to counter Magecart.
Site owners can also mitigate the risks of third party code by using the Content-Security-Policy header and Subresource Integrity validation.
And if you’re getting around problem of third party code by loading it all from your own, first party, domain, don’t forget that malicious code can also sneak on to websites at build time via supply chain attacks on package repositories.