Multiple 0days used by Magecart


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.

While the extensions differ, the attack method is the same: PHP Object Injection (POI). This attack vector abuses PHP’s unserialize() function to inject their own PHP code into the site. With that, they are able to modify the database or any Javascript files. As of today, many popular PHP applications still use unserialize(). Magento replaced most of the vulnerable functions by json_decode() in patch 8788, but many of its popular extensions did not.

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.

POST /index.php/madecache/varnish/esi/
POST /index.php/freegift/cart/gurlgift/
POST /index.php/qquoteadv/download/downloadCustomOption/
POST /index.php/ajaxproducts/index/index/
POST /index.php/minifilterproducts/index/ajax/
POST /index.php/advancedreports/chart/tunnel/
POST /index.php/bssreorderproduct/list/add/
POST /index.php/rewards/notifications/unsubscribe/
POST /index.php/emaildirect/abandoned/restore/
POST /index.php/vendors/withdraw/review/
POST /index.php/vendors/credit_withdraw/review/
POST /index.php/gwishlist/Gwishlist/updategwishlist/
POST /index.php/rewards/customer/notifications/unsubscribe/
POST /index.php/aheadmetrics/auth/index/
POST /index.php/customgrid/index/index/
POST /index.php/customgrid/Blcg/Column/Renderer/index/index/
POST /index.php/tabshome/index/ajax/
POST /index.php/customgrid/Blcg_Column_Renderer_index/index/
POST /index.php/rewards/customer_notifications/unsubscribe/
POST /index.php/vendors/credit/withdraw/review/
POST /index.php/multidealpro/index/edit/
POST /index.php/layaway/view/add/
POST /index.php/simplebundle/Cart/add/
POST /index.php/CustomGrid/index/index/
POST /index.php/netgocust/Gwishlist/updategwishlist/
POST /index.php/prescription/Prescription/amendQuoteItemQty/
POST /index.php/ajax/Showroom/submit/

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.

URIModuleStatusOrg
rewards/*TBT_Rewardsfixed in 1.8.7.3link
simplebundleWebcooking_SimpleBundlereported and fixed in 1.6.9link
ajaxproducts/indexEM_AjaxProductsfixed in 1.0.0link
qquoteadv/downloadCart2Quotefixed in 5.4.5link
advancedreports/chartAW_AdvancedReportsreported, fix announcedlink
aheadmetrics/authAW_AheadMetricsreported, abandonedlink
ajax/Showroom?? 
bssreorderproduct/listBSS_ReorderProductfixed in 1.2.4link
customgrid/*BL_CustomGrid?abandonedlink
emaildirect/abandonedCampaignerfixed in 1.1.6link
freegift/cartMW_Gift?? 
*/GwishlistmageGwhishlistreported, not fixedlink
layaway/viewCed_Layaway??link
madecache/varnishMade_Cachereported and fixedlink
minifilterproducts/indexEM_ProductsFilterWidgetreportedlink
multidealpro/indexEM_Multidealreportedlink
prescription/Prescription?? 
tabshome/indexVes_Tabshome? 
vendors/creditVes_VendorsCredit?link
vendors/credit_withdraw?? 
vendors/withdraw?? 

Modus operandi

Some more info on this group’s modus operandi. Once any of the probes above is successful, a malicious actor will come back and insert a customized Javascript payment overlay for the specific site. This works for sites that have external payments, or no credit card payments at all, because a fake credit card payment section is inserted. Once a user enters his CC details and clicks submit, the fake credit card form disappears and the unsuspecting (?) user will likely try again. The fake form will not show a second time, because a cookie is set to prevent that.

fake cc form 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):

records.nstatistics.com/records.php
stat.statisticvisit.com/rec.php

Up to now, they have returned various CC drop servers in the ngrok.io domain, such as:

b0b127c6.ngrok.io
f0c806aa.ngrok.io
e7900f9c.ngrok.io

As Ngrok takes these down quickly (as I predicted earlier), they use this mechanism to easily switch drop servers.

How to block all probes

As suggested by Sean H, you could hard block specific requests to these modules in Nginx. Their functionality will probably break though:

 location ~* ^/index.php/(madecache|freegift|qquoteadv|ajaxproducts|minifilterproducts|advancedreports|bssreorderproduct|rewards|gwishlist|aheadmetrics|customgrid|tabshome|vendors|multidealpro|layaway|simplebundle|netgocust|prescription|ajax/Showroom)/.* { deny all; }

Header image credits: Maxpixel

Yours truly: security consultant & researcher, tracking payment skimmers since 2015. I am also the founder of the opensource malware scanner and Magereport. If you could use an extra pair of eyes in your team to resolve a complicated security issue, do get in touch.