W3 Total Cache Implementation Vulnerability

Just in time for Christmas, it was announced on the full disclosure list a security (configuration/implementation) bug on W3 Total cache (W3TC), one of the most popular WordPress plugins.

The issue is connected to the way W3TC stores the database cache (in a public accessible directory). It can be used to retrieve password hashes and other database information.

By default the plugin will store the caches inside /wp-content/w3tc/dbcache/ and if you have directory listing enabled, anyone can browse to yoursite.com/wp-content/w3tc/dbcache/ and download them. The second issue is that even if you don’t have directory listing enabled, it is still possible to guess those directories/files in order to extract the database cache queries and results.

There is more information about this issue on the full disclosure list: http://seclists.org/fulldisclosure/2012/Dec/242:

Confirmed vulnerability

We tested and were able to exploit this vulnerability on our test sites. Many shared hosts have directory listing enabled by default, making the problem even worse.

On the sites without directory listing, we were able to download the whole db cache directory remotely and then search for specific strings (user_pass) and get the password hashes:

a:6:{s:10:"last_error”;s:0:””;s:10:”last_query”;s:41:”SELECT * FROM wp_users WHERE ID = ’15′”;s:11:”last_result”;a:1:{i:0;O:8:”stdClass”:10:{s:2:”ID”;s:2:”15″;s:10:”user_login”;s:21:”Guest Blogger”;s:9:”user_pass”;s:34:”$P$BPtuFcIxFXXXX3MJbBBN4dxJ1″;s:13:”user_nicename”;..

Patching

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.

If you have any questions, let us know.


UPDATE (30 December 2012): W3 Total Cache has been patched (0.9.2.5). Head over to the WordPress Plugin Directory to download or update right from your WordPress dashboard.

Here is the official response to the vulnerability from Frederick Townes, the plugin author:

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.

About Daniel Cid

Daniel B. Cid is the Founder & CTO of Sucuri and also the founder of the open source project - OSSEC HIDS. His interests range from intrusion detection, log analysis (log-based intrusion detection), web-based malware research and secure development. You can find more about Daniel on his site dcid.me or on Twitter: @danielcid

  • http://nodeki.com/ Jonathan

    Running the script provided by the person reporting the vulnerability failed when testing it across a number of test installations. The closest we were able to get is “Attempting…” and nothing more – after about 4,000-5,000 attempts, it quit. Are you all using something more than the provided shell script to test for the vulnerability?

    • http://twitter.com/perezbox Tony Perez

      Hey Jonathan

      We didn’t use the provided script. We used our own method once we knew the vuln, we unfortunately do not disclose details of how we do it for a number of reasons. It is still very much an issue though.

      Thanks

  • http://www.arevindh.com/ Siddhu Arevindh

    I got 404 while trying this .

  • Daniel

    This only happens when using disk cache. When using Opcode cache that folder doesn’t even exist.

    • Simon

      Thanks. I activated APC on all my sites using W3TC

  • Ryan Duff

    “The second issue is that even if you don’t have directory caching enabled, ”

    I think you mean directory listing in that sentence, not directory caching.

    • http://armeda.com/ Andres Armeda

      Thanks Ryan. Fixed.

  • Paul

    I get a 403 access forbidden

  • http://jb510.com Jon

    Just to weigh how dangerous this is. How hard is it to reverse a WP hashed password? I forget how WP hashes p/w but assuming your not using 8+ random a password that doesn’t show up in a rainbow table or password list…

    I mean clearly this is bad since your handing someone the username and hash at the same time… still wondering how hard that particular hash is to reverse

  • Pingback: The Truth About W3 Total Cache Security and All Caching Plugins()

  • Andrea Giardini

    That’s not a vulnerability at all… Your configuration should always prevent direct access to plugin/theme folders. A server misconfiguration is not a vulnerability.

  • Avinash

    setting up a htaccess with deny from all in the folder wp-content/w3tc is causing Minify URL rewriting is not working message in w3tc admin ( Iam using Minify with disk cache )

    • Austin ☃ Passy

      Instead of deny from all, use Options -Indexes allowing the plugin to read itself but deny directory listing.

  • Derick Schaefer

    For those NGINX users, the following should be placed high the server block:
    if ($request_uri ~ ^/wp-content/w3tc/dbcache ) { return 403;}

    This isn’t a bad idea either:
    if ($request_uri ~ ^/wp-content/w3tc/objectcache ) { return 403;}

  • Martin

    You must not add “deny from all” to “wp-content/w3tc/.htaccess” if you have a file based page cache, or your visitors will experience a “Forbidden access” message on your blog.

    It is better to add a “wp-content/w3tc/.htaccess” with the following contents:

    # wp-content/w3tc/.htaccess
    # Prevent access to folders indexes
    Options -Indexes

    Then, create the following files:

    wp-content/w3tc/dbcache/.htaccess
    wp-content/w3tc/log/.htaccess
    wp-content/w3tc/min/.htaccess
    wp-content/w3tc/objectcache/.htaccess
    wp-content/w3tc/tmp/.htaccess

    with the following content:

    # Prevent direct access to files

    deny from all

    RewriteEngine On
    RewriteRule .? – [F,L]

    Please notice the “wp-content/w3tc/pgcache” folder must not contain any restricted “.htaccess” file or it will prevent the blog to work properly.

  • http://antonpug.com/ Anton Pugachevsky

    This is not a vulnerability, it’s called server misconfiguration. Btw, I don’t have anything in the dbcache folder anyway?

  • Mike

    I believe they released an update to deal with this yesterday.

  • Paul

    An update was made available today by the author of the plugin. The update directly addresses this issue. I’ve installed it without any problem.

  • Pingback: appthemes | CMS Radar()

  • Pingback: Tips Tuesday and Get Your Site Right in 2013()

  • http://www.yepiclip.com/ yepi

    thanks for sharing useful information to us, I will bookmark your page

  • Pingback: W3 Total Cache WordPress Plugin Security Concern - TourKick.com()

  • Pingback: WordPress Security Threats – Dec/2012 | 블로그코디 닷넷()

  • Pingback: W3 Total Cache Fixes Security Hole | WPForce()

  • Pingback: W3 Total Cache Fixes Security Hole - WP Force()

  • fuckyou

    fuck this plugin ruined my website already !

  • http://www.yepi-yepi.com/ Yepi Friv

    I believe they released an update to deal with this month. I hope so

  • Pingback: 2012 Web Malware Trends Report Summary | Sucuri Blog()

  • http://www.y8u.org/ Y8

    This is wonderful reading material that’s good for anyone that likes to read informational articles. Thank you.

  • http://www.minecraftgames.co/ Minecraft Games

    Great stuff here. The information and the detail were just perfect.

Share This