DNS Abuse roots http://www.ezkracho.com.ar Conceptos Básicos. La función de un servidor DNS (Nameserver/NS ) es la de resolver IPs a nombres y viceversa. Como funciona la resolución? veamos: Nuestro NS es ns.elites.com y el nombre que nos han dicho que resolvamos es "box1.intrac.victim.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, consulta el dominio "com". Entonces obtiene la dirección del NS que sirve al dominio "com". Después pregunta a ese NS quien sirve el dominio "victim". Obtiene la direccion de otro NS, a éste le pregunta quien sirve el dominio "box1", obtiene la direccion de otro NS y le pregunta que IP tiene la maquina "intrac". Asi, ya ha obtenido la IP de "box1.intrac.victim.com", pongamos, por ejemplo, que es 134.134.134.134. Aquí ha terminado el trabajo de nuestro NS, que además de resolver la dirección, la guarda en su cache. La cache es un registro de las últimas direcciones que resolvió el NS, por si se 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. 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. Si queremos spoofear o meternos en medio de una conexion UDP no tendremos que predecir estos seqnums. 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 hace el request). 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 máquina sobre un dominio) Aca vamos Digamos que nosotros somos m2.espejito.org (1.1.1.1) y el ns que controlamos es ns.zc.com y queremos spoofear como xxx.panial.org al NS ns.victima.com Se trata de hacernos pasar por el ns de xxx.panial.org y hacer creer a ns.victima.com que ha resuelto bien a xxx.panial.org. Para crear este "paquete" con información falsa, el NS de ns.victima.com debe preguntarnos sobre él, y en ese momento sera cuando nosotros contestemos. Pero como no somos el NS de xxx.panial.org no podemos saber cual será el QueryID de ns.victima.com. Por tanto tenemos un problema, como sabemos el QueryID que tendrá el paquete que preguntará sobre xxx.panial.org ? Si hacemos una consulta a ns.victima.com sobre una dirección que sirva el ns.zc.com. ns.victima.com se pondrá en contacto con ns.zc.com y le preguntará la dirección de www.zc.com, nuestro NS le responderá, y tan contentos. Dado que previamente habremos sniffeado la conexion con nuestro NS por parte de ns.victima.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. Una vez tenemos el QueryID del NS víctima creamos un datagrama DNS con la información falsa que queremos transmitir (xxx.panial.org <-> 1.1.1.1 ), como si la enviara el NS de panial.org, y con destino a ns.victima.com. Hacemos una consulta al ns.victima.com preguntando por alguna direccion del dominio xxx.panial.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 xxx.panial.org el NS victima puede haber recibido otras peticiones de resolución, y por tanto el QueryID puede haber aumentado ligeramente. Asi, si ns.victima.com recibe antes nuestra respuesta que la respuesta del NS de xxx.panial.org (si existe) 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. Veamos.. 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 va a recibir 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í, lo único que debemos hacer es preparar nuestro NS (ns.zc.com) para que responda con la información falsa (xxx.panial.org <->1.1.1.1) a las preguntas de un NS (ns.victima.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, 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 están pensando para este tipo de ataques a DNS como tener un host personalizado al entrar al 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. 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. No se olviden de leer la RFC 1536 Puesta en practica del metodo B Vamos a suponer que ya tenemos lo que necesitabamos, un host que sea NS primario de un dominio y otro host donde haremos correr nuesto programa "inyector" de informacion falsa DNS. Vamos a suponer esta situacion: - Nameserver primario: ns.zc.com - Host que corre el inyector: 134.134.134.134. Voy a exponer aqui cual serian las modificaciones a hacer a la configuracion del demonio DNS suponiendo que este es el "named", el que con mas probabilidad vais a encontrar en un server un*x. Lo primero que hacemos es consultar en el fichero de configuracion del named donde almacena la informacion de los dominios que sirve. Este fichero es el /etc/named.boot o en las nuevas versiones de bind es /etc/named.conf y se ha modificado un poco la estructura del fichero, en cuyo caso vas a tener que adaptar las explicaciones que de aqui un poco). En nuestro ejemplo, contiene lo siguiente: directory /var/named cache . root.cache primary zc.com db.zc.com secondary castor.org db.castor.org Esto significa: directory /var/named : Directorio base donde almacena los ficheros de configuracion de los dominios primary zc.com db.zc.com : Es un NS primario del dominio zc.com, y lo almacena en el fichero db.zc.com (El que nos interesa) secondary castor.org : Es Ns secundario del dominio castor.org, y lo almacena en el fichero db.castor.org (Este no nos interesa) Miramos al fichero db.zc.com (que como sabemos, estara en /var/named): zc.com. IN SOA ns.zc.com. root.zc.com. ( 1997062100 28800 7200 604800 86400) zc.com. IN NS ns.zc.com. localhost IN A 127.0.0.1 XXX IN A 10.0.0.1 owned.zc.com. IN A 10.0.0.2 Las primeras lineas se refieren a la configuracion del dominio, quien lo gestiona, las fechas de expiracion, etc. A continuacion esta la configuracion de los Nameservers del dominio: zc.com. IN NS ns.zc.com. En esta linea se especifica que el host "ns.zc.com" sirve al dominio zc.com. Aqui es donde vamos a hacer la modificacion. Tenemos que insertar una linea en que se reconozca a nuestro host inyector como nameserver de este dominio. A la derecha de un IN NS solo se acepta un FQDN, es decir, no podemos poner una ip numérica. Asi que vamos a tener que crear un host y luego asignarle una IP. La primera modificacion quedaria asi con lo que hemos supuesto antes: zc.com. IN NS ns.zc.com. zc.com. IN NS ns1.zc.com. Ahora vamos que tener que asignarle la IP a este host nuevo que hemos creado (ns1.zc.com). Para asignar una IP numerica a un FQDN, se usa el RR "IN A", tal como se puede ver en las siguientes lineas: XXX IN A 10.0.0.1 owned.zc.com. IN A 10.0.0.2 La segunda linea, asigna la IP 10.0.0.2 al FQDN owned.zc.com. El punto al final de owned.zc.com. es muy importante, ya que si no le ponemos punto (como a XXX) el named le pone al final el nombre del dominio (zc.com). Asi, para insertar la linea que queremos, y segun lo que hemos supuesto antes, utilizariamos esta linea: ns1.zc.com. IN A 134.134.134.134. Asi ya tenemos el named configurado para el spoof. Solo nos queda recargar esta informacion en el named (killall -HUP named), esperar a que la informacion se propague y poner a trabajar el programa inyector.