W3 Total Cache critical Vulnerability disclosed

@gianpaolo.cipicchia, How do you know that this was done through the object cache?

As for the permissions problems, that’s not unexpected and no one in these forums can even guess why that’s happening without looking at how your particular server is set up.

@gianpaolo.cipicchia

For my personal experience, with various hosting, dir and file chmod permission is not problem … W3TC work perfectly with dir 705 and file 604 chmod permission, on various situations.

@frederick Townes

1 – What happens if the same malicious script used to exploit db cache is applied to object cache with W3 total Cache 0.9.2.5?

2 – What happens if the same malicious script used to exploit db cache is applied to advanced cache (disk and enanched mode) with W3 total Cache 0.9.2.5?

I would agree with most everything here, including best practices for htaccess and so forth, but I take issue with the statement “And just an FYI – if you are using secure passwords then you have nothing to worry about since one-way hashed passwords cannot be cracked.”

Hashcat with on a workstation with a number of GPU’s, can and will crack wordpress passwords, and people do it all the time. Collisions can and will happen. Especially passwords under 8 characters, will only take about an hour or two on a high end machine with multiple GPU’s doing the cracking. 8 or more characters take a bit longer exponentially for every character over 8 or more in length.

At a minimum, 14 or more would be more desirable as well as implementing your own form of two factor authentication, or doing as I do and disabling access to wp-login.php and the wp-admin directory via htaccess for anyone other than my own IP.

Still, its not impossible to break, as the algorithm used to create the hash, can have any number of possibilities for the hash itself and its only a time trade off issue as to when, not if, the password can be broken. Type in any word, and do it continually, the hash changes every time. I use this for myself, when I’ve forgotten the password on systems that don’t have the ability to email passwords or no SMTP setup, and I have to manually edit clients sites that need password resets, I can make my own and just paste in whatever this outputs directly to the database file itself and it works – https://www.attack-scanner.com/pass.php

If you are going to block access to indexes, be sure to block access to wp-login.php and wp-admin as well except for your own IP. Its a hassle to update the htaccess file every time your IP changes, but its worth it in my mind. Another alternative, is add htpasswd protection to the wp-admin directory so no one can login, which in some ways, adds a second layer of authentication. Just don’t use the same login name and password for both htpasswd and your wordpress login, but that should go without saying.

@digip – Yes of course you are correct. Some secure passwords can be cracked in hours, some take months and some take years. I will rephrase my statement – “If you create new secure passwords over 14 characters each month then you have nothing to worry about.”

@aitpro hope no offense was taken either way. Was not my intention, just wanted to illustrate a point that length with respect to the current password hashing scheme for wordpress alone is not a deterrent for attackers at this point in time and easy access to user names is all they really care about, since they usually just brute force logins once they know the user names and don’t care about needing the hash itself.

Still, password cracking is a common threat in todays landscape of GPU hardware based password cracking machines, and wordpress passwords in general are quickly broken in hash cracking competitions since the average user only uses a small subset of actual characters for their passwords, often limited to lowercase letters and numbers only and usually no more than 8 characters. Not to mention hash length extension attacks that use probability statistics in reducing the common key space used to only commonly used characters and removing certain letters, special characters, etc, the process of cracking most(but not all) passwords becomes even that much faster when you add additional cracking techniques.

Not trying to hijack the thread or to cause hysteria, but users should be aware of a number of security practices, not just htaccess control and strong password use, but also monitoring of login attempts, something I hope is someday implemented into wordpress itself to notify admins if a failed password attempt has taken place. There good thing is there are plug-ins to help users in that area to fill the void, including one I’ve written myself, but you don’t need to use mine to be able to log these attempts. There are plenty of other plug-ins that help with that regard and I would suggest every WordPress user consider using some form of login monitoring plug-in that emails the admins of attempts. Just one more layer in a balanced approach to securing your site, and something most users would probably be surprised at how many people are already brute forcing their way into your sites already, directly against the login page of wordpress itself. One of the first things I do when setting up WordPress is install a login alerts plug-in, and change all usernames to use different nicknames for posts and comments, so attackers can’t use default names like admin to login with(which is a topic for a whole other discussion on why you should never setup wordpress with the username admin).

I deactivated the plugin, upgraded & reactivated the plugin and it is now giving me this error when it didn’t before:

It appears Minify URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.

I deactivated and reactivated the plugin again. Deactivated and reactivated the minify part of the plugin. Restarted my Apache server, but the error persists. Looking above at Frederick’s comment, I can see that it’s unlikely that anything can be done without someone knowledgeable about both this plugin and my server looking into it. But if anyone has any suggestions for what kind of permissions setting I’d need to change or look at just for this minify issue (my server does currently allow .htaccess), I’d be grateful for that.

Also, is it better to leave minify turned off for now?

Thanks!

alexwoolfson,

I have the same problem, except the issue also impacting disk cache

“It appears Page Cache URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.”

Based on the load of the CPU it looks like that the disk cache is not working for me at all. Also reloaded 0.9.2.4; have still the same problem on the site tried to the the upgrade.

alexwoolfson wote:

Is it better to leave minify turned off?

@alexwoolfson

Turn Minify to manual and take advantage of HTML minification. Minify CSS and JS manual … this work better ??

MediaInk wrote:

Disk cache is not working for me at all. Also reloaded 0.9.2.4; have still the same problem on the site tried to the the upgrade.

@mediaink

0.9.2.5 versione release is only simply security fix: all problems discovered on 0.9.2.4 version is the same and unfixed, and also on 0.9.2.5 have some negative unfixed problems … Nothing, for now, was fixed!

@digip

Default password on WordPress since version 3.1 is 12 characters (alphanumeric+simbles)

Foe my personal opinion best numbers is 15 characters! (alphanumeric+simbles) Strong Password Generator

For some for some reason of general security is recommended chmod:

/.htaccess 404
/favicon.ico 404
/robots.txt 404
/index.php 400
/wp-blog-header.php 400
/wp-config.php 400
/xmlrpc.xml 400 if CMS 404 if BLOG
All others files 604

/ 705
/wp-admin/ 701 (dir and subdir)
/wp-content/ 705 (dir and subdir)
/wp-includes/ 701 (dir and subdir)

This WP-Trik described take advantage of 404 not found HEADER error reply (same of default /wp-includes/) ??

delete /wp-content/index.php
delete /wp-content/plugins/index.php
delete /wp-content/themes/index.php
delete /wp-content/upload/index.php

Change default wp_ table prefix with wp_????????_ (?=alphanumeric character)

wp-config.php

define('FS_CHMOD_FILE',0604);
define('FS_CHMOD_DIR',0705);
define('DISALLOW_FILE_EDIT',true);
define('DISALLOW_FILE_MODS',true);//disable dashboard update link

.htaccess rules:

IndexIgnore *
Options -Indexes
#
# WP Upgrade Protection
#
<Files upgrade.php>
Order Allow,Deny
Deny From All
</Files>
#
<Files upgrade-functions.php>
Order Allow,Deny
Deny From All
</Files>
#
# WP Install Prevention
#
<Files install.php>
Order Allow,Deny
Deny From All
</Files>
#
<Files install-helper.php>
Order Allow,Deny
Deny From All
</Files>
#
<Files setup-config.php>
Order Allow,Deny
Deny From All
</Files>
#
<Files wp-config-sample.php>
Order Allow,Deny
Deny From All
</Files>
#
# WP Default Protection
#
<Files .htaccess>
Order Allow,Deny
Deny From All
</Files>
#
<Files wp-config.php>
Order Allow,Deny
Deny From All
</Files>
#
<Files readme.txt>
Order Allow,Deny
Deny From All
</Files>
#
<Files readme.html>
Order Allow,Deny
Deny From All
</Files>
#
<Files license.txt>
Order Allow,Deny
Deny From All
</Files>
#
<Files gpl-2.0.txt>
Order Allow,Deny
Deny From All
</Files>
#
RewriteEngine On
RewriteBase /
#
RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule .* - [L
#
RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
#
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST|PROPFIND|OPTIONS|PUT)$ [NC]
RewriteRule .* - [F,NS,L]
#
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ .+\ HTTP/(0\.9|1\.0|1\.1) [NC]
RewriteRule .* - [F,NS,L]
#
# Block the include-only files
#
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
#
# Skip WordPress 404 Error for Static Files
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} \.(php|css|js|htc|html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|otf|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|ttf|ttc|wav|wma|wri|xla|xls|xlsx|xlt|xlw|zip)$ [NC]
RewriteRule .* - [L]
#
# BEGIN WordPress

Hardening WordPress and Changing File Permissions

.htaccess headers rules:

#
FileETag none
#
Header set X-Frame-Options "SAMEORIGIN"
Header unset Accept-Ranges
Header unset ETag
Header unset Pragma
#
BrowserMatch MSIE ie
Header set Imagetoolbar "no" env=ie
Header set X-Content-Type-Options "nosniff" env=ie
Header set X-UA-Compatible "IE=edge" env=ie
Header set X-XSS-Protection "1;mode=block" env=ie
#
BrowserMatch SAFARI safari
Header set X-XSS-Protection "1;mode=block" env=safari
#
BrowserMatch CHROME gc
Header set X-Content-Type-Options "nosniff" env=gc
#
BrowserMatch chromeframe gcf
Header set Imagetoolbar "no" env=gcf
Header set X-Content-Type-Options "nosniff" env=gcf
Header set X-UA-Compatible "IE=edge,chrome=1" env=gcf
Header set X-XSS-Protection "1;mode=block" env=gcf

w3-total-cache-config.php

Never cache the following pages:
wp-.*\.php
Cache exception list:
wp-comments-popup.php
wp-links-opml.php
wp-locations.php
wp-login.php
Non-trailing slash pages:
index\.php
humans\.txt
robots\.txt
sitemap\.txt
sitemap\.xml(\.gz)?
sitemap_index\.xml(\.gz)?
Specify page headers:
Accept-Encoding
Accept-Ranges
Connection
Content-Encoding
Content-Length
Content-Type
ETag
Pragma
Server
Transfer-Encoding
Vary
X-Frame-Options
X-CF-Powered-By
Imagetoolbar
X-Content-Type-Options
X-Pingback
X-UA-Compatible
X-XSS-Protection

W3TC injection protection:

delete /wp-content/w3tc/index.html
delete /wp-content/w3tc/index.php

Put this .htaccess on:

/wp-content-/w3tc/dbcache/
/wp-content-/w3tc/objectcache/

.htaccess to put it:

Order Allow,Deny
Deny From All

functions.php

/* Disable Self Pings */
function no_self_ping(&$links){$home=get_option('home');foreach($links as $l => $link)if(0 === strpos($link,$home))unset($links[$l]);}add_action('pre_ping','no_self_ping');

/* Remove WordPress version from header */
remove_action('wp_head','wp_generator');

/* Hide blog URL from WordPress 'phone home' */
function disabler_remove_url($default){global $wp_version;return 'WordPress/'.$wp_version;}add_filter('http_headers_useragent','disabler_remove_url');

// Remove Login Error Message on wp-login.php
add_filter('login_errors',create_function('$a',"return null;"));

/* Block Bad Queries*/
$request_uri_array = apply_filters('request_uri_items', array('eval\(', 'CONCAT', 'UNION\+SELECT', '\(null\)', 'base64_', '\/localhost', '\/pingserver', '\/config\.', '\/wwwroot', '\/makefile', 'crossdomain\.', 'proc\/self\/environ', 'etc\/passwd', '\/https\/', '\/http\/', '\/ftp\/', '\/cgi\/', '\.cgi', '\.exe', '\.sql', '\.ini', '\.dll', '\.asp', '\.jsp', '\/\.bash', '\/\.git', '\/\.svn', '\/\.tar', ' ', '\<', '\>', '\/\=', '\.\.\.', '\+\+\+', '\:\/\/', '\/&&'));
$query_string_array = apply_filters('query_string_items', array('\?', '\[', '\]', '\.\.\/', '127\.0\.0\.1', 'localhost', 'loopback', '\%0A', '\%0D', '\%22', '\%27', '\%3C', '\%3E', '\%00', '\%2e\%2e', 'union', 'input_file', 'execute', 'mosconfig', 'environ', 'path\=\.', 'mod\=\.'));
$user_agent_array = apply_filters('user_agent_items', array('binlar', 'casper', 'cmswor', 'diavol', 'dotbot', 'finder', 'flicky', 'jakarta', 'libwww', 'nutch', 'planet', 'purebot', 'pycurl', 'skygrid', 'sucker', 'turnit', 'vikspi', 'zmeu'));

if (
	preg_match( '/' . implode( '|', $request_uri_array ) . '/i', $_SERVER['REQUEST_URI'] ) ||
	preg_match( '/' . implode( '|', $query_string_array ) . '/i', $_SERVER['QUERY_STRING'] )
	// || preg_match( '/' . implode( '|', $user_agent_array ) . '/i', $_SERVER['HTTP_USER_AGENT'] )
) {
	header('HTTP/1.1 403 Forbidden');
	header('Status: 403 Forbidden');
	header('Connection: Close');
	exit;
}

If use FeedBurner (plugins) to replace default WordPress Feed, instruct W3TC to no Minify Feed:

w3-total-cache-config.php

HTML minify settings:
Don't minify feeds (checked)

Instruct W3TC to no Minify Inline Script to maintain default WordPress behavior:

w3-total-cache-config.php

HTML minify settings:
Inline JS minification (unchecked)

Instruct W3TC Don’t cache pages for logged in users to reduce server load:

w3-total-cache-config.php

Page Cache General:
Don't cache pages for logged in users (unchecked)

sLaNGjI’s, thank you for your kind reply.

My site was working fine before the upgrade using 0.9.2.4. I have also four other sites with 0.9.2.4 and have no problems. My issue is specific to 0.9.2.5. TDF in this tread above had also similar issues with Disk cache.

I am using Litespeed web server. Any pointers are appreciated.

@slangji’s: Thank you very much for your kind reply. I actually was already using manual with the Minify. I agree, it is better.

Started getting numerous 500 errors on my website tonight. My ISP host looked into it and told me “On further checking, I could see that there were large number of cache files under the plugin w3tc. It was the processing of these files that delayed the execution of the PHP scripts.”

She “renamed the cache files and this has significantly reduced the server load.”

I do understand that the changes made to this version of the plugin were very minor. It could all be a coincidence. But reporting here in case it’s helpful to someone.

In the meantime, I’ve disabled minify in the settings.

@alexwoolfson

If you Set Minify to Manual, No CPU Load was Increased … ?? Consider to re-enable it!

Bye ??

I’ve updated to .5 and now all page caching is non-functional as TDF and Mediaink have reported.

Timestamps are always fresh and turning on debugging for page caching, it always reports “not cached”.

I’m using Disk: Basic.

I’m going to try and revert back to .4 as the load on my server is too high!!!

Please help.
Thanks,
Rich

I’ve reverted back to .4 and I still get no page caching.

This is not good!

Rich

For those whose page caching stopped working with the update to .5, someone has posted a fix to this. It is only for Disk: Basic page caching, which is exactly what stopped working for me. I’ve applied the fix and it seems to be working.

https://www.wmiles.com/2013/01/03/w3tc-cache-preload-for-version-0-9-2-5

Rich