Security Market Segment LS
Wednesday, 10 October 2018 06:21

Shopper Approved latest target of data skimming attack

Shopper Approved latest target of data skimming attack Pixabay

Security firm RiskIQ has discovered another case of a site breach by the group Magecart, this time against Shopper Approved, a customer rating plugin that is used on thousands of ecommerce sites.

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.

The Magecart group has been claimed to be behind breaches of the British Airways and Ticketmaster UK websites earlier this year. In the case of BA, it disclosed last month that the financial and personal details of 380,000 customers had been stolen from its site.

Ticketmaster reported a breach in June, and blamed a third-party supplier, Inbenta Technologies, for the incident. Inbenta, in turn, said that the breach had been caused by Ticketmaster directly applying a customised piece of JavaScript without notifying its (Inbenta's) team.

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.


26-27 February 2020 | Hilton Brisbane

Connecting the region’s leading data analytics professionals to drive and inspire your future strategy

Leading the data analytics division has never been easy, but now the challenge is on to remain ahead of the competition and reap the massive rewards as a strategic executive.

Do you want to leverage data governance as an enabler?Are you working at driving AI/ML implementation?

Want to stay abreast of data privacy and AI ethics requirements? Are you working hard to push predictive analytics to the limits?

With so much to keep on top of in such a rapidly changing technology space, collaboration is key to success. You don't need to struggle alone, network and share your struggles as well as your tips for success at CDAO Brisbane.

Discover how your peers have tackled the very same issues you face daily. Network with over 140 of your peers and hear from the leading professionals in your industry. Leverage this community of data and analytics enthusiasts to advance your strategy to the next level.

Download the Agenda to find out more


Sam Varghese

website statistics

Sam Varghese has been writing for iTWire since 2006, a year after the site came into existence. For nearly a decade thereafter, he wrote mostly about free and open source software, based on his own use of this genre of software. Since May 2016, he has been writing across many areas of technology. He has been a journalist for nearly 40 years in India (Indian Express and Deccan Herald), the UAE (Khaleej Times) and Australia (Daily Commercial News (now defunct) and The Age). His personal blog is titled Irregular Expression.



Recent Comments