W3 Total Cache – Beware The Surprise In This Christmas Gift
Merry Christmas!! Well, Christmas has passed, but on Christmas Eve WordPress users received an early Christmas gift. There is a confirmed security issue with the W3 Total Cache WordPress Plugin that can expose your WordPress website to crackers. This issue is a little more serious than most that I’ve seen because it exposes your user passwords in a cache file. First, let’s look at why you might want to use W3 Total Cache and then we’ll examine the vulnerability.
What Does It Do?
W3 Total Cache can help you serve your web pages faster by performing several actions to make the pages serve and load faster.
Cache Pages And Database Queries
Every time someone visits a page on your WordPress website, in order to send the information to their browser, your server must visit your MySQL database a number of times to get all the information it needs to put the page together. It must also consult the code on your website, consider the CSS, and a number of other operations. Each visit to the database, the CSS, and the code takes a certain amount of time to accomplish – even though that time may be very small. Each operation adds time before the page can be served to the end user.
W3 Total Cache goes ahead and constructs each page ahead of time and instead of revisiting all the different places and assembling the page as it’s needed, it only has to serve the page that it has already prepared. Additionally, as things do change on your website, it will prepare a new version of the page to serve. This not only takes a load off of your server, but also is supposed to load your website for your visitor much faster.
Streamline Your Visitors Browser Cache
Your visitors web browsers don’t instinctively know what items from your website can be cached on the visitors computer and which should not. Additionally, the browser doesn’t know how long to cache information from your website. UNLESS your website gives it the information necessary to know what to cache and for how long.
W3 Total Cache makes sure that this information is prepared and sent to your visitors web browser so that it knows what to cache and how long to cache it. That makes sure that their local cache is as effective and efficient as possible. In theory, that should make your website load faster on their computer.
What Is The Vulnerability?
You may be saying to yourself, “Well, if it’s that good, where is the security issue?” Sounds like it’s just fantastic doesn’t it. What could be wrong?
Basically, all this caching of your website files will store some information that you don’t want the world to know – primarily the encrypted password of your user account. Normally, just storing this information on your hosting account would not be a problem, but there are two potential situations that may expose your sensitive data to a cracker.
By default W3 Total Cache stores the cache files in the /wp-content/w3tc/dbcache/ directory and if you have directory listing enabled on your server, anyone can do a simple Google search on inurl:wp-content/w3tc and find websites that are potential targets for this security issue. Once they find a WordPress website that is exposing this data, they can simply download the cache files to their computer.
Once they’ve downloaded your cache files, a cracker can browser your database cache files and locate your database keys (such as your password hashes). What damage could be done by a cracker if they have your usernames and can decode your passwords? This could get bad couldn’t it?
Even if directory browsing is not enabled, someone aware of this security hole can directly download your whole database cache and then search through it just as noted above. There is a screencast of how Jason, the person who reported this to Full Disclosure, can find out your usernames and password hashes. Simply visit the screen cast at http://git.zx2c4.com/w3-total-fail/plain/screencast.ogv.
Want to poke around and see if you can discover these values on your own WordPress website? Then, use the code that he posted at http://git.zx2c4.com/w3-total-fail/tree/w3-total-fail.sh. I now WPMU.org take any responsibility for how you use his code or for any damage that may occur from using his code. I only note it here in case you want to know more.
There is more information on the Full Disclosure list from the person that discovered this vulnerability.
What Can I Do?
There have been many suggested fixes to plug this security hole, but most have since been proven to be of little value. I’ve seen an .htaccess trick to block access, but most of these files must be publicly accessible to be served to your visitors web browsers, so you can’t completely block access to them.
I apologize if this appears to be oversimplified for all the data that I’ve presented, but the best fix is to “UPDATE IMMEDIATELY”. The developer just released a new version on December 29, 2012 that is supposed to close up this security hole. The revision that fixes this is Version 0.9.2.5. According to the plugin author this version:
“Fixed security issue that can occur if using database caching to disk. If using database caching to disk with a web server with directory listing or web accessible wp-content/w3tc/dbcache/* directories. This patch works for all hosting environments / types where PHP is properly configured, i.e. .htaccess modifications (or other web server configuration changes) are not necessary to ensure proper security. Empty the database cache after performing the update if you use database caching to disk.”
While you are logged in to your WordPress Admin Dashboard, go ahead and update the WordPress core if you’ve not done so already. Then, update your themes if they are not up to date. Finally, update any plugins that are not up to date. Once everything is up to date, commit to yourself that you will keep it up to date in the future. So many WordPress exploits are the result of not keeping things up to date. There are tools that can help with this, but ultimately the responsibility falls to you.
Also, ask your hosting provider to turn off directory listing. If you are on shared hosting, you will probably not be able to get this done unless they have it turned off already. If your host will not turn directory listing you have a couple of options – stick with your current host and hope it is never an issue (yeah right) or change to a host that has directory listing turned off or will turn it off for you.
This is a perfect example of why using WordPress is not a “set it and forget it” method of building websites – either for yourself or for clients. When I first started working with local clients, they would almost always tell me that they didn’t really need monthly “maintenance” for their websites. So, I changed my language in explaining that service. I now explain to them that the core code for their website is constantly being improved and therefore regular periodic updates are necessary to maintain the security and integrity of their websites. I’ve found that a little education of WHY they need to hire me for the monthly work is usually sufficient to help them understand and make the decision to hire me.
Once you’ve updated the plugin to the latest version, be sure to visit my colleague’s article 2 Plugins To Put Your Site In The Fast Lane to learn some methods to speed up your WordPress website. Also, be sure to leave a comment here about your experiences with W3 Total Cache.