back to article Payment-card-skimming Magecart strikes again: Zero out of five for infecting e-retail sites

The payment-card-skimming malware operation dubbed Magecart has turned up again, this time in Shopper Approved, a customer rating plugin for websites. Shopper Approved is a toolkit used by hundreds of e-commerce sites, and it was infected with the MageCart spyware, allowing crooks to siphon off bank card data entered into …

  1. Doctor Syntax Silver badge

    "The security of our systems and customers is a top priority for Shopper Approved"

    So how do you square that with what happened?

    Also, let's remember that the punters who got their cards skimmed aren't their customers, just their customers' customers.

  2. Anonymous Coward
    Anonymous Coward

    Same Old

    Look at the culture/issues outlined here: https://www.telegraph.co.uk/technology/2018/10/08/banks-face-continued-woes-legacy-infrastructure-holds/

    These are the same issues common issues repeated. Stick in something that works, forget about it, implement a new way to interface or develop insight/revenue. Then forget the whole, and realise its all broken. Resulting in impacts to revenue or customer data.

  3. Halcin

    Begs the question why do companies think it's necessary to use third party scripts that have no direct relevance to collecting CC details?

    1. Warm Braw Silver badge

      Because having all the analytics and "engagement" is more important to them than the security of the payment. And, of course, their web designers are bereft without their beloved frameworks.

      Auditors generally give a free pass to shopping sites that have a fully-hosted payment page (i.e. it's on a third party site belonging to the payment processor), but they have also, I understand, sometimes extended the same licence to any page where the hosted payment page is included in an IFRAME within the retailers own site where, of course, misbehaving scripts would pretty much have free rein. So even the compliance controls seem to have been lax.

      1. Nosbod

        Cross origin iframe's are restricted

        Scripts trying to access a frame's content are subject to the same-origin policy, and cannot access most of the properties in the other window object if it was loaded from a different domain. This also applies to a script inside a frame trying to access its parent window.

        https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#Scripting

        1. Warm Braw Silver badge

          Re: Cross origin iframe's are restricted

          They are. But there's nothing stopping script in the outer window replacing the IFRAME with an inline form mimicking the hosted payment form and submitting it to the payment processor after capturing the details, or changing the URL of the IFRAME to a proxy server somewhere that captures the submitted details, or a range of other things...

  4. heyrick Silver badge

    Shopper approved?

    "a small portion of our customers that use the Shopper Approved seal on their website"

    What this says to me, more than anything, is to avoid any sites with a "shopper approved" seal. It's one thing auditing an online shopping process and saying "we approve", it's an entirely different thing doing so and in the process requiring that shop to run their scripts that are not only unnecessary but exist purely for siphoning off data - maybe the original aim was to collect usage stats and such, but clearly Crims have shown exactly what can be done with a little bit of extra code.

    Shopper Approved and any site using it now go on the mental blacklist... (this shopper does not approve)

  5. EnviableOne Silver badge

    Magecart - not one group

    This code is everywhere

    its not just one codeset being exploited its a whole load.

    https://doublepulsar.com/magecart-new-tactics-leading-to-massive-unreported-fraud-5211c9883dea

    The IOCs on this are never ending

  6. psale

    Brute Force access

    I have been brought in by many companies to remove and clean up after Magecart and its variants.

    Often the simplest way the hackers get backend access, is via brute force attacks against publicly exposed login pages, and or other unsecured login endpoints (Magento has a few of these for some unknown reason).

    That combined with poor / no password policy or basic IT security training for backend staff is very often to blame.

    Also i've noticed in the newer variants of Magecart, the bad guys also insert a database trigger that re-inserts the malware back into the database as soon as its been removed from the various tables. This is not getting reported on for some reason but i'm seeing this more and more.

  7. psale

    And another big problem

    As part of my daily work & research I often find hacked magento websites containing magecart and other malware.

    I always send the store a personalised email warning them they have been hacked and letting them know of the severity. I.e. your customers bank details are being stolen from your website!!!!

    I then send various follow up emails and even take the time to warn them via a "Live Chat" box if they have one.

    I tell them i can provide FREE step by step removal instructions if they contact me back, i would estimate about 20% of stores reply, the other 80% are still infected several weeks later.

    Honestly many of these store owners simply do not care, or bury their heads in the sand and hope the problem will go away.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021