---------------------------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)