La vulnerabilidad en las DNS

A comienzos del mes de julio Dan Kaminsky hizo publica la noticia. La mayoria de servidores de nombres de Internet sufrian un fallo de diseño que podía permitir a un atacante cambiar el destino al que apunta una dirección web con su nombre (sería el caso más visible pero por supuesto afecta a todos los servicios que dependen de la resolución de dominios)

El fallo afecta a multitud de sistemas y varias empresas han lazando parches desde entonces para intentar solucionar el problema (Microsoft, Sun, Cisco, Red Hat, Debian, Apple.. ) aunque según parece no han tenido el efecto esperado y la vulnerabilidad sigue estando presente en los servidores que han sido parcheados.

Para llegar a entender este problema lo mejor es empezar desde cero y explicar que es un servidor DNS. Tal vez, la forma más sencilla de entenderlo es hacer un símil con la agenda de un teléfono móvil. Cuando seleccionas un nombre en la agenda, el móvil se encarga de marcar su número. De la misma manera, un servidor DNS se encarga de resolver la dirección IP de una URL (o dirección de Internet) Ésta es su función más común pero también se encarga de indicar el servidor de correo electrónico de un dominio, por ejemplo.

Por supuesto, dada la gran cantidad de dominios existentes en Internet, el funcionamiento de esta agenda es mucho más complejo que el de una simple agenda de móvil con cientos de entradas. Es por ello que cada ISP y cada servidor de hosting disponen de múltiples servidores DNS.

En el mundo de las DNS existe una pequeña jerarquía, hay 13 servidores raíz en todo el mundo y además también hay servidores por cada tipo de dominio (.com, .net, .es) denominados dominios de nivel superior y de ellos dependen el resto de servidores según el nombre de dominio que tengan (son las denominadas zonas)

Una vez vista la estructura de los servidores DNS, su funcionamiento es bastante sencillo. Cuando escribimos una dirección en nuestro navegador, nuestro ordenador la envía al servidor DNS de nuestro proveedor de Internet. Desde este servidor se envía una petición a un servidor raíz, el servidor raíz indica el servidor que tenga delegada la zona correspondiente a la dirección de la petición. El servidor de nuestro ISP interroga a este servidor y así sucesivamente hasta encontrar el servidor del hosting donde está alojada la web y que devolvera la dirección IP correspondiente para establecer la conexión.

Para evitar repetir estos procesos se utiliza un sistema de cache en los servidores DNS, el sistema es bastante sencillo y añade un campo (TTL) donde se indica el tiempo que permanecerá almacenada la resolución de la petición en el servidor DNS de nuestro ISP, con lo cual el tiempo de respuesta será mucho menor.

Lamentablemente, este sistema de cache puede ser corrompido, tal y como demuestra la vulnerabilidad descubierta por Kaminsky. El sistema de DNS utiliza el protocolo UDP, un protocolo más sencillo y antiguo que TCP. Además de ser un protocolo que no garantiza la llegada de paquetes entre máquinas requiere muy pocos campos para comprobar la veracidad de un paquete, con lo cual, es bastante sencillo suplantar un paquete UDP y colárselo al servidor DNS, el resultado será un servidor DNS con su cache repleta de resoluciones incorrectas.

Los efectos para el usuario pueden ser desastrosos, pues, en cierta manera, se crea un problema de seguridad similar al phishing (se redirige al usuario a páginas que no son las verdaderas)

A pesar de la primera oleada de parches parece que todavía se está intentando encontrar una solución duradera (que no pase por redefinir el funcionamiento de las DNS) y de todas maneras, muchos servidores todavía no han aplicado los parches ya existentes, con el consiguiente riesgo para los usuarios.

Se puede hacer un seguimiento de todo este asunto en la web de Kriptópolis, de donde está sacada la mayor parte de información y enlaces de este artículo.

Más información:

• Guía ilustrada de la vulnerabilidad, por Steve Friedl.
• Nota de la vulnerabilidad en la web del US-CERT.
• Entrada en el diario de la web sans.org.