blog site of branko ajzele, senior developer / project manager

Magento sites hacked

Huh, this has been crazy week. I’ve been doing lot of Magento upgrades. Last night I upgraded one of sites to latest 1.3.2.4 Magento version (as of time of this writing). By pure accident I discovered a virus placed under the “app/code/core/Mage/Checkout/Controller” folder. It was in form of malicious php script named “81632.php” and “htaccess” file.

Below is a partial of malicious script

#...
error_reporting(0);$a=(isset($_SERVER["HTTP_HOST"])?$_SERVER["HTTP_HOST"]:$HTTP_HOST);
$b=(isset($_SERVER["SERVER_NAME"])?$_SERVER["SERVER_NAME"]:$SERVER_NAME);
$c=(isset($_SERVER["REQUEST_URI"])?$_SERVER["REQUEST_URI"]:$REQUEST_URI);
$d=(isset($_SERVER["PHP_SELF"])?$_SERVER["PHP_SELF"]:$PHP_SELF);
$e=(isset($_SERVER["QUERY_STRING"])?$_SERVER["QUERY_STRING"]:$QUERY_STRING);
$f=(isset($_SERVER["HTTP_REFERER"])?$_SERVER["HTTP_REFERER"]:$HTTP_REFERER);
$g=(isset($_SERVER["HTTP_USER_AGENT"])?$_SERVER["HTTP_USER_AGENT"]:$HTTP_USER_AGENT);
#... and the juicy part is cut of

The stuff was hooking to checkout process and sending data to another site. Luckily this was merely a development server, not a live site, so no actual damage was done.

For all Magento store owners, I would highly recommend immediate upgrade to latest Magento.

Magento 1.3.2.4 security update

  • meph137
    Nice job for letting everyone know about this. That is one nasty bug, especially being as it attempted to send personal data elsewhere without being detected, ouch! :(

    @colin - we have also seen an iframe-injecting nasty before. As you metioned, it broke Magento which was great, however it was nowhere near as serious as sending card data - it just attempted to spread itself.

    It also sniffed FTP passwords from what we could gather. It was contracted due to a vulnerability in Adobe PDF reader on one of our machines and then it spread to others who visited any sites.

    If magento is vulnerable to anything, it certainly seems wise to not 777 everything, something I have personally decided not to do. Glad I did :)
  • Hello Branko,

    You mentioned mentioned in your comments a manual patch... do you have any further information on this?

    Reason I ask is that I have a magento website still on 1.3.0.0, I'm hesitent to upgrade due to past issues I have had with the auto upgrading process... any information or instructions on manual patching would be fantastic - maybe another blog post for it?

    Many thanks
    James
  • @jonathan :)
  • Thanks for telling everyone Branko, this is not cool.

    @Colin - What mask should we be using - 755?

    Thanks,
    Jonathan
  • Lloyd
    I'm just wondering why Varien does not tell anyone about this? Especially for people running community version on production servers...
  • Lloyd
    I'm just wondering why Varien does not tell anyone about this? Expecially for others running production servers with the community version of Magento.
  • I have a client that was getting hacked multiple times per day. I think a PC infected with a FTP password-sniffing virus was somewhere on the wire and kept picking up new passwords. Moral of the story: don't use FTP.. ever.. Changed the password and lost it (purposefully) and switched to SFTP (FTP over SSH) and all is well. Good to know what other types of attacks are out there, this one just inserted an iframe in index.php which consequently caused a parse error (better than not causing a parse error and spreading viruses to clients like it was intended to do).

    A few recommended protections:
    - Place your apache redirects directly in the apache config file and don't allow .htaccess overrides (good performance tweak too)
    - Redirect to some other script besides index.php so that an attack on index.php has no effect.
    - Don't 777 all directories even if Varien says too. ;)

    Thanks Branko, as always, great blog post!
  • James
    The site Branko is talking about is mine and it’s a lot worse than originally anticipated.

    It appears a web bot scoured our site looking for directories that were set at 777. Then, it injected a PHP file and a htaccess file. While the PHP file is encrypted, any search engine bot coming through looking reads it fine and we now have search results like:

    sxe on vista
    spandexgalleries, bokep anak smp lampung, 2 men 1 horse video, deutche hitparade torrent, edita bente movie, deutche hitparade torrent, hacking rcon ...
    xxxxxxxxxx.com/media/catalog/product/1/a/sxe-on-vista.html

    Wondering where a lot of these files reside, I made a backup and extracted the files to my local computer. I noticed that all these files had the creation date of 8/17/2009. With the help of Microsoft’s cheesy but effective search feature, I did a search for any file created on 8/17/2009. It just stopped searching and it has found 21,689 files … and that’s just the rogue php files its injected and not the htaccess files.

    Considering it’s a development site (although anyone can access it), search results are few and far and only internal people know about it. We had pretty strong passwords and we just changed them again.

    My personal suggestion is that anyone running Magento is to look in any folder that has a permission level set to 777. If you see a php file that has a username of random numbers (e.g. 861585.php), open it up. Its more than likely that it’s a rogue php file and there is also an htaccess file in the same directory.
  • The issue seem to be 777 related. Fixed now. However, upgrade is a must, or manual patch due to XSS. Thnx for feedback.
  • Unirgy
    Did you check the apache logs around the time of file creation?
  • Vinai
    I do not think this is related to the XSS issue - probably a weak FTP password or some other vulnerability.

    Vinai
blog comments powered by Disqus
Powered by Wordpress | Designed by Elegant Themes