Masiva actualización coordinada de servidores DNS: Grave vulnerabilidad

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…sigue

LEER mas en hispasec.com

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