Información

Está visitando los archivos de la categoría DNS.

Calendar
Mayo 2012
L M M J V S D
« Abr    
 123456
78910111213
14151617181920
21222324252627
28293031  
Categorías
Links

Archivo de la DNS categoría

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

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 correoy cualquier traducción dominio-IP se realiza en los servidores DNS. Casitodo 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 bienbadivinar 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

|