Over the past several months, we’ve published four reports on the digital credit card-skimming activities of Magecart—mainly regarding significant breaches like Ticketmaster, British Airways, and Newegg. In every publication, we noted that the six groups under Magecart have ramped up their operations, becoming more clever, and in many cases, sophisticated, with each attack.
However, a particularly problematic aspect of Magecart activities is that due to a general lack of visibility into the code running on most e-commerce sites, site owners and consumers are generally unaware when the third party’s code on that checkout page into which they’re entering their payment information has been compromised with Magecart’s skimming code.
In this blog, we’re disclosing what could have been another sizable Magecart attack against Shopper Approved, a customer rating plugin that integrates with thousands of e-commerce sites, had it not been for a few recent industry trends and fast detection and notification by RiskIQ. Below, we’ll provide analysis of this new attack and provide detail of when the Magecart attackers added the skimmer, where they added it, and the scope of affected websites.
Similar to the attack against Ticketmaster, this attack did not impact a single store directly. Instead, it attempted to skim payment information from multiple online stores at once by compromising a widely used third party. In this case, the actors compromised Shopper Approved, an organization that provides rating seals for online stores.
Early on the morning of September 15th, RiskIQ received an incident notification regarding Magecart. Although we’re notified hourly, this domain (and affected URL) caught our eye. Here is the incident detailing:
Opening the associated page in the crawl data, we immediately see the Magecart skimmer in the code. Here is what the normal certificate.js file for Shopper Approved looks like:
Here is the same script but with the Magecart skimmer added from our incident:
An interesting aspect of this attack is that the above screenshot is not what the skimmer looked like when the actors first put it in—they made a mistake! At 04:35:07 GMT on September 15th, the actors modified the certificate.js script to include the skimmer, which looked like this afterward:
Almost 15 minutes later, the actors came back at 04:49:59 GMT and modified the script again to make it look like the one shown in the screenshot before. They forgot to obfuscate their skimmer the first time, a small mistake, but it allowed us to view the clean skimmer code, which is a good reference point.
One other thing to note is that recently Feedify was also compromised, and a skimmer was also placed in their scripts that used the same drop server (where the cards are sent off to) as the one used in the Shopper Approved attack: info-stat.ws.
Outreach & Cleanup with Shopper Approved
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.
On Monday, September 17th at 15:03:01 GMT, the skimmer code was removed from the site-seal script. Since then, we have been in frequent contact with Shopper Approved, which launched a full-scale internal investigation in addition to engaging a leading forensics firm to help find out exactly how this happened and who was affected.
One thing to note is the affected website count. While Shopper Approved is active on thousands of websites, only a small fraction of their clients were impacted. We believe three key factors contributed to this limited impact:
- More and more prominent shopping carts, such as Shopify and BigCommerce, are actively blocking third-party scripts from being allowed to display on checkout pages.
- Most Shopper Approved clients did not have the impacted script on their actual checkout pages, and
- The skimmer code only looked for checkout pages with specific keywords in the URL and did not impact pages that did not include those keywords.
We’d like to note one final concern, the awareness of which can help limit the scope of future Magecart attacks. Many websites use CDN services for caching, and we’ve noticed that often the skimmer code will be cached in the CDN and stay active there long after the skimmer is cleaned up from an affected site. As a site owner, be sure to purge any caching you are performing after your organization is hit with a skimmer like this.
Prior to publishing our findings, Scott Brandley, co-founder of Shopper Approved, provided the following remarks:
“On behalf of Shopper Approved, I want to personally thank the RiskIQ team for the diligence and incredible effort they’ve taken in helping us detect and secure our code in such a short amount of time,” said Shopper Approved co-founder and CEO Scott Brandley. “It is rare when you find a company like RiskIQ who genuinely helps people simply because it is the right thing to do. RiskIQ helped significantly limit the impact caused by Magecart – and for that, we will be forever grateful.”
Magecart groups are carrying out a full-scale assault on e-commerce and show zero signs of stopping. These attacks are only getting more and more traction as the groups learn how to become more effective. While initial attacks involved low-tier Magento stores, later attacks targeted CDNs to increase their reach. Now, Magecart operatives have learned to tune the CDNs they compromise to ensure that the only sites they hit are online stores. To achieve their goals, they will go after any analytics company, CDN, or any service supplying functionality to e-commerce websites.
Word to the wise: if you own an e-commerce company, it’s a best practice to remove the third-party code from your checkout pages whenever possible. Many payment service providers have already taken this approach by prohibiting third-party code from running on pages where customers enter their payment information.
We are keeping a very close eye on the activities of the Magecart groups and will continue to report publicly on them.