Blog

2010/04/16

Earlier this week, many WordPress-driven websites were hijacked and rerouted to a spam site. One site hit was one that I'm responsible for (the Burn City Rollers derby site). I'll post a brief chronicle of what happened.

I got a panicked email from Cho, founder of the BCR team, last Thursday (Apr 8th) -- a malicious popup appeared when she was using the site. When I checked the website it wasn't quite working correctly: the content appeared by the theme was missing. I use javascript whitelisting and adblocking so I didn't see any ads. I checked the page source and saw something very wrong: the page had an iframe directing to an "ad" site.

I tried to login the wp-admin panel first and could not access it. I used FTP to check over the theme files -- they had not been changed. I Googled around and found other people on Network Solutions having the same problem. Someone pointed out the changed setting: the iframe had been somehow added to the WordPress options table in MySQL.

I logged into Network Solutions and launched PHPMyAdmin. I fixed the offending value. I changed the MySQL password and WordPress admin password. I looked for other security options I'd missed: I filled out the random keys in the wp-config file and upgraded to the latest WordPress. The site appeared fine but I had no way of knowing if I'd closed the hole. I figured they used SQL injection on a WordPress form, cause it's unlikely they found the MySQL database password itself.

I checked the BCR site obsessively for a few days, fearing it would be hit again. Sure enough, two days later it was hijacked again (this time to a different ad site). Frustrating. I went in and changed passwords again, fixed the options, and Googled around to see if anyone had it figured out. I found this blog post by sucuri.net where they tracked down the WordPress vulnerability.

I checked my wp-config.php file and sure enough, permissions were set to 644. It hadn't occurred to me that this file would have the wrong permissions. I used Network Solutions's quick WordPress install to set things up, and it seems this installation had set risky permissions for everyone who used it. I used FileZilla to change the public permission to 0. No hijacking since then.

So what happened? BCR is on a shared hosting setup at Network Solutions. Some user figured out a way to view files of other shared hosts on these machines. Because they had file-level access they could read this wp-config.php file and get full database access. Then they used a script to change a setting in the WordPress blog database to load malicious ads from another server.

Long story short: don't assume file permissions are set properly. Make sure your password files are not public readable, and even move them out of web directories if possible.

P.S. Network Solutions has fixed the issues on their end. If you have a WordPress hosted by them and you're getting "Error establishing a database connection" see this blog on how to clean things up.