Back in Business
“Reports that say something hasn’t happened are interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know.”
- - Donald Rumsfeld, US Secretary of Defense, 2002
Update: frgdr.com was base64′d a second time on May 12, 2010. New insights at the bottom of this post.
A few hours ago frgdr.com was injected with malicious code which redirected every visitor to a website that tries to trick people into downloading a fake antivirus program. Everything is fine now. If you are interested in such details after the jump is a summary of the incident, including why my hosting provider GoDaddy is awesome.
For more than a week now I have been reading reports about self-hosted WordPress websites being hacked and injected with an eval(base64_decode code, so in a way, I have been waiting to be hacked, and were proactively reinforcing my already tight security.
Yesterday at about 6pm local time I received an email from my own website (!) through one of my WP plugins which read “The daily antivirus scan of your blog suggests alarm”. Visiting my website made me realize it was hacked, as I was transferred to a website made to look like Windows XP, telling me I have a virus and should click here to get rid of it.
How was it resolved?
After determining frgdr.com was hacked, I tweeted about it and immediately renamed my WordPress directory to prevent visitors from getting duped. Further inspection revealed every php file hosted was injected with the infamous base64 code, including my WordPress files and my URL shortener files.
Since I read about this specific attack beforehand, I knew restoring the old files was sufficient, and so since I am hosted with GoDaddy this was done with a single click.
As a precaution, I downloaded the restored website to my local computer and scanned it for the specific base64 string. When I was certain all was back to normal, I tweeted about it and was back in business.
What did I do wrong?
I was not running v2.9.2. the latest version of WordPress, but its predecessor v2.9.1. I usually upgrade to the latest version ASAP, but since it fixed an unrelated issue and was not labeled a ‘recommended upgrade’, I figured I would skip it.
I am not certain that this would have saved my website from being hacked, but hey…
What did I do right?
Following is a list of precautions I took before being hacked including WordPress plugins I use to make my website secure. This might be useful for people who self-host WordPress as vigilance is a constant battle. Bare in mind that with everything mentioned here I still got base64′d:
- passwords: I use strong passwords, up to 20 characters in length, and a different one for every service. Using RoboForm2Go to remember my passwords for me, I can be this restrict.
- file backup: The actual files are backed up daily by my hosting provider.
- database backup: Using WP plugin WP-DB-Backup to automatically backup and email me the MySQL database every hour.
- malware notification: Using WP plugin WP AntiVirus to monitor malicious injections and send an email warning of possible attacks. If you do one thing, install this plugin now!
- unauthorized logins: Using WP plugin Login LockDown to prevent brute force attacks.
- corrective measures: Using WP plugin WP Security Scan to detect novice-level vulnerabilities.
What saved my day?
- GoDaddy hosting – which includes easy files/folder restoration.
- GoDaddy’s twitter updates and their general approach of transparency with security issues.
- WP AntiVirus plugin which literally emailed me an SOS that triggered my rapid response.
Update May 12, 2010 2pm: Following are my new insights after being base64′d a second time today:
- As I suspected, running the latest version of WordPress v2.9.2 is no guarantee against being attacked.
- I had found an unfamiliar php file named tiphany_enemy.php in my root directory (modified: May 11, 2010 – 9:33:58pm). It contained just the base64 code. I suspect this is how the attack began.
- Total time from discovery to fix: 1 hour. This is roughly six times as fast as the first attack, as the novelty wore off and I only restored the php files. No extensive investigation this time.
- My time goal for the inevitable third attack: 20 minutes.
Update May 12, 2010 4pm: After reading WPSecurityLock’s case study I have upgraded my SQL database from v4.1 to v5.0.