M!x

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.

sanata

Casualmente y casi como una paradoja, el día anterior a que fueran reiniciados los servidores de DNS (8 de julio) Guanakoo fue defaceado y el día siguiente a este masivo reinicio (9 de julio) fue hackeada nuestra base de datos, en el peor ataque que sufrimos en los 2 años que llevamos en la red.

Lo que me preocupa, como decía en el otro post que escribí sobre el tema, es el silencio y las mentiras de los ISP para con sus clientes. Por ejemplo, si llamabas (o llamás a Anteldata) entre el 8 de julio y el día de hoy, porque muchos sitios eran (y son) inaccesibles, la respuesta a secas es: "son problemas generales que estamos solucionando" y ninguna advertencia, sobre el riesgo de realizar transacciones comerciales en estas condiciones.

__________________