Credit card gobbling malware found piggybacking on ecommerce sites

Thanks to Mark Stockley, our resident JavaScript, PHP and jQuery expert, for his help with this article.
Dutch security researcher Willem de Groot, who’s particularly interested in security problems on online payment sites, recently wrote about a long-running Magento malware campaign.
Magento is to ecommerce what WordPress is to blogging – you can run the open source version on your own servers; you can use an ecommerce partner who’ll run a Magento instance for you; or you can sign up for Magento’s own cloud platform.
Thousands of sites still run their own Magento servers, even in the modern cloud-centric era, for example because they’ve already got a customised warehousing and shipping system with which their ecommerce servers need to integrate.
Unfortunately, de Groot found that many of these sites – more than 7000 in total, he claims – have been infiltrated by cybercrooks in the past six months.
Worse still, de Groot estimates that nearly 1500 of them may have been infected for the entire six-month period.

We’re not sure how sites are getting infected, but we suspect that the crooks behind this campaign are using multiple ways to break in.
If you haven’t patched your systems – including Magento itself, your underlying web and database servers, and the operating system – crooks may well be able to sneak past your existing defences by exploiting a known security hole.
If you haven’t kept track of accounts, crooks could be logging in using forgotten usernames you meant to retire but didn’t.
If you’ve picked poor passwords, and aren’t using two-factor authentication (where your users need to enter a one-time code each time they login), crooks could be guessing your passwords and masquerading as legimitate users.
In this attack, the crooks are quite deliberately targeting your customers in real time, harvesting credit card details “live” while your customers are right there on your site.
In the attacks that de Groot investigated, the crooks have been uploading a JavaScript file called mage/mage.js that they add to your website’s HTML template.
A template file serves as the boilerplate for all your web pages, or at least for all the pages in one part of your site, much like a master slide in a PowerPoint or Keynote presentation.
By adding a single HTML tag like this to the template…

…every web page based on that template ends up fitted out with the malicious data-stealing mage.js script.
Briefly summarised, the mage.js malware does the following, once it’s been received and loaded in a visitor’s browser:

• Adds a hidden web form for temporary storage of stolen data inside the web page itself.
• Sets a JavaScript timer that looks every 7 seconds to see if a data entry field called cc_num is visible on the page.
• Waits until the user fills in their card number, expiry date and CVV (short card security code) and possibly more.
• Copies the user’s personal data into the hidden form at the bottom of the page.
• Uploads the hidden form to a server controlled by the crooks.

By adding a hidden form and leaving the regular appearance and operation of your “buy pages” intact, your original site appears to work as usual – the crooks don’t draw attention to themseves by triggering unexpected error messages or failed purchases.
Additionally, by intercepting the data while it’s still in the browser, the crooks don’t need to go grubbing through the databases on your server to dig out data from recent transactions.
The data comes to the crooks; the crooks don’t need to go to the data.
Even more sneakily, the crooks get access to data that is only ever present during the transaction but never stored afterwards, such as the victim’s CVV (security code).

Fullz, the jargon term for complete credit card records, are more valuable than card data with no CVVs. The CVV isn’t supposed to be kept after a transaction has gone through, and it’s never stored on the magstripe or chip of the card – it’s the missing piece that crooks can’t easily acquire in other ways.
This malware also includes server-side PHP files that the crooks upload in an effort to protect their beachhead inside your network.
A file called clear.json (it’s a PHP program, not actually a JSON data file) is used to change the password on a long list of account names so that the crooks have many other ways back in if their initial attack is discovered.
A file called clean.json (also a PHP program) removes all references in the Magento database to the text strings ATMZOW, 19303817.js and PZ7SKD.
According to de Groot, the clean.json program is what’s often called anti-malware malware – it prevents various other “competitor” Magento malware samples from working.

What to do?

• If you’re an online shopper, consider using a web filter to protect you from compromised servers by blocking access to the command-and-control site run by the crooks.
• If you’re running a server that handles sensitive customer data such as names, addresses and payment card data, watch your logs for unexpected changes or unauthorised uploads.
• Consider using an anti-virus scanner on your server to detect the presence of malicious files that will put your customers at risk.

If you decide to use an anti-virus on your server, use real-time mode if you can.
Real-time mode, also known as on-access scanning, checks for malware files as soon as they arrive, and blocks them from being used at all, so they can neither run directly on your server nor be served up to your users.
Additionally:

• Patch early, patch often. Don’t leave security holes open when you could have closed them off.
• Pick proper passwords. If you can’t remember complex passwords, use a password manager to help you.
• Use two-factor authentication. That way, stolen usernames and passwords are no use on their own.

Sophos products block access to the malicious site in this attack as Mal/HTMLGen-A. The malicious scripts are variously detected as Troj/Magento-A, Troj/JSBanker-C and Troj/PHP-CI.