Source: https://elrincondelhax.wordpress.com/2016/05/25/usar-dns-cache-snooping-para-hacer-dns-fingerprinting/
Timestamp: 2017-10-20 12:12:18+00:00

Document:
Usar DNS Cache Snooping para hacer DNS fingerprinting – ElRinconDelHack
Usar DNS Cache Snooping para hacer DNS fingerprinting
Cuando se realiza una auditoría de seguridad externa a una organización, hay que analizar todos los servidores expuestos para descubrir si en alguno de ellos existe alguna vulnerabilidad conocida o no. Entre las fases de trabajo, lógicamente, se encuentra la de descubrimiento de huellas o footprinting y la de reconocimiento de activos por medio de inferencia de conocimiento, es decir, el fingerpriniting de los servidores. El artículo de hoy versa sobre cómo realizar una de estas tareas, para responder a una de estas fases de fingerprinting de un sistema operativo, en concreto del sistema operativo sobre el que correo un servidor DNS.
Imaginemos que durante uno de estos procesos de trabajo en un test de intrusión nos interesa saber cuál es el sistema operativo sobre el que corre el servicio de DNS de una organización.
Conocida la dirección IP o el nombre de la máquina, una primera aproximación puede ser utilizar nmap para sacar la información del servicio:
Tras los resultados devueltos en la figura anterior, podemos suponer que el servidor está detrás de un firewall. Podríamos hacer el mismo proceso para obtener información de otros servicios sobre el mismo servidor y así intentar inferir el sistema operativo que corre en el servidor, pero el resultado sería el mismo: nada de información. ¿Qué podemos hacer? Pues investigar un poco más el comportamiento de este servidor DNS para inferir el sistema operativo.
Windows Server y el servicio DNS
El servicio de DNS en Windows Server tiene la particularidad de que si tiene que resolver una consulta de DNS, como por ejemplo, una resolución directa (obtener una dirección IP a partir de un nombre), y esta información no se encuentra en la base de datos del DNS, y no se han configurado reenviadores para resoluciones recursivas, por defecto, el servidor DNS echa mano de los 13 servidores DNS raíz.
Como parece lógico, si la consulta ha de resolverla alguno de los 13 servidores DNS raíz en lugar de alguno de los reenviadores, el tiempo de resolución de la consulta puede ser aún mayor. Debido a la topología jerárquica del servicio DNS, al realizarse una consulta de resolución de nombre, si el servidor consultado no tiene la consulta cacheada, lo normal es que escale la petición a un servidor DNS superior en la jerarquía.
Podemos indicar al servidor DNS que no use recursividad para resolver las consultas y preguntarle por un nombre que no se encuentre dentro de su zona. Como es lógico, si la consulta ha sido realizada anteriormente y ésta está cacheada, el servidor DNS será capaz de resolverla. Sin embargo, si ésta no se encuentra cacheada, al no permitir resoluciones recursivas, el servidor DNS nos ofrecerá una respuesta negativa. En esta forma de consultar al servidor se basan las técnicas de DNS Cache Snooping.
Debido a la configuración por defecto del servicio de DNS en Windows Server relacionada con los 13 servidores DNS raíz, si hacemos DNS Cache Snooping al servidor DNS que estamos investigando y la respuesta de la consulta no está cacheada, devolverá como respuesta parte de los 13 servidores DNS que están configurados:
Probando con un servidor DNS público
Si hacemos DNS Cache Snooping en un servidor que se encuentre detrás de un firewall, como el de la Figura 2, ya que no podemos obtener mediante nmap el sistema operativo en función de los servicios que corren en el servidor, si éste devuelve parte de los 13 servidores DNS raíces, podemos inferir que, con alta probabilidad, se trata de un Windows Server.
Comportamiento en BIND
Veamos ahora cuál será el comportamiento de un servidor DNS montado con Bind tras la petición de una resolución directa que no sea capaz de resolver, no la tenga cacheada y no pueda realizar una petición recursiva a otros servidores de nombres. Para esta prueba, usaremos el servidor DNS utilizado en http://www.ubuntu.com. Basta simplemente obtener quién es el servidor DNS que aparece en el registro SOA de la zona y obtener qué servicio se encuentra detrás del puerto 53 UDP.
Podemos ver que se ha utilizado Bind para montar el servidor de nombres. El comportamiento del servidor DNS después de realizar DNS Cache Snooping es el siguiente:
Vemos que la respuesta del servidor DNS tras intentar resolver un nombre de dominio que se encuentra fuera de su zona impidiendo que éste pregunte a otros servidores de nombres (resolución recursiva) es Query refused.
Comportamiento de TinyDNS
Por último, veremos cuál es el comportamiento de un servidor DNS sobre TinyDNS. La idea, ver cuál es el comportamiento frente a una petición de resolución directa de un nombre de dominio que no esté en su zona y que no pueda resolver de manera recursiva. Los primero de todo, localizar un servidor DNS montado sobre TinyDNS (al fin y al cabo es DJBDNS). El utilizado por cr.yp.to puede valer:
La elección de este servidor de nombres no es algo aleatorio. La web cr.yp.to pertenece a Daniel Julius Bernstein, autor de qmail, publicfile y djbdns, de ahí el nombre de este último. Aplicando técnicas de DNS Cache Snooping, los resultados que aloja este servidor DNS frente a la petición de una resolución directa de un nombre de dominio que no se encuentra en su zona y que no se le permite resolver a través de resoluciones recursivas, es un mensaje de Time-Out. Se agotó el tiempo de espera de la solicitud como se ve en la siguiente figura:
Aplicando técnicas de DNS Cache Snooping con nombres de dominio fuera de la zona de los servidores de nombres, es posible, siempre y cuando no se hayan modificado las configuraciones por defecto de los servicios DNS, aplicar un poco de inteligencia al reconocimiento del software de DNS y al sistema operativo, aunque haya unfirewall entre medio que impida realizar fingerprinting al servicio que se esconde detrás del puerto 53 UDP. Por supuesto, las técnicas de deception podrían hacer que un software fuera configurado para simular otro, pero al menos de esta forma tenemos un poco más de información que aplicar a nuestro racionamiento posterior.
De forma esquemática, lo revisado en este artículo:
– Microsoft DNS 6.1.7601 -> responde con parte de los 13 servidores DNS raíz.
– ISC BIND 9.8.1-P1 -> Query Refused.
– TinyDNS -> Time-Out.
Obtenido de: http://www.elladodelmal.com
fecha 25 mayo, 2016

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución