Zero Day Vulnerability in many Wordpress Themes

A mitigation for this sort of thing: your Wordpress installations can be owned by someone other than the webserver, with 644/655 permissions. This will prevent folks from uploading arbitrary code (through any of the NUMEROUS plugins/themes with a vulnerability that allows them to do that), and also prevents folks from appending malicious code to known files.

My WP theme is from WooThemes and it includes "thumb.php" which upon inspection is timthumb.php. The blog post says to patch this you should remove the list from the allowedSites variable which I have done... I'll look at this more tomorrow but just FYI!

Great writeup. It's clear, it's concise and it's not overly dramatic. Thanks for taking the time to write this up and share it.<p>I have invested a bit of time installing and tuning mod_security. I'd love to know how it'd have faired against this attack, probably it wouldn't have stopped the upload, but it might have stopped a lot of payload/control commands from working.

I did a series on talks on Wordpress security earlier this year at OWASP London and AppSec EU. Sadly the AppSec slides were lost but the OWASP slides are still there for anyone interested:<p><a href="https://www.owasp.org/images/d/db/Wordpress-security-ext.pdf" rel="nofollow">https://www.owasp.org/images/d/db/Wordpress-security-ext.pdf</a>

The worst part of reading this post is encountering this search result - <a href="http://www.google.com/search?q=Alucar+shell" rel="nofollow">http://www.google.com/search?q=Alucar+shell</a>

As someone relatively new to Wordpress, I use a hosted instance from Wordpress.com. How do they handle things like this, and security in general?

&#62; 1. SSH into your web server.<p>That's not an option on a surprising number of web hosts offering PHP hosting. You'd have to find the file using FTP instead.

Also note that it doesn't even have to be an active theme - since timthumb.php executes directly and not through wordpress.

I used to see so many security problems with xmlrpc.php, and never used the functionality, so I put in a cron job entry that did this for all blogs I had hosted:<p><pre><code> mv PATH/xmlrpc.php PATH/xmlrpc.php.nope chmod 000 PATH/xmlrpc.php.nope </code></pre> something like once an hour in case I upgraded and forgot to secure the site.

FWIW: We had an older version of timthumb which uses preg_match instead of strpos, but suffers from the same flaw. The relevant line looks like this:<p><pre><code> if (preg_match($site, $url_info['host']) == true) { </code></pre> Good catch, Mark.

Very good find! Thank you for sharing.<p>I bought my theme from Theme Forest and it has this vulnerability. If you have a theme that you've purchased and contains this file, it would be helpful to post this on the theme's support forum.

This affects not just themes, but plugins too. Its in the vslider plugin I've used in multiple installs.

I wonder if it would be better if he disclosed this to the theme vendors.

Thanks for posting this!

Shameless self promotion of image resizer code... <a href="http://www.nkdv.co/code/do/resize" rel="nofollow">http://www.nkdv.co/code/do/resize</a><p>php resize crop and cache source.

But to use this vulnerability at first cracker have to have registered user? Or there are other way to upload images?

FWIW, I had two separate running instances of timthumb.php, but neither contained the $allowedSites array.

v1.34 fixes this, right? The author committed it this morning.<p><a href="http://code.google.com/p/timthumb/source/list" rel="nofollow">http://code.google.com/p/timthumb/source/list</a>

Could Wordpress issue an update to patch this?