If you’ve ever been hit with a virus on your computer, you know how difficult it can be to thoroughly clean the machine, even when you have security software that does all the heavy work.
Take that picture and apply it to your blog and you have a migraine-inducing situation, precisely what I’ve experienced during this past week with an iframe virus and a malware attack involving a backdoor Trojan that temporarily created some havoc on this WordPress blog until they were eliminated.
What I learned from this experience is simple things any blogger can do to help ensure the security of your site.
I became aware that something wasn’t right when publishing a post using Windows Live Writer produced an access error. Likewise, accessing the blog via the WordPress app for Android on my phone also gave an error. I thought it might be related to a known error with XML-RPC and PHP that I encountered a few years ago. But a quick peek at the source code of the home page showed me a different likelihood.
Notice the string of text highlighted in red that starts line 1 – code to create an iframe and then access another website on every page load. Given that I hadn’t inserted that code, nor had it anything at all to do with WordPress, then the chances were pretty certain it was done by someone who had gained unauthorized access to my server.
Line 1 should start with this -
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
A simple search on Google and a chat with my hosting service, DreamHost, speedily confirmed the worst: the blog was infected. Identifying precisely with what, and fixing it, was a clear priority.
Looking around the web produced lots of helpful posts recounting the experiences of others who have addressed similar issues as mine, all of which were very useful in the actions I took to rid my site of this most unwelcome visitor.
Immediate three steps:
- Change the passwords and log ins for all blogs and my hosting account.
- Review list of users who have admin authority on the blog. If there are any there I don’t recognize, either delete them or at least change their access levels to one which gives no ability to write content on the site. For all others, disallow their admin rights temporarily
- Change the password for my own FTP access account and cancel access of every other FTP account.
If the hacker had got in via a lax security measure – like a weak password or FTP access – then that simple route was now blocked.
Now, some detective work.
I began by backup up the WordPress database and then downloading a copy of my complete site via secure FTP, a process that took some hours, so that I could compare every PHP file in the WordPress installation and the theme I use against known clean files of both so I could see all instances of where the nasty code was. While downloading, Microsoft Security Essentials was checking each file as part of its virus scans. That’s when the alarm bell rang.
The security software identified one file as a backdoor Trojan called Merview.A.
This is an especially nasty piece of work, according to Microsoft.
This threat is classified as a Trojan – Backdoor. A backdoor trojan provides remote, usually surreptitious, access to affected systems. A backdoor trojan may be used to conduct distributed denial of service (DDoS) attacks, or it may be used to install additional trojans or other forms of malicious software. For example, a backdoor trojan may be used to install a downloader or dropper trojan, which may in turn install a proxy trojan used to relay spam or a keylogger trojan which monitors and sends keystrokes to remote attackers. A backdoor Trojan may also open ports on the affected system and thus potentially lead to further compromise by other attackers.
In essence, that file gave the perp access to my server so he could do whatever he wanted. Something had been going on for sure, judging by the increased bandwidth use on my server that couldn’t be connected to normal activity, eg, visitors reading blog posts. The file itself, called remv.php, has an interesting pedigree and is not part of WordPress nor any theme or plugin I use.
After zapping that file on the server itself (and more on that in a sec), my next step was to upload and overwrite the WordPress files on the server with known clean copies from a new installation file I downloaded from WordPress.org. As soon as I’d done that, I could see immediately from the source code that all references to unknown iframes were gone.
Next was the same procedure with my theme, followed by plugins.
It’s nearly a week later and the site hasn’t had any repeats of the headaches of the past week. Running a simple audit by monitoring and malware detection service Sucuri gives the site a clean bill of health.
So what have I learned from this experience? First and foremost, pay attention to site maintenance. The remv.php file I mentioned was placed in the theme directory of an old test blog I’d created back in 2006 and I’d not visited or looked at the admin of it for over two years. Passwords were weak (and unchanged in years) and it was running a very old WP version as well as out-of-date plugins. This was like an open door to my perp, and probably was just that.
You can not be complacent about the security of your online presence, whether it’s a blog or anywhere else for that matter, as I was with that old blog. You need to keep alert always and pay attention to what’s going on with your presence.
In the case of a blog, that means things like ensuring it’s running the latest version of your blog platform especially if updates have been released to fix security issues – as has been the case with WordPress during the past few years. (As I write this post, the current version of WordPress is 3.0.4 released in December 2010. If you’re still running an earlier version, you’re asking for trouble.)
Even though I’ve done the steps I’ve mentioned to clean out the crap, so to speak, I’m not resting on any laurels. It may be that the site isn’t 100% clean at all, a thought that certainly comes to mind when I read posts like this one by Michael VanDeMar.
Indeed, VanDeMar says it well in a comment in his post:
[...] Just having the latest version is never a guarantee that it is safe. The most you can say is that having an older version is pretty much a guarantee that you are not safe.
Probably the only way you will ever get to a feeling of complete security is by starting over with fresh installations and a new WordPress database. Hardly a feasible option for many.
My proposition is to treat the threat as a calculated risk, taking obvious steps to secure your site so at the very least it becomes not really worth a perp’s time trying to get into it – there are other fish he can more easily fry.
So here are my five tips for managing your blog with more peace of mind:
- Ensure your blog installation, your theme and all plugins are up to date (but note caveat above), whatever platform you use. If a hosted service, ask the provider about security if it’s not obvious to you on your site.
- Make sure your logins, passwords and other access means to your blog are robust; change passwords frequently.
- The same applies to your MySQL database – the heart of your blog – and change that password frequently.
- In WordPress, install a couple of handy plugins that are helpful in monitoring your site and alerting you if anything is suspect: AntiVirus for WordPress and TAC (Theme Authenticity Checker) are two I use
- Review your server logs regularly and pay attention to any alerts you receive from your hosting service about activity in your account or on your server.
What else should be in a list like this? What would you do?