Off to the Host and Exploited
Recently, we needed to move the entire company’s portfolio to outside servers. This was pretty quick and painless, and overall I’m quite satisfied. What I didn’t expect was for three of the company’s websites to be hacked shortly afterwards, including this one…and it was a coincidence!
We moved to DreamHost. So far, it’s great. Awesome up-time and all speed tests look positive. We don’t have as much control or abilities as we had (shared hosting), but I’d go out on a limb and say it’s the best host I’ve used to date. Beautiful and efficient control panel, access and abilities I haven’t seen with my previous hosts, and courteous support when you’re in a jam (“LONESTAR!”).
A while back, I purchased the WordPress Envision theme developer license for use on a few customer sites. It’s a nicely designed theme with a few nice features, and I’m more than happy to support other developers/designers when their work appears to be top-notch. Eventually, however, I didn’t use the theme on any of their sites, but kept it in my theme pack for deployment since it was paid for. I’ve created the majority of these themes, so there’s no real concern over such security issues. I tend to shy away from overly complex theme options when dealing with customers, so there isn’t a great deal of risk there.
The Red Screen of Death
As I was doing my normal hourly (or so) refresh of one of the sites’ administration panels, Chrome throws up the “This site redirects and may contain malicious content.” Which, of course, is far from the more preferable “This site will bake you brownies and guarantee 24/7 NFL action on the Lifetime Movie Network.” First thing to do? PANIC…for a couple of seconds. Really, you would too.
After nearly soiling myself, I pulled it together and took notes. What domain was being redirected to? What should my next step be? Simple questions to clear my mind in that situation. The first step was to hit google in search of the domain being redirected to: newportalse.com (DO NOT CLICK THAT IF IT’S A LINK…unless you don’t like puppies…then, hey, I can’t be held responsible). That search led me to this page which gave me a better idea of what I’m dealing with, and eventually to this post with a list of affected WordPress plugins and themes. Not seeing anything I use in those lists, I had to keep searching.
I decided to use Sucuri.net‘s free web site malware scanner to track it down, and was pointed to one offending file on each site. Easy enough, right? FTP > Delete. End of story, you say? Well, don’t. It’s not. I still hadn’t found the vulnerability. Where was this elusive “timthumb.php” hiding in my installs? After some more searching, I found this page on Sucuri.net‘s web site, which provides a simple PHP script for seeking out that mean old puppy-hating, unicorn-slaying, mole of a thumbnail script. Amazingly, it found the offender in the “Envision” theme I now feel that I had paid far too much for.
The Gripping Conclusion
I removed the theme from all of my WordPress installations, and enjoyed a pint with my mates at the Winchester. Happy ending, right?
After being stumped by the repeated infections, here are all of the traces I have found thus far. We’re currently monitoring the websites minute-by-minute, and as soon as it reactivates, we squash it, so no customers (or customer data) is at risk. We were rotating login and database passwords to keep the intruders out. I eventually found the other files by modifying the sucuri_wp_check.php file and adding “eval(base64_decode(” to the sigs array.
- Any file in any theme directory may also be infected.
When fighting any issue such as this, it’s important that you keep security as tight as you can, even while dealing with an in-progress compromise. Passwords that could have been compromised should immediately be changed (and continue changing them throughout the ordeal to protect data), especially those which are stored in plain-text, like the WordPress-MySQL password.
As we continued to watch, we began to see these same files become infected repeatedly, so we knew there was still a hole somewhere. Eventually we tracked it to another theme that wasn’t being used and didn’t use timthumb.php. The files of this theme seem to have been modified in the first round, and the scanners we were using weren’t looking for the right signatures (see “Affected Files” above). Unless the signatures of this highly irritating exploit have changed in some way, we’ve now killed it and closed up the hole.
Updated 8/20/2011 12:21 AM: Added list of affected files.
Updated 8/20/2011 12:36 AM: Added reminder and TRUE Conclusion (we hope).