1 in 5 compromised merchants get reinfected, average skimming operation lasts 13 days
MageCart, the notorious actors behind massive online card skimming, has been busy. And so have I: my crawlers are continuously tracking the raging battle between card thieves and merchants. It seems that the latter are on the losing end: in October, I counted the 40,000th hijacked store since 2015. And in the last 3 months alone, I counted 5,400 unique online stores that got a skimmer added to their checkout pages.
20% reinfection rate, counter measures fail
In the last quarter, 1 out of 5 breached stores were infected (and cleaned) multiple times, some even up to 18 times. This shows that counter measures taken by merchants and their contracted security firms often fail. There are multiple reasons for this. First, MageCart operatives are getting more sophisticated in hiding their presence and ensuring future access. Once an operative gains access to a merchant’s server, it is common to litter the site with backdoors and rogue admin accounts. Second, they use reinfection mechanisms such as database triggers and hidden periodic tasks to reinstate their payload. Third, they use obfuscation techniques to make their presence indistinguishable from legitimate code. Fourth, it is more and more common for MageCart actors to utilize unpublished security exploits (aka 0days). Researching these requires a significant investment. All in all, it takes some very keen eyes and a lot of effort to clean all traces of a breach.
Public examples of stores battling with reinfections are TechRabbit.com (2 times), Kitronik.co.uk (4 times) and Zapals.com (4 times).
Black hats are faster than white hats
Here’s a histogram of the number of days it takes merchants after a MageCart breach to clean up, and how many days between cleanup and a subsequent reinfection. Conclusion: skimmers persist on average for 12.7 days, while on average I saw reinfections occur within 10.5 days. We are one step behind here.
Cleaned during the week, hacked in the weekend
The red lines are newly identified infections, the green ones are cleanups. You can see that merchants and their security firms work mostly during the week, while the black hats, unsurprisingly, dont stick to office hours.
MageCart operations have become more professional while expanding methodologies and changing tactics. Merchants need to step up their efforts in protecting their reputation and the privacy of their customers.
When an accounting software firm proclaims to do epic shit, you know they are up to no good. The VC-funded Webgility software contains a backdoor for the purpose of remote upgrades. As a side effect, this allows anyone to upload PHP code and do all kinds of naughty stuff. Curiously, the Webgility engineering team denies the existence of the backdoor, even when confronted with a functional proof of concept and a demonstration video.
Because of the severity, I recommend Webgility customers to restrict access to trusted IPs or temporarily remove the software until there is a fix.
The backdoor was discovered by Eric Seastrand as part of a PCI code audit. He reported the security flaw on Oct 16th to Webgility, together with an extensive explanation, sample code and a demo video. Then, he got this odd response:
Our engineers further reviewed your E-mail and we would like to inform you that, this file can’t execute automatically or through a Web Browser […] we request you kindly do not test or trial anything in Webgility module folder
Eric answered patiently and explained once again how the unauthorized update mechanism poses a serious security threat. Webgility thanked him for the suggestion and closed the ticket without further ado.
I also gave it a couple of tries to explain the situation, but they would have none of it.
Just to be sure: I have validated Eric’s proof of concept exploit code on my live store. Because of the intense efforts that criminals are undertaking to find vulnerabilities in 3rd party ecommerce software, it won’t be long before this flaw will be massively exploited to turn the thousands of Webgility customers into card skimming zombie stores.
Hopefully this post will get Webgility to release a fixed version. If not, better to stay far from its software.
Thanks to Eric and the fine people at Hypernode, you can now use Magereport to check whether your store runs a vulnerable Webgility.
Online credit card theft has been all over the news: criminals inject hidden card stealers on legitimate checkout pages. But how are they are able to inject anything in the first place? As it turns out, thieves are massively exploiting unpublished security flaws (aka 0days) in popular store extension software.
It appears that attackers have amassed a large number of extensions and found numerous POI vulnerabilities. And they are now probing Magento stores in the wild for these extensions. I collected the following probes. If you are running any of them, you’d better disable them quickly and search your logs for unauthorized activity.
The payload for all of these POSTs is a specially crafted Zend_Log object that contains rogue code. Max Chadwick wrote a nice summary of this vulnerability class.
Fixing this mess
Now, I contacted several authors (kudo’s to Webcooking for being the first to fix their code within hours!), but I cannot derive the original author from all of these URLs. So my request to you: do you recognize any extension in these URLs? Please contact the author and keep me posted (email/twitter DM), I will update the status below. Together we can get all of these extensions fixed quickly.
fake cc form
Under the hood it currently uses a two step payment exfiltration method. First, a jQuery call is made to one of these (the first one has been taken down already):
The store of German political party CSU contains an identity skimmer that was planted on or before Oct 5th, right before the Bavarian election on Oct 14th. Personal identifyable information of customers gets sent to a remote server during the checkout process.
Because the CSU shop uses an off-site payment provider (Amazon & Paypal), no credit cards are stolen. However, session cookies and other private data are actively intercepted. The attackers likely used an unpatched flaw in the store software, or used brute force to guess a staff password. A quick MageReport scan yields:
The German coalition party is not the only one affected. I have been monitoring global stores for some time and counted the 40,000th compromised shop last week. The modus operandi is commonly known as “Magecart” and has hit high profile targets such as British Airways, Ticketmaster and ABS-CBN.
Just flagged the 40,000th store that got Magecart'ed, since I started counting 3 years ago. That's unique stores (domain names).— Willem de Groot (@gwillem) October 11, 2018
Here is the proof that the identity stealer is active and working.
The obfuscated malware is found at the bottom of https://www.csu-shop.de/js/infortis/jquery/jquery-1.7.2.min.js. This file was last modified on Fri, 05 Oct 2018 14:45:47 GMT, suggesting the malware is in place since at least 9 days. It fetches a dynamic payload drop server from records.nstatistics.com/records.php?standart, at the moment it will return b0b127c6.ngrok.io/checkpayment.php but the malware authors anticipate that they will have to change this, as Ngrok (free proxy for developers) will likely shut them down soon. The decoded malware reads:
Back in 2016, Magecart skimmers would evade detection by sleeping if any developer tools were found running. Then, their malware would 404 without correct Referer or User-Agent header. And now, Magecart sounds the alarm when it finds you snooping around, and collects a fingerprint of you on an external server.
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 sslvalidator.com/tools.php and rellicform.com.
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.
Ramifications: the Magecart authors now likely have a list of IPs of interested parties, and may use those in future evasion techniques.
The obfuscated tripwire is attached to a (dummy) copy of jQuery-Mask that is served on non-checkout pages. Here’s a reverse engineered copy:
The fingerprint receivers are hosted on 22.214.171.124 and 126.96.36.199, a dodgy network spanning NL/IE/RU/UA. According to VirusTotal, the following hostnames resolve there, which have been added to the Magento Malware Scanner list of IOCs.