17 posts categorized "security"


GlobalSign Temporarily Ceases SSL Certificate Issuance

See this article on ABC News for more details as Belgium-based Certificate Authority GlobalSign has temporarily ceased ssl certificate issuance in the wake of the announcement yesterday from comodohacker that he(?) has managed to breach 4 other major CAs. GlobalSign was the only one of the four high-profile CAs specifically named.


Mitigating the Apache Range Header DoS on Ubuntu Apache 2.2

If you are running apache 2.2 (the current version in Ubuntu Server on my recently created VM being 2.2.17) and you wish to mitigate your web server against exploitation by the Apache Range Header Denial of Service vulnerability and the killapache exploit, below is the mitigation steps that worked best for me.

Ubuntu's Apache 2 implementation utilizes httpd.conf for user specific server configuration changes. The mitigation suggestion from the Apache Software Foundation that had the most favorable impact was scrubbing the Range Header if an incoming request contains more than 5 ranges within that specific request. Please note that this fix may not help with future versions of the exploit.

The workaround makes use of mod_headers, which, on a stock ubuntu server apache2 installation, is not enabled. You can enable it using the command line:

sudo a2enmod headers

Once that is complete, modify your servers httpd.conf and add the following directives:

SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range

If you want to enable logging of hosts sending you those range requests, modify the configuration file for your virtual server—if you add it to the httpd.conf, the log file will get created but nothing will get logged. For example, if you are using the instance, modify the /etc/apache2/sites-available/default configuration file and add the following line somewhere that makes sense:

CustomLog /var/log/apache2/range-CVE-2011-3192.log common env=bad-range

That's all you need to do. Pretty straightforward workaround but hopefully a more formal fix will be made available by the Ubuntu Server team soon.


Here's a Preliminary "Apache Killer" Test Script

There is a nasty exploit in the news lately, a perl-based script called "Apache Killer" that provides an easy way to issue a denial of service attack against an apache server from a single source.  The Register has a complete write-up on the vulnerability and the exploit, SANS has started covering it in this article, and you could just grab it from the Full Disclosure mailing list or visit my friends over at PenTestIT for a writeup and download and they also have a workaround folks can implement via mod_rewrite (although it might not be appropriate for every site).

The exploit is fairly easy enough to modify but I assume that within the next day or so, anti-virus clients will start quarantining the exploit if found on the filesystem of certain machines.  I've written a script, which might receive some heavy modifications over the next couple days,  that attempts to assess whether a server (or site) is vulnerable to the Apache Range Header Denial of Service Vulnerability.  The intent of my implementation is to assess the existence of the vulnerability but prevent more than one connection to the site and containing no exploit code.

It's still preliminary because I have unanswered questions/concerns with the exploit.  The exploit appears to be sending the following request (with request headers) to the target server in order to determine if the server "seems" vulnerable:

HEAD / HTTP/1.1  
Accept-Encoding: gzip  
Connection: close

My test ubuntu server running apache 2.2.17 responds with the following http response headers:

HTTP/1.1 206 Partial Content 
Date: Wed, 24 Aug 2011 18:44:32 GMT 
Server: Apache/2.2.17 (Ubuntu) 
Last-Modified: Thu, 04 Aug 2011 03:23:21 GMT 
ETag: "20abb-b1-4a9a580b93ac0" 
Accept-Ranges: bytes 
Vary: Accept-Encoding 
Content-Encoding: gzip 
Content-Range: bytes 0-145/146 
Content-Length: 146 
Connection: close 
Content-Type: text/html 

The exploit seems to assume a server is vulnerable simply because it returned a 206 Partial Content status code. The problem is that the same test run against an IIS server gives the same 206 Parital Content response and, as far as I know at this particular point in time, IIS is not known to be exploitable.  But maybe that's not the case?  The original vulnerability was reported back in 2007 and listed both Apache and IIS as being vulnerable.  I wonder if anyone tested this exploit against an IIS host.  So, my current quandary with my implementation here is that I do not have the confidence yet that simply retrieving a 206 Partial Content status code is enough to formally declare the target system vulnerable. Update: Interestingly, the exploit finds tomcat to be vulnerable, too!  See the discussion on ServerFault

I think I will have a better idea of what to test for when the new versions of apache httpd are released.  Here is the current version of my script, it uses LWP::UserAgent and HTTP::Headers and is intended to work with perl version 5.10 or above:

#!/usr/bin/env perl

# Apache Killer assessor

use strict;
use warnings;
use feature ':5.10';

use HTTP::Headers;
use LWP::UserAgent;

my $host = $ARGV[0];
my $port = $ARGV[1];
my $scheme;

my $help = "Usage:  $0  ";

if ( !@ARGV ) {
    print $help . "\n";
    exit 0;

if ( $port == 443 ) {
    $scheme = 'https';
else {
    $scheme = 'http';

my $message;

my $objHeader = HTTP::Headers->new;
  $objHeader->header('Host' => $host);
  $objHeader->header('Range' => 'bytes=0-');
  $objHeader->header('Accept-Encoding' => 'gzip');
  $objHeader->header('Connection' => 'close');

my $url = "$scheme://$host:$port/";

    my $method = "HEAD";
    my $ua  = LWP::UserAgent->new;
    my $req = HTTP::Request->new( $method, $url, $objHeader );

    my $resp = $ua->request($req);

    given ($resp->code ) {
        when (206) {
            say "Response Status Code: " . $resp->status_line;
            say "Web Server Seems Vulnerable to Apache Range Header DoS Vulnerability";
        when (301) {
            say "Redirect Present.  Potential False Positive";
            say "Retry request against: " . $resp->header('Location');
        when (302) {
            say "Redirect Present.  Potential False Positive";
            say "Retry request against: " . $resp->header('Location');
        when (307) {
            say "Redirect Present.  Potential False Positive";
            say "Retry request against: " . $resp->header('Location');
        when (403) {
            say $resp->status_line;
            say "This is not an expected response code at this time."
        when (404) {
            say $resp->status_line;
            say "This is not an expected response code."
        when (405) {
            say $resp->status_line;
            say "HTTP Method HEAD is not permitted.";
            say "This is overkill!";
        when (501) {
            say $resp->status_line;
            say "HTTP Method HEAD is not implemented.";
            say "This is overkill!";
        default {
            say $resp->status_line;