lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 Dec 2012 07:39:44 +0100
From: "Jason A. Donenfeld" <>
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, and WP Engine and countless more.
> Trusted by countless sites like:,,,,,,,,,,,, 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

W3 Total Fail

Exploit for point (2):  (Read the
entire usage message.)

Screencast for point (2): or


Merry Christmas.

- Jason


Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists