• =?iso-8859-1?q?una-al-dia_=2809/07/2008=29_Masiva_actualizaci=F3n_coord

    From noticias@hispasec.com@2:341/201.99 to All on Wed Jul 9 18:50:00 2008
    ---------------------------SPOT-------------------------
    AUDITORIAS DE SEGURIDAD INFORMATICA DE HISPASEC

    Hispasec Sistemas ofrece sus servicios de auditoría de seguridad
    informática, destinados a determinar y evaluar las vulnerabilidades
    que puedan presentarse en sus sistemas.

    Más información en:
    http://www.hispasec.com/corporate/auditoria.html ---------------------------SPOT-------------------------

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    -------------------------------------------------------------------
    Hispasec - una-al-día 09/07/2008
    Todos los días una noticia de seguridad www.hispasec.com
    -------------------------------------------------------------------

    Masiva actualización coordinada de servidores DNS: Grave vulnerabilidad
    en la implementación del protocolo que "sustenta" Internet
    -----------------------------------------------------------------------

    Toda vulnerabilidad es importante y tiene un potencial impacto en la
    red. Sin embargo, cuando hablamos de la resolución de nombres y de
    problemas en los servidores DNS, la gravedad se multiplica porque se
    supone que los servidores DNS sustentan la red. La navegación, el correo
    y cualquier traducción dominio-IP se realiza en los servidores DNS. Casi
    todo dispositivo conectado a Internet necesita resolver nombres. Un
    fallo en este protocolo hace que toda la infraestructura de la red se
    tambalee. Quien domine la resolución de nombres, domina Internet.
    Presuntamente un fallo de este tipo es lo que parece que se ha
    descubierto.

    Las bases del problema descubierto no son nuevas, y no se trata de un
    fallo en la implementación de un fabricante en concreto. Más bien, se
    trata de una nueva forma de engañar a los servidores DNS para que den respuestas falsas, gracias a un fallo inherente del protocolo. No se han
    dado detalles técnicos sobre el problema. El descubridor Dan Kaminsky ha llevado en secreto su investigación durante meses, esperando a que todos
    los grandes fabricantes implicados se pusiesen de acuerdo para programar
    una solución y publicar los parches correspondientes. El 8 de julio ha
    sido el día elegido.

    El protocolo DNS y los programas que lo implementan se han visto
    lacrados desde siempre con múltiples problemas de seguridad. Por varios
    métodos distintos:

    * Atacando al servidor a través de un desbordamiento de búfer, inyectar
    código o accediendo al servidor para modificar las zonas. Aunque esto es
    ya menos común, durante los años 90, BIND el programa casi estándar de
    facto en servidores DNS, sufrió de muchas vulnerabilidades de este tipo.

    * Envenenamiento de la caché de los servidores. Un atacante puede montar
    su propio servidor DNS y "mentir" a un servidor DNS legítimo que le
    pregunta por registros que no tiene (los servidores DNS se preguntan constantemente entre sí para actualizar sus datos y redireccionar
    correctamente todos los dominios a las mismas direcciones). Esta
    transferencia contiene datos falsos que resuelven incorrectamente las
    preguntas de los clientes. El servidor legítimo almacena esa información
    falsa un tiempo en su caché (para ganar tiempo en la próxima resolución)
    y así las víctimas pueden ser enviadas a otro sitio.

    * Falsificación del ID. Este método consiste en hacerse pasar por la
    respuesta legítima de un servidor DNS. El cliente que ha hecho una
    pregunta recibe directamente una respuesta falsa de un atacante.

    Estos dos últimos métodos han sido muy populares también en los últimos
    años, con numerosas técnicas que permitían llevar a cabo el ataque. Bien
    por fuerza bruta (bombardeando con peticiones) bien por fallos de implementación del protocolo. Pero no termina de solucionarse porque en realidad, el protocolo DNS no utiliza generalmente métodos de
    autenticación. Para que un servidor DNS responda una consulta, no es
    necesario autenticarse de ninguna forma. La manera de distinguir entre consultas entre sí, está basada únicamente en tres datos: puerto UDP de
    origen, IP y DNS ID.

    Históricamente se han realizado muchos experimentos que permiten o bien adivinar o deducir tanto el puerto origen UDP desde el que se ha
    realizado una consulta como el identificador de transacción y así poder falsificar respuestas y que el cliente vaya a una dirección IP falsa.
    Este último descubrimiento, al parecer, tiene que ver una vez más con la posibilidad de conocer el número de identificador DNS y poder así
    envenenar la caché de los servidores. Este campo dispone sólo de 16 bits
    de "espacio" en la cabecera de un paquete e identifica de forma única
    una petición. Las posibilidades son de unas 32.000. Con el tiempo, se
    han ido añadiendo mejoras para evitar la fuerza bruta y hacer más
    compleja la posibilidad de conocer este identificador, pero el método
    "de base" usado sigue siendo el problema.

    No se han dado detalles técnicos sobre el fallo descubierto, aunque sí
    se sabe que los parches añaden entropía al cálculo de este identificador
    para que resulte mucho más complejo predecirlo de alguna forma. Así que
    puede que no sea un fallo totalmente nuevo (la debilidad de confiar en
    un número tan pequeño de posibilidades se conoce desde hace años) sino
    quizás alguna forma novedosa de aprovecharlo que lo hace más sencillo y
    por tanto, peligroso.

    Hasta ahora, Cisco, Microsoft, BIND y otras muchas distribuciones Linux
    han publicado sus respectivas actualizaciones, en un esfuerzo
    sincronizado y secretismo coordinado no vistos hasta la fecha. Dan
    Kaminsky (que al parecer se topó con el problema de forma casual)
    pretende dar los detalles en la conferencia Black Hat de agosto.

    En cualquier caso, y aunque el fallo sea importante, también es cierto
    que hace años, cuando los ataques de este tipo eran más sencillos y
    factibles que hoy en día, nunca se ha observado que hayan sido llevados
    a la práctica de forma masiva o generalizada por atacantes.

    Se recomienda a todos los administradores que parcheen sus sistemas
    cuanto antes.

    Opina sobre esta noticia:
    http://www.hispasec.com/unaaldia/3546/comentar

    Más información:

    Multiple DNS implementations vulnerable to cache poisoning http://www.kb.cert.org/vuls/id/800113

    CERT VU#800113 DNS Cache Poisoning Issue http://www.isc.org/index.pl?/sw/bind/bind-security.php


    Sergio de los Santos
    ssantos@hispasec.com


    Tal día como hoy:
    -----------------

    09/07/2007: Los estafadores en Internet, más solidarios que nunca
    http://www.hispasec.com/unaaldia/3180

    09/07/2006: Finaliza el soporte a versiones antiguas de Microsoft Windows
    http://www.hispasec.com/unaaldia/2815

    09/07/2005: Vulnerabilidad HTTP Request Smuggling en Apache 2.0.x
    http://www.hispasec.com/unaaldia/2450

    09/07/2004: Vulnerabilidad de falsificación de barra de direcciones en Opera
    http://www.hispasec.com/unaaldia/2084

    09/07/2003: Continúan los intentos de fraude a través de correos masivos
    http://www.hispasec.com/unaaldia/1718

    09/07/2002: Acceso al directorio 'WEB-INF' en diversos servidores de aplicaciones web
    http://www.hispasec.com/unaaldia/1353

    09/07/2001: Procesado el hacker del incidente "Viagra a Bill Gates"
    http://www.hispasec.com/unaaldia/988

    09/07/2000: "Búfer abierto", nueva sección en Hispasec
    http://www.hispasec.com/unaaldia/622

    09/07/2000: Ataques de denegación de servicio contra Windows 2000
    http://www.hispasec.com/unaaldia/621

    09/07/1999: Nuevos peligros con la utilización de las conexiones por cable y DSL
    http://www.hispasec.com/unaaldia/256


    -------------------------------------------------------------------
    Claves PGP en http://www.hispasec.com/directorio/hispasec
    -------------------------------------------------------------------
    Bajas: mailto:unaaldia-request@hispasec.com?subject=unsubscribe
    Altas: mailto:unaaldia-request@hispasec.com?subject=subscribe
    -------------------------------------------------------------------
    (c) 2008 Hispasec http://www.hispasec.com/copyright
    -------------------------------------------------------------------

    --- SoupGate-DOS v1.05
    * Origin: Pasarela FTN-INet telnet://pucelabbs.dyndns.org:4000 (2:341/201.99)