Until recently, I’d hosted my own WordPress blog. I’d been thinking of moving to one hosted on WordPress.com for a while, but I hadn’t been bothered enough to move – though it would be cheaper.

Then I got hacked. Naturally, I investigated. 

The attack itself was manifest through a ‘content’ widget that contained a URL encoded string which contained the payload – basically, an HTML element that was put in front of the homepage of the site. Other widgets that I’d had configured had been removed. Removing this widget “fixed” my homepage.

How was the attacker able to achieve this?

Well, I started by examining the server logs. That showed a LOT of calls to the login page – much more than would be expected for legitimate use. Looking at data volume I could see an unexpected volume of traffic originating from an IP that appeared to relate Amazon Web Services. Fully 20% of my sites bandwidth for the last 3 months seemed to have come from AWS.

Interesting. Brute Force attack, maybe? Investigating this further, I was dismayed to discover that vanilla WordPress doesn’t seem to have any brute force protection built-in. No exponential backoff, no temporary blocking of accounts. I added that via a pluggin, and changed the admin account name (which, in fairness, I should’ve already done).

For what it’s worth, I was pretty appalled that there was no such functionality built-in.

Still, if it was brute forcing, that was surprising; my password was strong, and to brute force should’ve required an exhaustive search, which should be prohibitive.

Next, I checked the filesystem itself of the webserver. I couldn’t see any files that had changed, though to be honest, I did only check the modified times, rather than a compare with a backup set that I had. That might have been more useful – though possibly confusing, as I had recently upgraded WordPress to the latest version. I decided to reinstall WordPress anyway.

I waited – and 2 days later it happened again.

It now occurred to me that the vulnerability could be due to plugin. I did have a few installed. Perhaps one of those had been subverted and was introducing a vulnerability. I was keeping them up to date too. Quite whether this as a server side vulnerability (which I suspected), or something else wasn’t clear.

Alternatively, it could have been achieved via a SQL Injection attack (though that’d have to be a fault in WordPress, which one would hope was also unlikely. Although I suppose a plugin might cause that again…). Most strangely, the Admin account seemed to have been re-enabled. In hindsight, this does make me think the issue might be a SQL injection one.

Anyway, it was clear that I had a vulnerability, that I was unclear what it was. There’s quite a lot of code in WordPress and it’s plugins, and that the only safe approach would be to rebuild the WordPress install and database. Or… I could just move the blog to a WordPress.com hosted one. That way, someone else could look after the administration and security side of things, and I could focus on writing up what I learn. It’d also have some nice things like 2-factor authentication (and I like 2-factor authentication!)

So I migrated, and set up an HTTP forward on my existing blog. Not entirely satisfactory – it’s still not entirely clear what the vulnerability was – but why spend ages solving the problem if I was going to move the blog anyway?

Looking at the text content of the web site defacement, it does seem like there are a lot of WordPress sites that this idiot is defacing. I’m deliberately not mentioning any of the details he posted in the defacement to deny him publicity.

My money is on a SQL injection attack, though through what isn’t clear. The presence of lots of such hacked sites suggests a plugin, maybe. And I am at a loss as to why so much traffic was received from an Amazon Web Services server.

If your WordPress install get’s hacked, I recommend the following link as useful information: My Site Was Hacked FAQ.