DNS: Vulnerabilidad de transferencias de zonas o “AXFR”

Se dice que si un intruso no puede ingresar por la puerta, intenta por la ventana. Desde el lugar del atacante, los DNS pueden ser una “ventana” que nos permita obtener información sobre la estructura interna de una web y facilitarnos un acceso.

Existen varias técnicas para la extracción de datos mediante los DNS, pero en este artículo trataremos sólo una, conocida como “Vulnerabilidad de transferencias de zonas” o “AXFR”.

Nuestro objetivo:

Hoy en día es habitual encontrarse sitios web con gran cantidad de servicios. Sin ir más lejos: Google. Accedemos al buscador mediante www.google.com, sin embargo al ingresar a los diferentes servicios (mail, noticias, video, etcétera) la URL va cambiando: mail.google.com, news.google.com, video.google.com. El dominio sigue siendo google.com pero algo cambia antes, a esos nombres que varían se los conoce como subdominios.

Estos subdominios comunes y corrientes no aportan ningún dato significativo para realizar un ataque. Nuestro objetivo es encontrar aquellos que no son accesibles desde la página web pero valen la pena descubrir, muchos administradores crean subdominios, por ejemplo, de paneles de administración.

 

Ahora somos servidores DNS secundarios:

Si un servidor DNS primario no se encuentra disponible para responder las consultas que recibe, el secundario se encargará de hacerlo. El registro SOA indica cada cuanto tiempo un servidor secundario debe consultar el serial del primario y realizar una transferencia de zonas para actualizar sus datos. Lo interesante está en que estos servidores se transfieren exactamente lo que nosotros queremos obtener. Por tanto existe la posibilidad de hacernos pasar por un servidor secundario, solicitar una transferencia de zonas y visualizar todos los subdominios de nuestro objetivo.

Para realizar la transferencia de zonas vamos a utilizar la herramienta Dig que se encuentra en los sistemas Linux (también es posible llevarla a cabo desde Windows con Nslookup). En primer lugar consultamos cuales son los servidores DNS del dominio objetivo, ejecutamos en la terminal:

dig ns dominio-objetivo.com

 

La respuesta podría ser similar a la siguiente:

;;ANSWER SECTION

dominio-objetivo.com 600 IN NS ns01.servidordns.com

dominio-objetivo.com 600 IN NS ns02.servidordns.com

 

Elegimos uno de los servidores DNS que nos imprima, por ejemplo el “ns01.servidordns.com” y realizamos la transferencia de zonas o AXFR con el siguiente comando:

dig @ns01.servidordns.com dominio.com.ar AXFR

En primer lugar a continuación del arroba (@) escribimos el servidor DNS que elegimos, luego el dominio a consultar (nuestro objetivo) y al final indicamos que es un AXFR. El resultado podría ser similar al de la imagen:

 

 

Mediante esta transferencia de zonas pudimos obtener subdominios interesantes (FTP y Mail) que podrían servirnos a la hora de atacar el objetivo. Tenemos a disposición una gran cantidad de herramientas programadas para encontrar subdominios útiles mediante técnicas de fuerza bruta o diccionario. La técnica de AXFR es mucho mas rápida y efectiva pero, por desgracia para el atacante, solo funciona si el servidor DNS primario esta mal configurado y permite realizar transferencias de zonas a cualquier parte.

 

Solución al problema:

Ahora nos ponemos en el lugar del administrador encargado de la seguridad (¡Que se acaba de enterar que tiene este problema!). La solución es fácil, en el caso de utilizarse el servidor BIND es necesario localizar el archivo de configuración llamado: named.conf.local. La idea es limitar la transferencia de zonas únicamente a los servidores secundarios, por tanto dentro de las zonas creadas en este archivo, especificamos las direcciones IP de los mismos con la siguiente línea: allow-transfer { 192.168.1.102; }; Entre llaves se especifica la o las direcciones IP de los servidores secundarios. La configuración de una zona podría quedar de la siguiente manera:

Zone “nuestrositio.net” {

type master;

file “/etc/bind/db.nuestrositio.net”;

allow-transfer { 192.168.1.102; };

};

Sin más, le ponemos fin al problema.

#EOF

Fuente: blog.educacionit.com