Apache Range Exploit Detector

Find out if your apache web server is vulnerable to the apache range explot.

http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3C20110824161640.122D387DD@minotaur.apache.org%3E

Find

Determine which hosts are vulnerable.

Locate servers you manage

Find which servers are exploitable.

You may enter up to 10 servers at once. SSL servers are now supported, please enter a url such as: http://example.com

Don't trust me?

No problem, try the following php code yourself

function check_for_exploit($host,$port=80,$timeout=10){
	$range = '0-1';
	for($i=0;$i<20;$i++){
		$range .= ",5-$i";
	}

	$error_code = null;
	$error = null;

	$socket = fsockopen($host,$port,$error_code,$error,$timeout);
	$packet = "HEAD / HTTP/1.1\r\nHost: $host\r\nRange:bytes=$range\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n";
	fwrite($socket,$packet);
	$result = fread($socket,2048);
	//check to see if "Partial" is in the response
	if(strstr($result,"Partial") !== false){
		return true;
	}
	return false;
}

Fix

Prevent the exploit from happening.

Choose one.

Choose a solution from the following for whatever works best for you.

There is currently no full fix for this vulnerability, the following solutions are temporary fixes. Please revisit this site in the future or follow the apache mailing list for discussion.

Upgrade Solution - Best Solution

This exploit was fixed in Apache 2.2.20, you can review the changelog, you can download the latest apache version. More information is available at CVE-2011-3192.

This solution is the best fix because Apache is able to determine the file size and determine if all of the byte ranges exceed the file than it simply returns the file and ignores the range requests.

Rewrite Solution

If you have mod_rewrite running this is one of the easiest solutions.

Simply add this to your .htaccess file.

RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]

SetEnvIf Solution

If you have SetEnvIf enabled this is also an easy solution.

Add the following to your .htaccess file.

SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging, uncomment and set path to log matches
# CustomLog /var/log/range-CVE-2011-3192.log common env=bad-range

Headers Solution

If you have mod_headers enabled this solution will completely disable file resuming support. What this means is that users will not be able to suspend/resume file downloads. This is not a good solution if you host large files.

Add the following to your .htaccess file.

RequestHeader unset Range

Learn

Why should I care?

What causes this?

If a request is made to apache to resume a file at a specific point by using the Range property in the request that contains numerous ranges apache will need to allocate increasing amounts of memory to service the request. By sending many requests coupled with range boundaries it can cause apache to exhaust all available memory and start swapping to disk.

What happens?

If apache is targetted and the attack continues the server will exhaust all available memory and begin using swap, if swap is exhuasted processes are likely to be killed. If you're interested you can read about how linux handles running out of memory

Credits

I found out about this vulnerability from Dirk-Willem van Gulik viahttp://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3C20110824161640.122D387DD@minotaur.apache.org%3E"

The vulnerability checker is based a perl exploit tool from HI-TECH at http://seclists.org/fulldisclosure/2011/Aug/176

I'm just the guy that built this page, all credit should be associated with the people who found and distributed solutions, information, research, and the exploit. — Jesse Janzer

Changelog

1.0 - August 25th, 2011 07:00 MST

  • Initial Release

1.1 - August 25th, 2011 11:00 MST

  • Added SSL support

1.2 - August 26th, 2011 08:00 MST

  • Added ip host checking thanks to David's and Maurizio De Santis's comment

1.3 - September 7th, 2011 19:32 MST

  • Updated lookup to prevent false positives for 2.2.20 release

Share

blog comments powered by Disqus