TimThumb WebShot Code Execution Exploit (Zeroday)

23 comments

1. If you’re on a vps, here’s a command line to search for instances (default thumb.php filename only):

   find / -name ‘thumb.php’ -exec grep WEBSHOT_ENABLED {} ;

   1. Some themes include the file as tt.php, others may have different names. If you want to be sure, use:
      find / -exec grep WEBSHOT_ENABLED {} ;

      Yes, this takes a lot longer, but at least you’re sure you found all instances.

      1. Little correction to my own message:
         find / -name ‘*.php’ -exec grep WEBSHOT_ENABLED {} ;

         Otherwise you would scan every file/node at the system, including /proc/* – which will never end.

2. Thanks for sharing!

   “The good news is that Timthumb comes with the webshot option disabled by default, so just a few Timthumb installations are vulnerable.”

   More good news is the block in Timthumb 2.8.11-2.8.13 (and possibly other versions as well) that says:
   if(! is_file(WEBSHOT_CUTYCAPT)){
   return $this->error(“CutyCapt is not installed. $instr”);
   }
   if(! is_file(WEBSHOT_XVFB)){
   return $this->Error(“Xvfb is not installed. $instr”);
   }

   Since this requires both WEBSHOT_CUTYCAPT (default: /usr/local/bin/CutyCapt) and WEBSHOT_XVFB (default: /usr/bin/xvfb-run) to exist, this reduces the risk a lot.

   XVFB is available in the RHEL/CentOS package xorg-x11-server-Xvfb, but it’s not installed on a default server or minimal installation. Cutycapt is not available at all on a default installation, although it can be installed using a non-standard repository such as Epel. Epel however, does not install in /usr/local/bin, but /usr/bin instead.

   So even if a user or theme/plugin author enables webshots, it’s the missing binaries that stop the attack most of the time. And finally, there is safe_mode or disable_functions that blocks execution of exernal programs on most servers.

   So unless you’ve explicitly enabled webshots, AND installed the required software, there’s not too much to worry about. At least if you’re running RHEL/CentOS.

3. Thanks for sharing. The historical list of fails of this script can now be considered an EPIC FAIL. 🙂

4. I guess if you want to be on the safe side, this should block any attacks:

   RewriteCond %{REQUEST_URI} /wp-content/ [NC]
   RewriteCond %{QUERY_STRING} webshot= [NC]
   RewriteRule ^ – [F]

5. It looks like this vulnerability might also be in the wordpress plugin /awesome-flickr-gallery-plugin/. We found an instance of the code “WEBSHOT_ENABLED” in the afg_img_rsz.php file of this plugin. Haven’t been able to confirm if it is exploitable yet.

6. Hey! Almost all WooThemes’ themes are using timthumb script too. Now you have a dangerous threat.

   1. WooThemes have had to answer some pretty tough questions recently. I
      really do wonder why all their themes use TimThumb when the developer of
      TimThumb has said “Don’t use TimThumb”, “I no longer maintain it”,
      “there’s just better ways now”, “WordPress has had support for post
      thumbnails for ages now – and I use these all the time in my themes. I
      haven’t used TimThumb in a WordPress theme
      since before the previous TimThumb security exploit in 2011”.

      So,
      why are WooThemes using TimThumb when even the developer of TimThumb
      doesnt use it, hadn’t used it since before the 2011 exploit and there
      are better ways to do this?

      A few years ago, I became a
      full member of WooThemes, but I obtained a refund when I was told by
      their staff that when they test their themes they do not have errors
      displayed and they do not check their error logs. I am sure they have
      improved since then.

      1. Furthermore, in despite of all this, they (WooThemes) increased their prices this year in order to “keep up with the high quality”… I stick with Elegant Themes, which, at least is not using TimThumb in any of their themes.

         1. Absolutely. I am also a member of Elegant Themes, but I dont like them as much as I did a year ago. They need to be edited to avoid their seo settings and they feel really dated to me. I prefer finding designers on themeforest or having our designer create something custom from an existing theme.
            I would love to hear why WooThemes still use TimThumb. I guess for them it is easier to keep using an old technology instead of ripping it out of all themes.

            1. I wanted to let you know that I contacted someone with WooThemes and asked them why they still used TimThumb with their WordPress themes since I thought that was an interesting question as well. Also, I sent them the link to this blog post and encouraged them to publicly respond. If they don’t respond publicly once I have heard back from them, I will copy their response in the comments section of this blog post.

            2. Great. Let’s see how do they fix this issue. I’ll pay attention to this closely 🙂

            3. You don’t need to edit the Elegant Themes files. Just disable the dumb predefined SEO settings and use your favorite SEO plugin 🙂

            4. Disabling the SEO options doesnt work as the seo items use code specific to elegantthemes. Or at least it did when I first found out about the issue and asked for their support in resolving it.

            5. Now it’s fixed. WordPress SEO will work like a breeze with any Elegant’s theme 🙂

         2. Here is their response:

            Great question.

            We actually address the security vulnerability in this post – http://www.woothemes.com/2014/06/timthumb-vulnerability-protect-website/

            I’ll assign your ticket to our product chief for further incite.

            Stay tuned….

            Mike K – Chief Happiness Officer

            WooThemes Support

            Also, in the blog post it does say they plan to remove TimThumb from their themes and hopefully the “product chief” can provide a better timeline of that process along with more helpful information, but it sounds like they are making an effort which is good I suppose.

            1. They are making an effort NOW that the vulnerability is being noticed by everyone 🙂 Hope they can hurry up with this and give it the priority it deserves.

            2. That’s it? They plan to remove it now that another issue happened? WordPress manages almost all of this internally now, so surely keeping it within the themes only adds to extra load and processing.

   2. Hi All. Matty here, Chief Product Officer at WooThemes.

      I’ve recently replied to Caleb’s query on our help desk about this, which references this article, to thought I’d post here to share with you all about our plans for removing TimThumb from our themes.

      TimThumb was included in our Framework during the days where WordPress didn’t contain the advanced image-related functionality it does today. As I’m sure you can all appreciate, it is far easier to add a feature to a code base in use by hundreds of thousands of individuals, than it is to remove a feature (tl;dr: removing code without a contingency plan is no easy endeavour).

      We have scheduled the removal of TimThumb from version 6.1 of the WooFramework. We hope to accelerate the development of this version and have TimThumb removal as a top priority on the milestone list in our issue tracker.

      Since the very first TimThumb vulnerability hit several years ago, we have been running a regular effort to have our customers switch over to using the native WordPress image resizing functionality. At this stage, the inclusion of TimThumb within our Framework is purely a legacy decision. This has been a part of our greater plan to remove TimThumb from our code base.

      We look forward to sharing the WooFramework 6.1 update with you all.

      If I can clarify any points in the above, please do let me know. 🙂

      1. Glad to hear that Matt. It is always hard to remove a feature, but the user base will [hopefully] understand.

         At least you have did it already, the first move is to implement the patch using **define (‘WEBSHOT_ENABLED’, false);** in every one of your themes’ functions.php file.

         Best regards 🙂

7. Given the exploit, it looks like it using exec() – I don’t use WordPress myself, I find it to be a piece of shitaki mushroom that does crap like emulate magic_quotes_gpc (and in a broken way) and other such nonesense, but there really is no reason for a plugin to be running exec() and any plugin that does should not be installed.

   I suspect suhosin would have blocked this exploit. And probably breaks the plugin.

8. Another good way to mitigate this is to disable functions in php configuration. For those using cPanel is pretty easy. Just open your WHM, and go to Service Configuration, PHP Configuration Editor, Advanced Mode, search for “disable_functions” and in the input field just paste: popen, proc_open, shell_exec, passthru, exec
   That will prevent the most generic abuse attempts if any malware gets into the system. Well, they can still attack others’ websites, but still being unable to mess with your server files.

Comments are closed.