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.

Figura 1: Usar DNS Cache Snooping para hacer DNS fingerprinting

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.

Figura 2: Servidor 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:

Figura 3: Resultados devueltos por nmap

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.

Figura 4: Sugerencias raíz del servidor DNS en Windows Server

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 (ver Figura 4), 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:

Figura 5: Parte de los 13 servidroes raíz como respuesta a una consulta no cacheada y no resuelta de manera recursiva

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.

Figura 6: Resultado de una petición no cacheada ni resuelta

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 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.

Figura 7: Contenido del registro SOA de la zona

Figura 8: Servicio DNS montado sobre BIND

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:

Figura 9: Consulta no cacheada

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:

Figura 10: Servidor principal de la zona que se encuentra en cr.yp.to

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:

Figura 11: Respuesta del servidor DNS sobre TinyDNS

Conclusiones

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 un firewall 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.

Autor: Amador Aparicio (@amadapa)