Got WordPress? Time to get it hardened – and scan for exploits
Oh, that in the picture above? It’s a control panel that I discovered inside the Free Our Data blog. Click on the buttons and it would let you do pretty much anything you liked in the directory. Though as you may have surmised from the dire layout and colour choices, it’s not WordPress-approved.
Not at all: this is a control panel installed by a hacker, who I suspect used one of the holes in user registration on WordPress to install this. (I surmise that because the blog is on shared hosting, and other WordPress installs on the same host that I know of which didn’t allow user registration haven’t been affected in the same way. If it were an exploit across the whole web server, you’d expect that all the blogs there might be affected.)
You’ll recall that there was a recent scare over WordPress vulnerabilities: pretty much every installation not hosted at WordPress.com was suspected of being at risk.
WordPress is important because it’s so widely used by people who have been looking for a quick, free blog install for their own hosting: getting it running is a cinch if you’ve got MySQL and PHP on your system. It’s widely used, for example, in the civil service, where getting blogs up quickly has become an important consideration.
However, keeping ahead of the hackers is rather different, and over the years there have been multiple occasions where quick updates have been urgently required. There was even one occasion where an “update” turned out to have been poisoned by a hacker who’d inserted their own stuff into the base code.
It turns out that turning off “user registration” is probably one of the simplest and most effective ways of “hardening” WordPress. (Allowing other users to, in effect, have access to your database leaves the way open for privilege escalation that you won’t like.)
And now, some more.
First, there’s been another upgrade to WordPress (it’s now at 2.8.5). The WordPress blog describes it as a “hardening release”.
Much more important, in my view, is the release of the WordPress Exploit Scanner plugin. Plugins are little extensions to WordPress; and Exploit Scanner is probably the next one you should install. (The first you should install, in my opinion, is Dr Dave’s Spam Karma 2 – which weeds out spam comments more effectively than anything I’ve ever seen, and is specific to your blog.)
The Exploit Scanner does a number of things: it compares your files against an MD5 hash of the WordPress files for whatever version of installation you’re running; it finds examples of suspicious code in your files – three principal ones being the use of “invisible” text through CSS; the use of iframes to embed code from other sites; and base 64 encoding, which can be used to obfuscate entire programs. It will also look through your posts and users to see if there’s anything suspicious or spammy about them.
It was the third of those suspicious behaviours – using base_64 encoding – that Exploit Scanner pointed out on the Free Our Data blog, leading me to the control panel pictured above. You could call it an accomplished bit of programming, using just 21Kb to put in a program that will analyse your system for any vulnerabilities, will try to hack your password directory (there’s even a button called BRUTE FORCE – for slogging through trying to get at those passwords), and notes everything potentially weak about your system. Remember that this, though, is the hackers’ tool. Once Exploit Scanner had pointed me there, that part of the hacker’s toolbox was quickly wiped.
I should mention though that Exploit Scanner didn’t notice the files that the hacker had added pointing to a “Canadian” “pharmacy” – it is limited to comparing the files that are there with the ones that it knows WordPress should have; those which are there which shouldn’t be it ignores.
One point about the default WordPress installation – from this experience – is that the hackers hid a stack of pages in the “default” WordPress theme. Among the security steps worth taking is to install a different theme and delete the default: that might make the hackers’ task more difficult.