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>
> 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.
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.
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>