[AXFR] Intur y Continental DNS Zone Transfer

Esta técnica es muy útil cuando realizamos un pentesting ya que nos puede entregar información sobre los subdominios, especialmente si encontramos un dominio relacionado con “testing”, “nivel”, o algo relacionado, ya que podriamos acceder a sistemas que se encuentren en desarrollo, que a diferencia con los que se encuentran en producción, suelen tener menos restricciones y son más faciles de explotar.

Intur

| intur.hn            SOA     ns629.dizinc.com dnsadmin.pass19.dizinc.com 
| intur.hn            MX      intur.hn                                    
| intur.hn            NS      ns629.dizinc.com                            
| intur.hn            NS      ns630.dizinc.com                            
| intur.hn            A       72.29.74.75                                 
| cpanel.intur.hn     A       72.29.74.75                                 
| ftp.intur.hn        A       72.29.74.75                                 
| localhost.intur.hn  A       127.0.0.1                                   
| mail.intur.hn       CNAME 
| webdisk.intur.hn    A       72.29.74.75                                 
| webmail.intur.hn    A       72.29.74.75                                 
| whm.intur.hn        A       72.29.74.75                                 
| www.intur.hn        CNAME 
|_intur.hn            SOA     ns629.dizinc.com dnsadmin.pass19.dizinc.com 

Continental

Para que los atacantes no extraigan demasiada información de los servidores DNS, se deben emplear una serie de técnicas. Primero, debemos estar seguros que no se está filtrando información adicional. El DNS es necesario para mapear nombres hacia y desde direcciones IP, e indicar servidores de nombres y correo, no se requiere otra información adicional, como información de los sistemas internos. Los nombres de dominio no deben indicar el tipo del sistema operativo. Segundo, se deben restringir las zonas de transferencia, se deben adoptar directrices que especifiquen las direcciones IP y redes, que vamos a permitir para iniciar las transferencias de zona. Muchas organizaciones tienen sus DNS secundarios en ISPs, y muchos de estos no limitan las transferencias de zonas, en estos casos es aconsejable ponerse en contacto con el administrador e indicarle que política ha de seguir. Por último es recomendable aplicar la técnica de split DNS para limitar la cantidad de información DNS que está disponible al público. Se podría usar un servidor DNS externo y otro interno. El externo contendría la información que puede hacerse pública y el interno contendría información para nuestros sistemas internos. Con la técnica de split DNS los atacantes sólo tendrán acceso a los DNS externos, mientras que los usuarios de la red interna podrán resolver tanto nombres internos como externos.

En algunos casos nos encontramos con la sorpresa de que existen subdominios que apuntan a direcciones IP locales, por ejemplo “nivel.dominio.com -> 10.0.0.55″ pero sabemos (o creemos saber) que justo ese subdominio comparte alojamiento con sitios que estan en produccion, por ejemplo “dominio.com -> some.ip.publica.xxx”, basta con que forcemos que localmente nos resuelva “nivel.dominio.com” a esa IP publica y logramos entrar a una zona supuestamente de acceso local.

Pero como lo forzamos?

 Tenes 1 servidor con dos virtualhost, uno “site.com” y el otro “test.prueba.com”, el dns.site.com resuelve lo siguiente:

site.com -> some.ip.publica.xxx
test.site.com -> 192.168.0.5 (ip privada)

Cuando alguien de afuera intenta ingresar a test.site.com, resolvera a una ip privada, por lo que no podra acceder.

Pero, que pasa si editas tu archivo /etc/hosts agregando:

test.site.com -> la.ip.publica.de.sitio.com

cuando ingreses a http://test.site.com podrías verlo.

Hasta la PROXYma.

Posted in: hacks , secinfo