I’ve Been Hacked

The WordPress sites that I have hosted at MediaTemple have been hacked. (Not WiredPen, it’s still on WordPress.com.)

Based on what I’m reading in the WordPress blogosphere, and Media Temple’s insistence that it is not at fault, I guess I’m going to be looking for another host. Again. Boy this is tiresome!

Thanks to my friend Lara — or else due to changes in the MediaTemple “how to guide” — I was able to run the MT SQL script this afternoon. It did not work for me yesterday — when I had only one site that seemed to be infected. The script results:

• TEDxSeattle.com – 948 affected rows
• ThisIsNotASpill.org – 118 affected rows
• LeeKaslander.org – 38 affected rows (a fresh WP second installation didn’t solve the problem – and this site was blocked from search engines)
• Motogrrl.com/blog – ? affected rows (I didn’t think to get a screengrab)
• kegill.com – ? affected rows (I didn’t think to get a screengrab for the two prototype sites hiding there)

About The MT Response

It did not occur to me Sunday, when I first reported the redirect, that this was a system-wide problem. I did look at MT’s website security section, which reported all clear. When I finally got a response to my ticket (21 hours later), the first thing MT did was suggest I hire someone to fix the problem:

If you do not feel comfortable resolving compromise-related issues yourself, Sucuri.net has extended a substantial discount on their scan/cleanup services to (mt) customers:
http://sucuri.net/mediatemple

I thought I was techy enough to figure this out, so I looked at the next point:

If you are experiencing a “redirect hack,” in which your domain is unexpectedly redirected to an external site, please go here for cleanup instructions:
http://wiki.mediatemple.net/w/WordPress_Redirect_Exploit

Ah. This was my problem. Good. More on that in a moment.

MediaTemple continued, with a tacit “blame the end user” implication:

In addition, here are instructions on how to “harden” a WordPress blog:
http://codex.wordpress.org/Hardening_WordPress
http://www.smashingmagazine.com/2010/07/01/10-useful-wordpress-security-tweaks/

I thought I was pretty secure, but, hey, happy to do more.

What that initial form mail response did NOT include was a link to this blog post from 6 August 2010. In other words, there was nothing in that original response, 06.27 am Sunday 9 August 2010, that made it clear that I was not alone. This deliberate minimization of the problem, more than anything else, triggered this blog post.

A followup on Monday 9 August 2010 at 11.02 am provided the link to the MT blog post. At that time, I had only one site that exhibited the exploit; it would grow to all four.

That form letter asserted:

As of this time, the majority of sites affected by the most recent exploits have been swept for malicious code and we will continue to scan all of the sites.

Well, given that it is 30+hours later and I’ve uncovered four sites with exploits — out of the four hosted at Media Temple — I think that was a supreme over-statement. Kinda up there with “Mission Accomplished.”

What about that Media Temple blog post — the one from Friday?

Generally, How do attackers gain access?

• Exploiting vulnerable, usually outdated, versions of web software.
• Exploiting vulnerabilities in the hosting infrastructure itself.
• Harvesting credentials from web applications that are not properly secured.
• Individual computers are being compromised thus leaking sensitive login information.
• Email is being spoofed and end-users are being phished for site login data.
• Non-secure FTP connections.

Let’s see — working in reverse order:

• I use secure FTP
• No one has phished me for MT login credentials
• My computer hasn’t been hacked
• The only “web application” I am using is WordPress — and the security of the database is at the feet of Media Temple. I use their one-click installation and have done nothing to the databases.
• Hosting infrastructure? That one is beyond my control.
• “Vulnerable” versions of the software? All of my sites are on WordPress 3.0 — I have not updated to 3.0.1. Nor has MT sent an alert around asking for this incremental upgrade, although I just upgraded all of them.

Moreover, MT insisted that this was not infrastructure-related:

We have fully analyzed recent attacks and have found they are being exploited by-way-of vulnerable or non-securely configured customer-installed web applications.

Well, I’m going to repeat myself here, but I don’t see how I had “non-securely configured” code. My comments are login or moderated. My WordPress admin passwords are secure (10+ characters, upper/lower case, numbers and special characters). And the MySQL configuration is managed by MT’s one-click installation process.

About The MT Solution

I have now run the SQL script against all of my databases. I visually inspected my wp-config.php files and did not see the injection URL nor did I see evidence that the file had been edited based on last modified date. However, according to Sucuri.net, I am still infected:

So, I ran the MT-supplied SSH script, which was looking at wp-config.php files. This completed script indicated that only motogrrl and leekaslander had to be disinfected.

Nevertheless, running the Sucuri.net scan shows motogrrl.com and TEDxSeattle.com are still infected; leekaslander.org and thisisnotaspill.org are clean.

Arghh.

Re-read the text accompanying the “copy and paste” SSH script:

This command includes the 3 URL variations from the above section.

Doh. There are now four URL variations. Is mine (ao.euuaw.com/9) not in the script? Yep, that one is in the script, but ue.oeaou.com/31 is missing. So I’ll run the SSH again with that snippet. Fingers crossed. No joy.

OK, to the WordPress.org forums. Here’s where I learn that one Media Temple person says that the exploit is broader than the “fix” that is on MT’s how-to-fix-it site:

I had the same problem. MediaTemple is my hosting provider, and they help me out with this. This is a WordPress Redirect Exploit hack that put a line of code on your database table wp_posts and wp_cats_posts

Great. When I ran the SQL script, I was checking only wp_posts … because that’s what MT’s guide said to do.

Back to MyPHPAdmin. Not my issue, I don’t have a wp_cats_posts row.

OMG.

Same problem here today on MediaTemplae.
The <script src= is also inserted into media attachment descriptions, so make sure to clean those too.

I don’t know how to do this.

OK. I’ve filed another ticket. The clock (20 hour wait, still) is ticking.