The company said in a statement that it had received an incident notification on 15 September about a possible breach. On opening the URL mentioned in the notification, the Magecart skimmer was noticed in the code.
The attack was limited because of three factors, RiskIQ said:
- "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."
Since 2016, RiskIQ has publicised the spread of devices known as card skimmers — hidden within credit card readers on ATMs, petrol pumps and other machines where people paid with credit cards — to steal credit card data. The Magecart attack is the digital equivalent.
In the case of Shopper Approved, RiskIQ said the people behind the skimmimg attack had initially inserted the wrong code and later changed it so that their attack would work.
The security firm said it had informed Shopper Approved about the presence of the malicious code as soon it had confirmed it; it was removed on 17 September.
"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," RiskIQ said in its statement.
It also pointed out that there was a danger that websites which used a content delivery network for caching could continue to display such malicious code even after it was removed from the offending webpage.
"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 organisation is hit with a skimmer like this," RiskIQ said.
RiskIQ's Yonathan Klijnsma told iTWire in response to queries that Shopper Approved was running a custom software solution as it was a provider on its own, and not any of the common ecommerce software like Magento Commerce, Powerfront CMS or OpenCar.
Asked about possible attribution, Klijnsma said the attack on Shopper Approved was from what he called Magecart Group 5, which specialised in supply-chain attacks. Magecart was an umbrella term given to five separate groups carrying out these attacks, he added.
Klijnsma was asked why ecommerce sites had third-party code running on their sites, and whether it was cheaper to run such code compared to developing customised software.
He replied: "There is certain functionality they do not invest in, as it is not their primary business. They have their own supply chain just like any physical store. In this case, Shopper Approved is one of those suppliers. Sadly, Magecart Group 5 targets the supply chain exclusively."
Klijnsma said he had no knowledge about the entry point for the attack- whether it was a vulnerability in the ecommerce software or a flaw in the setup of the third-party code provider.
"From older research the operators use any method at their disposal to try and get in — credential re-use, outdated Web applications, or even outdated server installations. Anything is game for them as long as they get in," he said.