systemadmin.es > LAMP y web > Range header: Ataque de denegación de servicio para Apache 1.x y 2.x

Range header: Ataque de denegación de servicio para Apache 1.x y 2.x

Con el siguiente breve mensaje en Full-disclosure se ha publicado (0-day) un script en perl que permite hacer un ataque DoS a un servidor web con Apache mediante el header Range (CVE-2011-3192):

(see attachment)
/Kingcope

A partir del código publicado, podemos comprobar si nuestro servidor web se encuentra afectado mediante el siguiente código:

#!/usr/bin/perl

use IO::Socket;

sub usage {
print "usage: perl test.rangeheaderdos.pl <host>\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-\r\nAccept-Encoding: gzip\r\nUser-Agent: test-range-header\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;	
}

$v = testapache();
if ($v == 0) {
	print "Host does not seem vulnerable\n";
	exit;	
}

Lo guardamos en un fichero y pasamos la web a comprobar, en caso que no sea vulnerable obtendremos:

# perl test.rangeheader.pl systemadmin.es
Host does not seem vulnerable

Por el contrario, si es vulnerable obtendremos lo siguiente y, a diferencia del script original, no lanzamos el ataque:

# perl test.rangeheader.pl www.vulnerable.com
host seems vuln

El exploit lo que hace es mandar múltiples peticiones con el header Range para todos los posibles bytes y aceptando compresión: De esta forma hace que el apache intenta comprimir todas estas partes por separado, consumiendo mucha RAM.

HEAD / HTTP/1.1
Host: systemadmin.es
Range:bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6, (...)

Existen varias formas de mitigar el ataque, a espera que se corrija el problema. En DaboWeb las enumeran. Personalmente me quedo con la siguiente:

Deberíamos deshabilitar mod_deflate eliminando las entradas AddOutputFilterByType/SetOutputFilter DEFLATE y, como en el caso del slowloris, podemos situar un nginx en modo proxy para realizar dicha tarea.

Para ello deberemos añadir lo siguiente para realizar la compresión en el nginx en lugar de usar mod_deflate:

gzip on;
gzip_vary on;
gzip_comp_level	9;
gzip_types text/plain text/xml text/css application/javascript application/x-javascript application/x-httpd-php application/rss+xml application/atom_xml text/javascript;

10 comments to “Range header: Ataque de denegación de servicio para Apache 1.x y 2.x”

  1. Enhorabuena como siempre por la información y gracias por la mención a Daboweb -;).

    Sólo añadir a tu entrada tan completa que, a modo de comprobación, tiren el script también contra la IP del servidor, no sólo hacia las webs alojadas, ya que los resultados pueden diferir (me ha pasado a mi en algún caso-;).

    Saludos !!

  2. Creo que esto te pasa porque se debe hacer contra algo que de un 200. Por ejemplo, contra el típico web.com que hace el redirect con las www no te funcionaria: Debe existir el contenido sobre el que hacer el Range

  3. Se me olvidaba, si quieres borra este comentario /*Parezco un spammer*/ o lo metes con el otro que me doy cuenta ahora del tema, hablan de que no habrá parche para la rama 1.x pero…¿crees que será temporal o definitivamente? Me he quedado un poco mosca con ello, aunque imagino que a medida que pasen los días nos iremos enterando.

    Saludos de nuevo -;)

  4. Entiendo que al ser una versión deprecada no quieran mantenerla ni para problemas como este, lo veo comprensible.

    El End of Life esta en la 1.3.42:

    http://archive.apache.org/dist/httpd/Announcement1.3

  5. Al probar con este dominio me arrojo este error.
    test.rangeheader.pl www.cobreloa.cl

    respuesta :
    Can’t use an undefined value as a symbol reference at /usr/local/bin/test.rangeheader.pl line 15.

  6. Parece que no hayas incluido el parámetro, pero te debería dar el usage. Puedes comprobar que no haya ningún error al hacer el paste del código

    saludos,

  7. #Creo que esto te pasa porque se debe hacer contra algo que de un 200

    Cierto, por eso lo comentaba, para que la gente con dedicados o VPS lo tenga en cuenta, algún cliente y colegas me decían que estaban parcheados y luego tiraba yo el script contra la IP y veían que no -;)

    Sobre el final del ciclo sí, pero si te fijas en;

    There will be no more full releases of Apache HTTP Server 1.3.
    However, critical security updates may be made available from the
    following website:

    http://www.apache.org/dist/httpd/patches/

    En todo caso, cierto es que es una versión ya depreciada aunque algunos sigan usándola (hay mucho miedo a las migraciones como bien sabes) pero vaya, nos enteraremos.

    Un abrazo !

  8. Hombre, depende de como de complicado sea el parche siempre se puede intentar un backport. En mi caso no tengo servidores con 1.x, por lo que no me preocupa demasiado

    saludos!

  9. Al pasar el script killapache sobre una web, es posible que bote el servidor?, ocurriría algo malo o solo sirve para poner en evidencia que la máquina es vulnerable?, gracias.

  10. El killapache si es vulnerable lo ataca, por lo que es mejor no usarlo. Por eso he recortado la parte de comprobación (en el post esta) para únicamente comprobar si es o no vulnerable tal como lo hace el killapache

Deja un comentario:

XHTML - Tags permitidos:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>