Category: Media Industry Author : Duncan Riley Posted: November 15, 2009
Tags : attack, fail, hack, hosting, Injection, mediatemple, security, WordPress
The Epic WordPress + MediaTemple Failure
A week ago I, Kyle the Invincible!, was hit by an injection attack on the majority of my own sites, and it took a large handful of hours to even figure out what was wrong. Once I discovered that a file had been somehow uploaded to my server, which executed itself and inserted malicious code onto my site’s pages, I wrote about it – in fact, you can find the full technical details on my blog and some more details on the WordPress bug ticket.
Everything seemed like it was OK afterwards, since MediaTemple (my host) had worked pretty heavily with me to find the problem and determine the solution – I even wrote about how I was happy with the interaction and name-dropped the techs who had helped me. But then when my post on the issue started getting popular, because this is apparently a common problem at the moment, they stopped talking to me, especially when I started pushing for more answers.
The key to all of this is that a file is somehow uploaded to the server, which I had initially thought might be a fault of my CMS. WordPress claims it isn’t their fault, but they released a security update (2.8.6) pretty quickly after my security and bug reports on the issue. MediaTemple claims it’s not their fault either, because WordPress is “notoriously insecure”. But when the same issue started appearing for other users that don’t even use WordPress, I became concerned – even more so when I learned most, if not all, of them are MediaTemple (gridserver) customers.
I’ve been pressing them for answers for the last four days, since I decided it was a hosting security issue, and have been ignored pretty stoically. But imagine my surprise today when I notice that I’ve been hit by the exact same attack, just a week later, this time running WordPress 2.8.6.
If there’s a security issue floating around, you’d imagine that those behind the problem would be extremely interested in fixing it as soon as possible… right? Well, apparently not. It seems to be more important for both WordPress and MediaTemple to act more like the Camel Lights camel rather than Boris from Goldeneye, and this is absolutely unacceptable from a user standpoint. Any vulnerability that allows unauthorized access to data, breaks a site, makes a huge list of SPAM links to porn, and redirects links to a malware distribution site is entirely not something to laugh at.
This is not a chain mail letter you can ignore without repercussions – this could effect a very big swath of the Internet, no matter who has caused the security hole.
I’ve been relatively happy with the (gridserver) plan from MediaTemple, and I know most people have been too. If this keeps up, however, I’ll be leaving them for someone who’s more interested in my data security than they appear to be, especially since all evidence points to this being a server issue rather than that of public-level software.
MediaTemple: step up, and do what we pay you for. If not, there will be a user reckoning.
WordPress: you need to make an announcement. If it’s not your fault, that’s fine – but recognize the issue publicly, publish steps to fix the issue, and make a definitive claim against MediaTemple; however, you better have concrete evidence that it isn’t your fault.
— — —
Update (11/26/2009 2:15pm PST): It’s been long since decided that it’s MediaTemple’s fault, not WordPress. MediaTemple has just announced they’ve “solved” the issue, but they haven’t yet told the whole story. I’m working on getting the full story, but until there’s enough to warrant a full-post update here on the Inquisitr, granular updates can be found on my original blogpost.
Update (111/26/2009 5:30pm PST): More granular detail has been revealed, as well as some revelatory updates.
— — —
Kyle Brady is a contributing columnist for the Inquisitr, an entrepreneur, and has a future in science fiction. He can be found at his blog, via email, or on Twitter.







3 Trackback(s)