Unknown
Thursday, November 10, 2011
So what’s all the fuss about? Recently, an 0day was discovered in a project called “TimThumb” which essentially, caches even remote files locally, without doing any proper sanitization. The file “timthumb.php” does however, check if to see if the target file is actually an image or not. This timthumb file is also quite often renamed to something else and is used in many themes.
TimThumbCraft – Image Crafting Tool
The easiest way to trick TimThumb into believing a remotely stored image (that also contains evil PHP code) is an actual image, is to either craft it yourself or by using an external tool. In this case, I decided to write a small tool for the job which also has a few encoding features, payload types, and of course, options for custom images.
Using the tool is pretty straight forward and intuitive. But what are its complete features?
Feature List:
.List known vulnerable themes
.Choose between 2 images or select your own
.Enter your own code or use the Reverse PHP Shell
.Encode your PHP Payload, this applies only if “code” is chosen
.Base64 and Hexadecimal encoding is currently supported
.Hexadecimal output of the created file. (Can be used in paste’s, etc.)
.MD5 calculation of filename, that the target server will most likely use
It doesn’t work when you tried, why?
If the src field on the target server doesn’t require Base64-encoded strings as some do, the issue is most likely because the evil domain you created isn’t readable by the web server or because it isn’t in the list of allowed domains contained within the timthumb.php file. From version to version, this appears to have changed but in version 1.32, blogger.com was a valid domain.
Q: What should the created subdomain look like?
A: blogger.com.yourdomain.tld
Simply enough, you need to test in your web browser that you can access your subdomain and of course, upload the image file which you created with TimThumbCraft. If your image is displayed when you perform the call to the timthumb.php file on the target server, you may have to press CTRL+F5 in your browser as it may be the case that the image is locally cached.
Another very important thing is that it’s very easy to change the cache directory so in some cases, the cache directory on the target may not be named “cache”. Last but not least, from version to version, strings may be prepended to the file that you forced the target server to cache locally. When I tested 1.33 in which the original researcher reported a vulnerability, it seemed like it created files without any extension. Therefore, I used 1.32 as I could confirm it was exploitable.
If you know PHP, you’re aware that you can do anything that the all-too-common malicious PHP shells can do. If you want to load a remote shell and allow_url_include is enabled within php.ini, use: include(“full url here”); and simply hit enter. As you can see in the screenshot below, I loaded a remotely stored r57 shell to demonstrate this PHP feature. Many RFI and LFI vulnerabilities are related to dynamic use of the include(); function in PHP.
Is there a patch for this vulnerability?
Yes. The original researcher rewrote the entire script, line by line, to optimize it and make it more secure. I did a quick review of the code and fuzzed a few fields I found interesting to see if there were any obvious mistakes. None were found, so the newest version is “pretty secure”. Remember though that nothing is 100% secure.
If you want to find timthumb files on your server the right way, issue this command in a terminal: (Thanks rAWjAW for the CLI Kung Fu)
find . | grep php | xargs grep -s timthumb
Be sure that you’re in the www / document root of your web server as you may not know where any timthumb files are located and what they’re named. Hence the reason it’s a very bad idea to just search for “timthumb.php” as a lot of researchers recommended.
Category ›
Computers
No comments:
Post a Comment