Toda Internet en peligro por culpa del DNS?

El DNS siempre fue un gran olvidado por años en lo que respecta a la seguridad en IT, aunque últimamente muchos venían levantando voces sobre el peligro que representaba. Ahora, todos parecen haberse puesto de acuerdo en el problema gracias al especialista en seguridad Dan Kaminsky, y todos los grandes pilares de Internet y del Software, como Cisco, Microsoft, Debian, Red Hat, y un larguísimo etcétera, están liberando parches para solucionarlo.

El problema que existe con el servicio de DNS es tan viejo como su propia creación probablemente, y radica en la forma en que se realizan las transacciones entre los servidores DNS no autoritativos que realizan consultas a otros servidores y cacheo de las respuestas. DNS utiliza el protocolo UDP, que es liviano y a diferencia de TCP no tiene ningún control de sesión o secuencia de paquetes, por lo que la respuesta a cada petición DNS es autenticada únicamente mediante estas condiciones:

• Debe existir una petición exclusiva para esa respuesta.
• La dirección IP de origen debe ser la misma a cuyo servidor se le envió la petición.
• Cada petición utiliza un número de ID único de 16 bits, el cual debe ser idéntico al de la respuesta.
• La respuesta debe ser enviada al mismo puerto de donde se originó la petición.

Hasta acá parece que la seguridad estaría bastante cubierta, pero como siempre, del dicho al hecho hay largo trecho, y en la práctica las cosas no son tan lindas como en la teoría.

Empecemos porque bajo determinadas circunstancias se puede falsificar una dirección IP de origen, en este caso para que parezca que viene del servidor DNS al que se le hizo el request. Pero eso no es todo. El campo de ID, el verdadero número de autenticación de una petición/respuesta DNS, al ser de 16 bits sólo puede tener 65.536 combinaciones posibles; dicho número se supone que debe ser creado, para cada petición, por un generador de números pseudoaleatorios lo suficientemente fuerte como para evitar que pueda adivinarse fácilmente. El problema es que no todas las implementaciones de servidor DNS tienen generadores lo suficientemente "aleatorios" como para que alguien no pueda adivinar en qué rango estarán estos números, con lo que las posibilidades de acierto del ID aumentan mucho. Si a eso le sumamos que el puerto de origen también se vuelve fácil de adivinar por implementaciones como la de BIND (famoso servidor DNS del mundo *nix) donde el puerto de origen cambia aleatoriamente, pero una sola vez al reiniciar, saliendo luego todas las peticiones desde el mismo, la cosa toma más color y se vislumbra la posibilidad de un ataque, en varios paquetes de respuesta falsos que deben llegar antes que el del servidor original (sería una ventana de aproximadamente 1 segundo), o acallando a este mediante un ataque DDoS relámpago. Si uno de esos paquetes la pega, podemos decirle entonces, por ejemplo, que para el dominio banco-online.com, al que el usuario X quería ingresar para chequear su cuenta bancaria, la dirección IP no es la real de ese sitio, sino, claro, la de un sitio falso idéntico al anterior, que pretende mediante el phishing robar la clave del visitante en cuestión, y de todos los demás que deseen visitar dicho dominio en ese momento ya que la resolución con esa IP falsa quedará guardada por un buen tiempo el la caché del servidor DNS; de ahí que uno de los nombres de este ataque sea DNS cache poisoning.

Muchos argumentan que esta movida, esta respuesta conjunta y articulada de todos los involucrados en las entrañas de Internet tiene que ver no con la novedad de un conjunto de vulnerabilidades que ya se conocían de hace tiempo, sino con el surgimiento de algún nuevo exploit capaz de aprovecharlas de manera muy eficiente. No dudo que sea ese el motivo.

Qué podemos hacer nosotros? Si somos administradores y mantenemos algún servidor DNS, implementar las actualizaciones correspondientes a la plataforma utilizada, así como también para todas las estaciones de trabajo, ya que las vulnerabilidades en muchos casos afectan también al cliente DNS de cada host, pero tomando precauciones; hay reportes de que por ejemplo Zone Alarm detecta el nuevo comportamiento de las peticiones DNS como una especie de malware y las bloquea. En el caso de todos como usuarios, además de actualizar nuestro equipo con los últimos parches, podemos verificar si los servidores DNS de nuestro ISP son vulnerables mediante el chequeador de vulnerabilidad DNS que Kaminsky publicó en su sitio web. Y como este test de momento nos dará casi con seguridad que nuestro ISP tiene servidores vulnerables, la mejor opción es usar los de OpenDNS, que no están afectados.

Más información en:

Kriptópolis: Fallo crítico en DNS obliga a parchear toda Internet

US-CERT: Multiple DNS implementations vulnerable to cache poisoning

DShield: Multiple Vendors DNS Spoofing Vulnerability

Dark Reading: Vendors Issue Massive Simultaneous Patch for Common Internet Flaw

Actualización: Al parecer se filtró antes de tiempo parte de la información confidencial que Kaminsky venía guardando para evitar que los exploits estén disponibles antes que los parches, en el blog de Matasano Security expusieron detalles que borraron rápidamente, pero como siempre, Google recuerda todo.

Compártelo

Entradas Relacionadas

Top 100 de especies en extinción

Cómo evitar que se roben tu cuenta de GMail

OpenDNS, es tu amigo?

Fallo DNS: Ya parcheamos, realmente estamos seguros ahora?

Clickjacking, el nuevo cuco de la inseguridad en Internet