Testing ‘Apache Killer’

I ran the tool to attack this server as well as my employer’s load balanced array of servers. It is clear that only those servers running an older version of Apache (i.e. 1.3) and those not protected by a firewall are at risk.

My underpowered virtual private server crashed just a few seconds after the attack began. The tool revealed that my employer’s web sites did not appear to be vulnerable.

Is there a solution?

While a solution from Apache.org has not been published, some of the contributors have identified the issue and are working on a patch. In the meantime, you can add the following rule to your virtual site definitions, if you own your sever, or .htaccess file if you’re in a shared-hosting environment.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]
RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
RewriteRule .* - [F]
</IfModule>

The preceding rule blocks “get and head requests with multiple ranges in the Range HTTP header.”

After applying this rule, feel free to attempt to kill your server, it will not crash. You should inspect your traffic logs to verify the incoming traffic is denied access with an HTTP status of 403, or forbidden.

Dirk-Willem van Gulik from Apache published this workaround for versions 2.0 and 2.2:

<IfModule mod_setenvif.c>
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
</IfModule>

Right now there is a worm making its way around old, unpatched versions of WordPress. This particular worm, like many before it, is clever: it registers a user, uses a security bug (fixed earlier in the year) to allow evaluated code to be executed through the permalink structure, makes itself an admin, then uses JavaScript to hide itself when you look at users page, attempts to clean up after itself, then goes quiet so you never notice while it inserts hidden spam and malware into your old posts.

Here are two quick steps to avoid unnecessary risks:

Turn off user registration

This one is simple. Just log in to your administrator screen and visit the “General Settings” screen (listed under Settings) and make sure the checkbox labeled “Anyone can register” is not checked.

Block access to your blog’s admin area

This can be accomplished with simple authentication.

If your site runs on Apache, you can create an .htaccess file in your /wp-admin/ directory to require authentication before the page is displayed. This post provides the necessary steps.

The task becomes a lot easier under Apache. So I threw away the plugin code and added the following rule to the Apache configuration:

<directory "/public_html/mysite.com">
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*) https://%{HTTP_HOST}/$1	[R,L]
</directory>

The directive above can be placed inside a VirtualHost or Directory directives, but this usually requires access to the Apache server configuration, which is not typically possible in a shared hosting environment — in that case, the rule can be added to the .htaccess file.

Alternatively we could have used the SSLRequireSSL Apache (2.x) directive, but this would only block access to the non HTTPS address. In our case we want to automatically redirect the users instead of displaying an error message.