does it help to disable the plugin until a fix to this vulnerability becomes available ?
I read another story about this issue, and the author recommended “deny access to plugin directory by making an extra .htccess in that folder.”
How would I do that? I can’t disable the plugin on the site where it runs…
Edit: After a little more research, I found the answer here:
Sucuri.net article
It seems the easiest way to protect your sites is by disabling database cache or creating an .htaccess file inside the wp-content/w3tc directory denying direct access there:
deny from all
If you are not using Apache, you will need a similar configuration entry to prevent direct access to the w3tc folder.
Thanks!
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.
@fredrick,
You wrote:
“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.”
So does this mean the next release still hasn’t been released yet?
Will you be posting here when the next release comes out?
You’ll see a notification in your dashboard when the next release comes out.
But I have uninstalled the plugin as soon as I read about the security vulnerabilities. I don’t want to risk attack so won’t reinstall it until the security hole has been fixed.
I guess I’ll have to check in on your site from time to time then to see when it has been fixed.
The plugin is 3 years old with millions of downloads and only one vulnerability has been found for those with a specific configuration of their web server AND W3 Total Cache. Uninstallation was not necessary.
No offence intended Fredrick, I just want to ensure my sites are secure. I am not sure if my web server’s configuration is set in that specific way or not. So best to be safe than sorry, so I uninstalled the plugin until it gets fixed. Once it is fixed I’ll reinstall it.
Hey there,
Per instructions from my provider, I installed .9.2.8 this past weekend on a WP install running 3.5.1.
Two days later, I received notification from Google Webmaster my site had been hacked. Further scanning and then research revealed I had been hit by the same hack as described here http://blog.sucuri.net/2012/12/w3-total-cache-implementation-vulnerability.html
Just an FYI you have another vulnerability on your hands.
Best,
Lisa
You need to be sure that your site was actually fully “cleaned” up meaning that the party that hacked wasn’t still able to access your site regardless of the software run there. The vector that was identified literally is not possible to compromise in the same way, it’s been vetted by WordPress core developers and industry leading security analysts (the same guy that found the issue as well).
So again, have a company like http://sucuri.net/ have a look at your server for back doors, update your database and site credentials, add basic authentication to WP Admin etc.
My apologies for the very late reply, but wanted to follow up:
The site WAS fully cleaned by myself and double checked by my host provider (Dreamhost). It was also checked against sucuri.net to be doubly sure, which I do on a regular basis (once a week and whenever I install a new plugin). I was assured by both sucuri.net AND Dreamhost my site was clean and yet, after installing the plugin after you patched it, I was hacked.
Anamoly? Perhaps. But there you go.
