WordPress 4.7.2 was released last week. As usual I was aware of it and decided I would upgrade manually at some point very soon.
Call me complacent, but I’ve run WordPress on this site since 2008 and never fallen foul to the many security vulnerabilities that have plagued WordPress’s reputation. (He says, jinxing himself).
I was getting around to upgrading, but was given a stern reminder this morning in the form of this BBC news article. That got me out of bed pretty quickly.
In the Release Notes for 4.7.2 (bullet point 4) you will see that a very serious flaw has been fixed. It should probably read “You WILL be hacked TODAY if you don’t upgrade NOW”, because you will, and I was.
Defacement
I suffered a standard defacement of my website. My two most recent posts were updated with a bunch of clichés about my being “HaCkeD” or whatever. It seems as though multiple hackers had updated the same post with their competing pseudonyms. Googling these names shows thousands of other sites hacked, but I’ll leave the analysis to the experts.
For the technical details of the vulnerability see this post by the security company that identified it. I won’t repeat any of their information, but I will explain what I did to remedy the situation, and the answer isn’t “use my security product”.
What to do if you’ve been defaced
If your website has been defaced and you don’t know what to do, do this:
- Upgrade to WordPress 4.7.2 immediately
- Roll back your defaced pages
- Think about disabling stuff you don’t need or trust.
- Enable auto-updates (maybe)
Roll back the content
Rolling back my defaced pages was easy thanks to WordPress’s history feature. From the post edit screen, click the “browse” link in the right hand panel where is says “Revisions”, then click “Previous” until the last good version of your post appears on the right hand side. Then click “Restore this version”.
You may also find the title and slug of your post have been altered, so be sure to check those too. Also, don’t forget to drop any caches that may hold the defaced content. My site is behind Cloudflare, so I purged the lot. (It’s the only way to be sure).
Also worth mentioning that if you have any social media cross-posting going on, you may find your Facebook/Twitter feeds are contaminated with junk, so check those too. I searched Facebook for one attacker’s handle and it was everywhere.
Disabling some stuff
I thought I had no need for the WordPress REST API until I checked my server logs and saw search engines making calls to the oembed endpoints. So I guess if you want your content to be discoverable and sharable there’s a good reason to keep it enabled.
However, as I have no intention of administering my site via REST for the time being, I see no reason to allow write access via these endpoints.
Just in case there’s another nasty flaw that nobody knows about, I added the following lines to simply block all POST requests to the API:
Chuck that into the plugins directory and enable it, or – as I did – into the “mu-plugins” directory.
Enable Auto-updates
I don’t have auto-updates enabled because I don’t trust WordPress enough to allow write access to the file system while I’m not there to supervise. Rather ironic in this case, because auto-updates would have saved my skin. But I’m still hesitant. It’s a personal choice, and I choose not.
I have learned two lessons though.
1. If you rely on manual updates, do them immediately.
2. Read the release notes :)