If you are using WordPress then watch out for W3 Total Cache
If you have a blog or write for one (both of which I do) then you have no doubt looked for plugins to improve your traffic and user experience. There is certainly no shortage of ones available, given the popularity of the platform. But, not all of them are good or reliable or even secure. In fact, one of the most popular has just been outed to have an enormous security hole.
W3 Total Cache, a plugin designed to speed up web sites that use the WordPress content management system. It does so by caching site content, speeding up page loads, and downloads. In fact, it has more than 1.39 million users.
Now however, a security researcher, Jason A. Donenfeld, has found a vulnerability in the plugin that makes sites that use the plugin vulnerable to attacks.
The cache data is stored in [a] public accessible directory, which means a malicious hacker can browse and download the password hashes and other database information.
Certainly not good news for many web site owners, including major ones like Mashable, which use this plugin. In fact, the researcher published a simple script -- http://git.zx2c4.com/w3-total-fail/tree/w3-total-fail.sh -- that can identify and exploit the hole. Donenfeld points out that the plugin is "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" and more.
Exposed cache directories are also discoverable by using a Google search. Even if you switch the directory listings to off, cache files are still publicly downloadable by default with W3 Total Cache. In fact, all a hacker would need to know is the key values and file names of the cache items, which Donenfeld claims is not exactly rocket science. Scary!
There is, however, some good news. In a post to Full Disclosure Donenfeld stated that W3 Edge, the company behind this plugin, is working on an update to close the security hole. In the meantime, those using this plugin on their blogs may want to consider temporarily disabling it while they wait for an update.
As far as Ghacks goes, we are safe from the vulnerability as we are running WP Super Cache.
Advertisement
I guess Old horse ruining new track. Hopefully Cache plugins will be more secure for latest WP releases.
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.
Frederick thanks for stepping by and posting the explanation.