La función de un servidor DNS (Nameserver - NS ) es la de resolver IPs a nombres y al revés. Como funciona la resolución? Pues bien, pongamos un ejemplo:

Nuestro NS es ns.hispahack.org y el nombre que nos han dicho que resolvamos es "memo.lala.lelo.com".
Lo que hara nuestro nameserver es destripar la dirección en partes. Primero consultará a uno de los ROOT-nameservers de Inet quien sirve el dominio "com". El NS tiene una lista de estos ROOT-NS con sus IPs asociadas, luego no tiene que consultar ya que IPs tienen (sino no conseguiria resolver nunca nada). Bueno, pues consulta el dominio "com". Entonces obtiene la dirección del NS que sirve al dominio "com". A continuación pregunta a ese NS quien sirve el dominio "lelo". Obtiene la direccion de otro NS, a éste le pregunta quien sirve el dominio "lala", obtiene la direccion de otro NS y le pregunta que IP tiene la maquina "memo". Asi, ya ha obtenido la IP de "memo.lala.lelo.com", pongamos, por ejemplo, que es 123.123.123.123.

Aquí ha terminado el trabajo de nuestro NS, que además de resolver la dirección, la guarda en su cache para futuras consultas.
La cache es un registro de las últimas direcciones que resolvió el NS, por si se le consulta sobre éstas no tener que volver a resolverlas.

Nota: Éste es el funcionamiento de un NS que soporta la función de recursividad (la mayoria). Esto significa que si el NS no sirve la dirección que se le pide que resuelva, enviara la peticion a otro NS para que la resuelva, hasta obtener la resolución o un error de dirección irresoluble. Si el NS no tiene esta función de recursividad, simplemente, si sirve el dominio de la dirección que le pedimos que resuelva la resolvera, y sino nos dira que no puede resolverla, que nos busquemos la vida.

Por tanto, las vulnerabilidades que se explican mas adelante, SOLO AFECTAN A SERVIDORES DNS QUE SOPORTAN RECURSION
 
 

Datagramas DNS.

El protocolo DNS se comunica por UDP, un protocolo de transporte sin conexión, es decir, que lanza el paquete a la red, y ya no se preocupa mas de él. Ésto imposibilita que se lleve un control del flujo de la conexión, correccion de errores, etc. Éste es un punto muy importante, pues UDP no puede, al contrario que TCP, mantener un flujo de comunicación entre dos hosts, con los ya conocidos sequence numbers.

Asi pues si queremos spoofear o meternos en medio de una conexion UDP no tendremos que predecir estos seqnums.
Podeis consultar la estructura de los datagramas DNS en la RFC 1035 si quereis datos más concretos sobre como funciona.

Dado que el protocolo de transporte no identifica los paquetes por conexión, debe ser el protocolo DNS el que asigne a los paquetes una "identificación" para poder saber que paquete responde a una pregunta anterior, etc.
A esta identificación se le llama QueryID y la asigna el NS que inicia la comunicación (el que pregunta). A partir de ese momento todos los paquetes referentes a la resolucion de esa pregunta iran identificados con ese QueryID.
 
 

Inyección de datos falsos en la cache de un NS.

A continuación viene la parte interesante, como engañar a un NS para que resuelva un nombre dado a una IP que queramos nosotros o al revés.
 
 

Método A: Suplantación de un NS.

Para este ataque debemos disponer de:

- Un NS primario (al que pueda consultar cualquier ordenador sobre un dominio)

La técnica es la siguiente...

Digamos que nosotros somos m1.hh.org (1.1.1.1) y el ns que controlamos es ns.xs.com y queremos spoofear como XXX.lechuck.org al NS ns.victim.com.

Se trata de hacernos pasar por el ns de lechuck.org  y hacer creer a ns.victim.com que ha resuelto bien a XXX.lechuck.org. Para crear este "paquete" con información falsa, el NS de victim.com debe preguntarnos sobre él, y en ese momento sera cuando nosotros contestemos. Pero como no somos el NS de lechuck.org no podemos saber cual será el QueryID de ns.victim.com. Por tanto tenemos un problema, como sabemos el QueryID que tendrá el paquete que preguntará sobre XXX.lechuck.org ?

Si hacemos una consulta a ns.victim.com sobre una dirección que sirva el ns.xs.com (por ejemplo, consultamos www.xs.com), ns.victim.com se pondrá en contacto con ns.xs.com y le preguntará la dirección de www.xs.com, nuestro NS le responderá, y tan contentos. Dado que previamente habremos sniffado la conexion con nuestro NS por parte de ns.victim.com preguntando por la direccion de www, sabremos con que QueryID ha preguntado.
El QueryID del protocolo DNs no es un número aleatorio o pseudo-aleatorio como el de algunas implementaciones de TCP, sino que es secuencial, ésto es, que para cada pregunta, aumenta en uno el QueryID. Esto es así porque el QueryID no se diseñó como un mecanismo de seguridad ante posibles spoofs, sino como una manera de controlar que respuesta corresponde a que pregunta y al revés.

Pues bien, una vez tenemos el QueryID del NS víctima creamos un datagrama DNS con la información falsa que queremos transmitir (XXX.lechuck.org <-> 1.1.1.1 ), como si la enviara el NS de lechuck.org, y con destino a ns.victim.com.
Hacemos una consulta al ns.victim.com preguntando por alguna direccion del dominio lechuck.org y inmediatamente enviamos el paquete de respuesta spoofeado.
En lugar de enviar un paquete es conveniente enviar unos cuantos, con QueryIDs consecutivos, dado que en el tiempo en que hemos tardado entre que obtenemos el queryID y solicitamos la consulta por lechuck.org el NS victima puede haber recibido otras peticiones de resolución, y por tanto el QueryID puede haber aumentado ligeramente.

Asi, si ns.victim.com recibe antes nuestra respuesta que la respuesta del NS de lechuck.org (en caso de que exista) o un error indicando que no hay tal dominio (en caso de que no exista) ya tendremos en la cache del NS víctima la información falsa que queriamos inyectarle.
 
 

Método B: Inyección de datos en nuestra respuesta.

Para este ataque debemos disponer igual que antes de un NS primario.

Esta técnica consiste en...

Cuando un NS hace una consulta a otro no sabe que numero de respuestas puede obtener a su query, ni le importa, pues todo lo que sea información lo recibirá con mucho gusto.
Pues bien, si al hacer una consulta a un NS, además (o en lugar) de la información que solicita se le devuelve la informacion falsa que nosotros queramos, el NS que preguntó la aceptará y ya la tendremos en la cache del DNS que nos preguntó :)

Así, aplicado al caso anterior, lo único que debemos hacer es preparar nuestro NS (ns.xs.com) para que responda con la información falsa (XXX.lechuck.org <->1.1.1.1) a las preguntas de un NS (ns.victim.com) y hacer que el NS víctima pregunte a nuestro NS.

Este método es mucho más sencillo y efectivo que el anterior, aunque requiere mas recursos para que funcione, pues debemos modificar el programa servidor de nombres o bien hacer un programa que funcione como tal, y que sirva nuestros datos falsos.
 
 

Impacto.

Aparte del uso que todos podais estar pensando para este tipo de ataques a DNS (fanfarronear en IRC) hay multitud de usos mucho más serios, en que la seguridad de muchos sistemas puede quedar comprometida:

- NFS (Network File Sharing) en sistemas que exporten para nombres de hosts

- Servicios r* (rlogin, rsh, etc.) haciendonos pasar por "trusted hosts".

- TCP Wrappers que se basen en nombres de hosts para cortar el paso.

- ...
 
 

Conclusión.

El protocolo DNS es sensible a ataques de este tipo, y probablemente existen muchas más vulnerabilidades que las que aquí se han descrito.

El primer ataque seria evitable si se usase un protocolo de transporte como TCP, con números de sequencia "aleatorios" o bien usando QueryIDs tambien más o menos aleatorios.

La segunda vulnerabilidad es ya inherente al protocolo DNS, y necesitaria de una profunda revisión de la especificación de DNS para controlar que las respuestas se correspondan con lo que hemos preguntado.