In October last year I discovered several Magento extension 0days. As it turns out, this was only the tip of the iceberg: today, insecure 3rd party extensions are used to hack into thousands of stores. A group of Magento professionals have identified 63 vulnerable extensions, and are now releasing the Magento Module Blacklist to help merchants counter these attacks.
Brief history of Magento hacks
The best part of my work as Magento forensics investigator is having front-row visibility into the craft of Magecart hackers. Over the last 4 years I’ve documented more than 40.000 breached Magento stores. The real figure is likely much higher, as not all hacks are visible from the outside.
In 2015, attackers used the “Shoplift” vulnerability in the core Magento code base. But as Magento upgraded their security policies, attackers shifted to brute force attacks on weak admin passwords during 2016 and 2017. Eventually, all the weak passwords got exhausted. And then in late 2018, a new attack method surfaced: exploiting insecure third party extensions. This quickly got traction, I estimate that several thousand stores were hacked this way in the last 3 months (I registered about 50 per day).
How extension attacks are spreading
The method is straightforward: attacker uses an extension bug to hack into a Magento store. Once in, they download all of the other installed extensions. The attacker then searches the downloaded code for 0day security issues, such as POI, SQLi and XSS flaws. Once found, the attacker launches a global scan to find vulnerable victims. Rinse and repeat.
Good protection, yet still getting hacked
The base of the problem is a conservative attitude among extension vendors. Contrary to Magento & Adobe, vendors generally fear loss of reputation and do not communicate about vulnerabilities. Those that do, may downplay the severity or bury it deep in their site.
Effectively, merchants are unaware of vulnerabilities in their installed extension base, which is typically 20 to 100 modules. Even though a successful merchant may have implemented all of the best practices:
Use a dedicated Magento hosting provider with managed server/OS security.
Have on-site dedicated Magento staff, or retain a specialized agency to perform timely (security) maintenance.
Implement technical measures such as a third party WAF and other recommendations from the Magento Best Practices guide.
But they may still be running code with known vulnerabilities. As a safety net, these merchants could keep all of their extensions upgraded all the time but that is economically impossible. Many extension releases are backwards incompatible, which requires costly developer hours. There is no standardized way to get notified of critical releases. And most important: merchants value stability above all, which does not fit well with a continuous upgrade policy. The fewer changes, the better.
I observe a sense of desperation among professional merchants, because they did all they could, and still got hacked.
Merchants: fear no more
A group of Magento professionals is proud to release a central repository of insecure Magento modules. It currently lists 63 insecure extension versions (and counting). Merchants can quickly run it against their store setups, find where they are at risk and selectively upgrade their extension base as needed:
Vendors & the future
I suspect that vendors will gradually move towards more transparent communication about security issues. Eventually, transparency will be a strong selling point for merchants who have suffered a breach in the past.
Until then, merchants should arm themselves with this data.
It is not our intention to shame vendors. I perfectly understand their position and their risk calculations. However, I strongly believe we have to strive for transparency if we are to have a chance against this tsunami of extension attacks.
A big thank you to these Magento professionals who have contributed security research and code.
The transfer of the file from the client host to the server host is initiated by the MySQL server. In theory, a patched server could be built that would tell the client program to transfer a file of the server’s choosing rather than the file named by the client in the LOAD DATA statement. Such a server could access any file on the client host to which the client user has read access. (A patched server could in fact reply with a file-transfer request to any statement, not just LOAD DATA LOCAL, so a more fundamental issue is that clients should not connect to untrusted servers.)
“In theory”? An Evil Mysql Server which does exactly that can be found on Github, and was likely used to exfiltrate passwords from these hacked sites. And could be used to steal SSH keys and crypto wallets.
The server has to know the full path of the file on the client for it to succeed. However, by first requesting /proc/self/environ, the server can learn a great deal about the folder structure on the client.
Several clients and libraries have built-in protection for this “feature”, or disable it by default (eg Golang, Python, PHP-PDO). But not all, as the Adminer case demonstrates. And Adminer probably won’t be the last.
Adminer is a popular PHP tool to administer MySQL and PostgreSQL databases. However, it can be lured to disclose arbitrary files. Attackers can abuse that to fetch passwords for popular apps such as Magento and Wordpress, and gain control of a site’s database.
Exploitation happens in three stages. First, the attacker needs a modified MySQL server, which is altered to send out data import requests to any client that connects.
Second, an attacker needs to find an open adminer.php on the victim system. That is not hard, as many people install it in the root of their site. Once found, the attacker can instruct Adminer to connect to his rigged MySQL server (external connections are actually a feature of Adminer):
Adminer will then connect to the foreign server, login with the credentials, and immediately receive a data import request from the server for a specific file. Here is an example session, where Adminer sends the contents of local.xml (where Magento stores it secret database password) to the attacker-controlled server.
Third stage: as the attacker now has the master password for the victim site, he can use the same Adminer to access the database of the victim. And continue to steal private data or inject a skimmer.
Abuse in the wild
Until now there is no documented abuse of this method, but in hindsight I have observed it being used by different Magecart factions at least since October 2018 (although I didn’t understand what was going on back then). The vulnerability was subsequently used to inject payment skimmers on several high-profile stores (government & multinationals).
Because different Magecart factions use it, I suspect that the modified MySQL server is for sale on the dark web.
Via my honeypots and customers I have observed a recent surge in the volume of open Adminer scans. I expect that anyone running an unfixed Adminer will be breached in the coming months.
I have tested Adminer versions 4.3.1 up to 4.6.2 and found all to be vulnerable. Adminer 4.6.3 was released in June, 2018 and appears safe. It is unclear whether the security flaw was fixed deliberately or by accident, as Adminer does not mention a security release.
I would recommend anyone running Adminer to upgrade to the latest version (4.7.0). Also, I urge anyone to protect their database tools via an additional password and/or IP filter. Sometimes perpetrators can obtain your database password by other means, and an open Adminer makes life very easy for them.
Skimmers found to subtly sabotage each others fraud operations
Competition is grim in the online skimming business (aka “MageCart”). The aggressive MagentoCore skimmer was previously observed to kick contending parasites from its victim hosts. But this week, I discovered that the battle has entered a new stage: advanced sabotage of each others revenue streams and reputation.
Sample case in question: cosmetics shop Bliv.com. It contains multiple distinct skimmers that send credit cards to different exfiltration hosts. The more advanced one is onlineclouds.cloud, which is heavily obfuscated and uses cloaking techniques. But with some sweating and curses, I decoded it (full source).
The interesting part is copied below. It detects whether any cards are sent to the (competing but inferior) skimmer domains js-react.com and bootstrap-js.com. Then, it subtly changes the last digit of the intercepted card number, effectively sending bogus card numbers to its competitor:
Why the subtle sabotage, instead of just killing the inferior skimmer? On the dark web markets, reputation is everything. If one sells non-working cards, angry customers will publicly complain and it will destroy the competing “brand”.
It is not likely that the MageCart battle will be finished soon, so stay tuned…
Thanks to Jérôme Segura of Malwarebytes for suggesting to decode the onlineclouds malware
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.