We were recently approached to help a client with their Magento website, and as a matter of course we first started with a check of what version they were running, what their current patch status was, and so on. We were immediately alerted to the fact that the site had not been patched for some time, and had recently been hacked. There’s a great online tool to help with this at MageReport.com:
Then for this particular script when you hit return it shows you what the variable x evaluated to (variations on this technique pretty much always work, although you do have to know what you are doing to avoid triggering some malware by mistake):
We’ve seen very similar code before, our assumption is that this is getting dropped on as part of a scripted “drive-by” attack. If this succeeds the script presumably keeps a note that your site is vulnerable and moves on to the next one. Some time later, the hackers visit again and drop back doors all over the place (we found more with just a cursory glance around the site).
In the screen grab above you can see the “send” function posts the form data to a destination page which has been named to sound like an innocuous jQuery library download ( trafficanalyzer.biz/lib/jquery-1.9.1.min.php ) but is actually isn’t that at all but is a script to capture the stolen data (the .php is another good clue, jQuery is a .js library file usually). I haven’t got the whole script in view in the screenshot above, there is a bit which has scrolled off the top which limits it to only trigger when you are on the site’s checkout/cart pages. To add insult to injury, there’s also a simple bit of code there which double checks whether any credit card numbers it is stealing look valid, using a simple regexp check. If it thinks it might have found a good credit card number it alters the destination URL slightly. This makes me laugh a bit to be honest, it is so cheeky of the hacker to use the victim’s processing capacity when it would have been trivial to do this check at the reverse end. They really do seem to be rubbing the victim’s nose in it.
You know that the hacker must have acquired admin level access into Magento in order to have dropped this hack in place. They have also turned on the on-site Sage Pay mechanism, so that rather than the two off-site ones which the client *thought* were enabled there were now three options when you got to the checkout step:
The third option has been turned on because the other two would take the user off-site to get credit card details. This is no good for the hacker (their script stops working when you go off to the remote payment gateway). By keeping you on-site they ensure that they will definitely get your credit card details as well as the personal details (address, phone number, email, etc) that they would get whichever payment mechanism you used.
This hack has certainly happened due to missing patches and/or poor password security. You might think you just need to clean up the site, indeed there are tips at this web address for how to remove the script via the Magento control panel:
…. (plus of course, you should remove the on-site payment mechanism). But our experience is that once someone has access to the Magento admin area they will have compromised the site in multiple ways and left themselves back doors – if there isn’t a clean copy of the site in source control to review against I would always strongly advise re-building rather than attempting repairs. Magento is a heavy beast (30,000 files plus in a typical install), the best programmer in the world couldn’t sensibly check all of those for hacks without the appropriate reference copies to check against, which means having the original versions of all of the plugins/extensions that the site uses. Without source control the chances of getting the right versions of all those files and making full comparisons in anything like a sensible timescale are absolutely zero. I wrote a blog entry detailing our processes a year or so ago:
It gets worse… In this particular instance we were quickly able to see that the hacker had also dropped a similar script into the “protoype.js” library which all site pages used (even the admin areas), so it was clear that if someone just followed the “how to fix credit card hijack” instructions above they would have immediately leaked their new admin passwords to the hacker as soon as they next logged in.
Of course, the real solution is to put a company like SteamDesk on retainer (our packages start from 4 hours/month), and we will monitor your site, update it straight away whenever new security patches are released, and add source control/backup mechanisms so that we can *recover* a site after it has been damaged (because with the best will in the world, you might still suffer from a zero-day attack, or a malicious insider, or a member of staff exercising poor password control) rather than have to start all over again.