Any eCommerce store knows security is paramount to its success both by reputation and the cost of a breach.
The latest, or re-occurring, attack we are looking at dubbed MageCart, has turned up in Shopper Approved. Shopper Approved is a customer rating tool kit used by hundreds of eCommerce sites and is the most recent target of the MageCart spyware. Designed to syphon off bank card details using the customer rating plugin as covered by RiskIQ
MageCart is the name given to the toolkit used but it is not a single group who are criminally active. “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.” according to RiskIQ Yonathan Klijnsma.
“Upon learning of the event, we promptly initiated an internal investigation, engaged a leading IT forensics firm to assist in our review and took steps to remediate the issue and enhance our security features for both our website and the Shopper Approved seal. Additionally, we have worked closely with researchers at RiskIQ to better understand the issue and help protect against similar events in the future,” a Shopper Approved spokesperson told The Register in a statement.
“The incident only affected a small portion of our customers that use the Shopper Approved seal on their website, and we have reached out directly to those we believe may have been affected. The security of our systems and customers is a top priority for Shopper Approved, and we regret any inconvenience this incident may have caused.”
willwm’s lab looks at the evidence of the growing sophistication of MageCart. His research show that in 2016 MageCart would sleep to evade detection any time it detected developer tools running. This has since evolved, MageCart has a tripwire code when it detects any snooping, and collects your fingerprint.
When developer tools are open and you start debugging, the tripwire will send your timezone, IP, browser and a whole lot of other info about you to an external URL, such as
It disables all kinds of logging to the console.
It won’t do any reporting on mobile devices.
The malware itself has a nodejs hook, probably for the malware author.
This collected list is now available to the authors of the particular MageCart attack and the information may be used in future evasive techniques.
Not the competition against MageCart but a competition between the various criminal groups using the tool-kit. Brought to attention at willem’s lab where one groups code hijacks the details skimmed by an inferior group, modifies the last digit of the intercepted card and then forwards this bogus information to the original intended target. The reason the code doesn’t just block the inferior skimmer is purely down to reputation. Willem explains “On the dark web markets, reputation is everything. If one sells non-working cards, angry customers will publicly complain and it will destroy the competing “brand””
So what can be done to help defend against MageCart?
Content Security Policy Reference
Content-Security-Policy HTTP response header helps reduce XSS risks on modern browsers by declaring which domains the browser should trust.
By using a Content Security Meta tag you can reduce the risk of XSS attacks by defining where resources can be loaded from. This prevents browsers from loading harmful data from locations that have not been given permission making it more difficult for an attacker to inject malicious code. It is even possible to block any scripts from running on a site via a global disallow script execution.
Here we provide the steps required to implement CSP:
To add to the list of allowed connections:
log in as admin2
go to the domain
edit apache and nginx settings
find the CSP block
Inspect the page in chrome to see what is broken and follow the instructions to add the link to the correct block in the CSP.
Once implemented only scripts run from specific servers and domains can run helping preventy such attacks as MageCart.