[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] Wordpress Remote Exploit - W3 Total Cache



For those of you that use W3 Total Cache to make your sites more performant, 
thank you. Security issues are always of paramount interest, no matter the 
scope.
 
The root of the possible vulnerability lies in the intersection of two 
configuration settings, one at the Web Server level and the other at the W3 
Total Cache database caching level. You may be vulnerable if the following are 
true: your server is configured to allow directory listing with enabled public 
access on W3TC’s database caching directories and also use database caching via 
the disk caching method. These settings would allow a hacker to break the md5 
hashing used for the then publicly accessible cached database objects. The 
manner, extent and timing of the vulnerability’s report leave much to be 
desired; nonetheless, the versions have now been patched on wordpress.org. 
Thanks to those that offered remediation advice. I’m sorry for the delay in 
turning this around, none of the proposed solutions were satisfactory.
 
The hotfix (tested with WordPress version 3.5) will help those who are just now 
upgrading to 0.9.2.4 or are otherwise getting started with W3 Total Cache. 
Specifically, the hash logic is improved via wp_hash(), significantly stronger 
than the previous md5 hashing at the compromise of a bit of speed. I’ve also 
made sure that a web server’s lack of security around directory listings and 
the standard file structure of W3TC’s hashing logic are no longer of 
consequence for those attempting to download them from your server.
 
For those who are using database caching to disk already, please be sure to 
disable directory indexing and deny web access to the 
“wp-content/w3tc/dbcache/” directory in your web configuration, then empty the 
database cache for good measure. Or, simply deactivate W3 Total Cache, 
uninstall it, and re-install it via wordpress.org to have the hotfix applied 
upon re-activation. Again, empty the database cache for good measure. Your 
settings will not be lost during this process. If all of this is gibberish to 
you, then simply disable database caching to disk until the next release or use 
another method if available. Once again, empty the database cache using the 
button of the same name available on the database caching settings tab.
 
If you’re reading this and have seen a post about the issue that does not have 
this response on it, please do post this for me. Thanks in advance. Happy 
Holidays.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/