Date: Mon, 24 Dec 2012 07:39:44 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: full-disclosure@...ts.grok.org.uk, webappsec@...urityfocus.com
Cc: ftownes@...edge.com
Subject: Wordpress Remote Exploit - W3 Total Cache

Hi all,

>>From the developers' description [1], W3 Total Cache is:

> The most complete WordPress performance framework.
> Recommended by web hosts like: MediaTemple, Host Gator, Page.ly and WP Engine and countless more.
> Trusted by countless sites like: stevesouders.com, mattcutts.com, mashable.com, smashingmagazine.com, makeuseof.com, yoast.com, kiss925.com, pearsonified.com, lockergnome.com, johnchow.com, ilovetypography.com, webdesignerdepot.com, css-tricks.com and tens of thousands of others.
> W3 Total Cache improves the user experience of your site by improving your server performance, caching every aspect of your site, reducing the download times and providing transparent content delivery network (CDN) integration.
> Downloads: 1,388,876
> Ratings: 4.6 out of 5 stars

Unfortunately, it's frequently incorrectly deployed. When I set it up
by going to the Wordpress panel and choosing "add plugin" and
selecting the plugin from the Wordpress Plugin Catalog (or whatever),
it left two avenues of attack open:

1) Directory listings were enabled on the cache directory, which means
anyone could easily recursively download all the database cache keys,
and extract ones containing sensitive information, such as password
hashes. A simple google search of
"inurl:wp-content/plugins/w3tc/dbcache" and maybe some other magic
reveals this wasn't just an issue for me. As W3 Total Cache already
futzes with the .htaccess file, I see no reason for it not to add
"Options -Indexes" to it upon installation. I haven't read any W3
documentation, so it's possible this is a known and documented
misconfiguration, but maybe not.

2) Even with directory listings off, cache files are by default
publicly downloadable, and the key values / file names of the database
cache items are easily predictable. Again, it seems odd that "deny
from all" isn't added to the .htaccess file. Maybe it's documented
somewhere that you should secure your directories, or maybe it isn't;
I'm not sure.

If I had to categorize these holes, I'd say they're due to
"misconfiguration", but I figure it's relevant to write in to
full-disclosure & webappsec because I'm usually not horrible with
configuring things and I made these mistakes several times without
realizing. I'm copying the author on this email, as he may want to
include a warning message where nieve folks like myself can see it, or
document these somewhere if they're not already, or at least apply the
two .htaccess tweaks mentioned above.

Anyway I put together a short and simple shell script that works
pretty decently against my own various wordpress websites, and
exploits the configuration error in point (2) above. Exploiting point
(1) can be done with wget & grep and is even more dull than the below
exploit.

****************
W3 Total Fail

Exploit for point (2):
http://git.zx2c4.com/w3-total-fail/tree/w3-total-fail.sh  (Read the
entire usage message.)

Screencast for point (2):
http://git.zx2c4.com/w3-total-fail/plain/screencast.ogv or
https://www.youtube.com/watch?v=sqZ_zYLFDSo

****************


Merry Christmas.


- Jason
  zx2c4



[1] http://wordpress.org/extend/plugins/w3-total-cache/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists