El rincón de Zerial

Informática, GNU/Linux, Seguridad, Hacking, Programación, Ocio

Mostrar menú Ocultar menú

AXFR: Una vulnerabilidad que pasa desapercibida …

julio 22, 2011 /
Información Importante Sobre el Contenido

Estas accediendo al contenido antiguo del blog. Este artículo "AXFR: Una vulnerabilidad que pasa desapercibida ..." es de dominio público y no será mantenido a futuro. Cualquier error o problema acerca del contenido por favor contactate conmigo desde la sección contacto.

Las transferencias de zona en los servidores de DNS en simples palabras se usa para replicar lo que hay en un maestro hacia su escalvo. Si esta caracteristica se encuentra mal configurada podria ser usada por un atacante para obtener información sensible sobre el dominio.
Un servidor maestro debe filtrar por dirección IP qué esclavos pueden realizar transferencias, si esto no se configura correctamente entonces cualquier atacante podría consultar por las zonas de los dominios que administra.

imagen: https://getglue.com/topics/p/dns_zone_transfer

Las transferencias de zona se realizan mediante AXFR, que según su descripción:

Las siglas AXFR hace referencia a la transferencia por zonas de un DNS primario a un DNS secundario o de un DNS primario a un server maestro y de un server maestro a un DNS secundario, si llegara a existir algún problema de configuración o actualización del software de cualquiera de estos servidores se podrían explotar una serie de vulnerabilidades como por ejemplo un DoS y la integridad y confidencialidad de la base de datos del DNS primario se verían comprometidas, se estima que alrededor de un 60% de los servidores DNS en internet son vulnerables.

(Fuente: https://es.wikipedia.org/wiki/AXFR)

Tambien exsite la transferencia de zona incremental (IXFR).

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”, “devel”, 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.

Como ejemplo, vamos a tomar el dominio “defensa.gob.es” y vamos a consultar si alguno de sus dns tiene habilitada la transferencia de zona.

Los DNS asociados a ese dominio son:

  1. ns01.mde.es
  2. ns02.mde.es
  3. ns03.mde.es

Probando uno por uno solo el ns02 es vulnerable:

Trying Zone Transfer from ns01.mde.es: Failed.
Trying Zone Transfer from ns02.mde.es: Success.
Trying Zone Transfer from ns03.mde.es: Failed

Entonces obtenemos la zona:

; < <>> DiG 9.8.0-P4 < <>> AXFR defensa.gob.es @ns02.mde.es
;; global options: +cmd
defensa.gob.es.		180	IN	SOA	ns01.mde.es. dnsadm.mde.es. 2011061802 180 60 4320000 180
defensa.gob.es.		180	IN	NS	ns01.mde.es.
defensa.gob.es.		180	IN	NS	ns02.mde.es.
defensa.gob.es.		180	IN	NS	ns03.mde.es.
defensa.gob.es.		600	IN	A	193.33.2.129
e-admin.defensa.gob.es.	600	IN	CNAME	e-admin.mde.es.
ns01.defensa.gob.es.	600	IN	A	193.33.2.99
ns02.defensa.gob.es.	600	IN	A	193.33.2.100
ns03.defensa.gob.es.	600	IN	A	193.33.3.99
sede.defensa.gob.es.	600	IN	A	193.33.2.137
procedimientos.sede.defensa.gob.es. 600	IN A	193.33.2.138
www.defensa.gob.es.	600	IN	CNAME	defensa.gob.es.
defensa.gob.es.		180	IN	SOA	ns01.mde.es. dnsadm.mde.es. 2011061802 180 60 4320000 180
;; Query time: 244 msec
;; SERVER: 193.33.2.100#53(193.33.2.100)
;; XFR size: 13 records (messages 1, bytes 351)

Y solo por probar, intentamos hacer transferencia de zona de “mde.es” usando el mismo nameserver:

; < <>> DiG 9.8.0-P4 < <>> AXFR mde.es @ns02.mde.es
;; global options: +cmd
mde.es.			3600	IN	SOA	ns01.mde.es. dnsadm.mde.es. 2011071502 180 60 4320000 180
mde.es.			600	IN	TXT	"v=spf1 a:smtp10.mde.es. a:smtp03.mde.es. ~all"
mde.es.			3600	IN	NS	ns01.mde.es.
mde.es.			3600	IN	NS	ns02.mde.es.
mde.es.			3600	IN	NS	ns03.mde.es.
mde.es.			600	IN	MX	10 smtp01.mde.es.
mde.es.			600	IN	MX	10 smtp02.mde.es.
mde.es.			600	IN	A	193.33.2.129
www.aire.mde.es.	600	IN	CNAME	www.ejercitodelaire.mde.es.
www.armada.mde.es.	600	IN	A	193.33.2.129
autodiscover.mde.es.	600	IN	CNAME	pdagw.mde.es.
campusvirtual.mde.es.	600	IN	A	193.33.2.140
cvcdef.mde.es.		600	IN	A	193.33.2.135
e-admin.mde.es.		600	IN	A	193.33.2.133
e-admin1.mde.es.	600	IN	A	193.33.2.134
ea.mde.es.		600	IN	TXT	"v=spf1 a:smtp10.mde.es. a:smtp03.mde.es. ~all"
ea.mde.es.		600	IN	MX	10 smtp01.mde.es.
ea.mde.es.		600	IN	MX	10 smtp02.mde.es.
autodiscover.ea.mde.es.	600	IN	CNAME	autodiscover.mde.es.
www.ea.mde.es.		600	IN	CNAME	www.ejercitodelaire.mde.es.
opencms.ejercito.mde.es. 600	IN	CNAME	web.mde.es.
www.ejercito.mde.es.	600	IN	CNAME	web.mde.es.
www.ejercito-aire.mde.es. 600	IN	CNAME	www.ejercitodelaire.mde.es.
www.ejercito-del-aire.mde.es. 600 IN	CNAME	www.ejercitodelaire.mde.es.
www.ejercitoaire.mde.es. 600	IN	CNAME	www.ejercitodelaire.mde.es.
www.ejercitodelaire.mde.es. 600	IN	CNAME	web.mde.es.
et.mde.es.		600	IN	TXT	"v=spf1 a:smtp10.mde.es. a:smtp03.mde.es. ~all"
et.mde.es.		600	IN	MX	10 smtp01.mde.es.
et.mde.es.		600	IN	MX	10 smtp02.mde.es.
autodiscover.et.mde.es.	600	IN	CNAME	autodiscover.mde.es.
extm.mde.es.		600	IN	MX	10 extm.mde.es.
extm.mde.es.		600	IN	A	193.33.2.132
extranet.mde.es.	600	IN	A	193.33.2.33
fn.mde.es.		600	IN	TXT	"v=spf1 a:smtp10.mde.es. a:smtp03.mde.es. ~all"
fn.mde.es.		600	IN	MX	10 smtp01.mde.es.
fn.mde.es.		600	IN	MX	10 smtp02.mde.es.
autodiscover.fn.mde.es.	600	IN	CNAME	autodiscover.mde.es.
tiknet.g2b.mde.es.	600	IN	A	193.33.2.136
www.invied.mde.es.	600	IN	CNAME	web.mde.es.
localhost.mde.es.	600	IN	A	127.0.0.1
ns01.mde.es.		600	IN	A	193.33.2.99
ns02.mde.es.		600	IN	A	193.33.2.100
ns03.mde.es.		600	IN	A	193.33.3.99
oc.mde.es.		600	IN	TXT	"v=spf1 a:smtp10.mde.es. a:smtp03.mde.es. ~all"
oc.mde.es.		600	IN	MX	10 smtp01.mde.es.
oc.mde.es.		600	IN	MX	10 smtp02.mde.es.
autodiscover.oc.mde.es.	600	IN	CNAME	autodiscover.mde.es.
pdagw.mde.es.		600	IN	A	193.33.2.145
portalcultura.mde.es.	600	IN	CNAME	mde.es.
www.portalcultura.mde.es. 600	IN	CNAME	web.mde.es.
www.rmo.mde.es.		600	IN	CNAME	web.mde.es.
servicios.mde.es.	600	IN	A	193.33.2.44
sscc.sigeloc.mde.es.	600	IN	A	80.26.76.36
smtp.mde.es.		600	IN	CNAME	smtp01.mde.es.
smtp01.mde.es.		600	IN	A	193.33.2.97
smtp02.mde.es.		600	IN	A	193.33.2.98
smtp03.mde.es.		600	IN	A	193.33.3.97
smtp10.mde.es.		600	IN	A	193.33.2.102
smtp11.mde.es.		600	IN	A	193.33.3.102
www.ume.mde.es.		600	IN	CNAME	web.mde.es.
wap.mde.es.		600	IN	CNAME	mde.es.
web.mde.es.		600	IN	A	193.33.2.129
working.mde.es.		600	IN	CNAME	web.mde.es.
www.mde.es.		600	IN	CNAME	mde.es.
wwwr.mde.es.		600	IN	A	193.33.3.129
mde.es.			3600	IN	SOA	ns01.mde.es. dnsadm.mde.es. 2011071502 180 60 4320000 180
;; Query time: 246 msec
;; SERVER: 193.33.2.100#53(193.33.2.100)
;; XFR size: 66 records (messages 1, bytes 1713)

En algunos casos nos encontramos con la sorpresa de que existen subdominios que apuntan a direcciones IP locales, por ejemplo “devel.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 -> alguna.ip.publica.xxx”, basta con que forcemos que localmente nos resuelva “devel.dominio.com” a esa IP publica y logramos entrar a una zona supuestamente de acceso local.

Información Importante Sobre el Contenido

Estas accediendo al contenido antiguo del blog. Este artículo "AXFR: Una vulnerabilidad que pasa desapercibida ..." es de dominio público y no será mantenido a futuro. Cualquier error o problema acerca del contenido por favor contactate conmigo desde la sección contacto.

Categorías: Hacking, Seguridad

Etiquetas: , , , , , , , , , , ,

« Cross-Site Scripting en CMS Newtenberg Engine Búsqueda de servicios DNS con Transferencia de Zona abierta (AXFR) »

17 comentarios

  1. newedge

    julio 23, 2011 a las 3:03 am

    Hola Zerial

    no entiendo el ultimo parrafo: “En algunos casos nos encontramos con la sorpresa de que existen subdominios que apuntan a direcciones IP locales, por ejemplo “devel.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 -> alguna.ip.publica.xxx”, basta con que forcemos que localmente nos resuelva “devel.dominio.com” a esa IP publica y logramos entrar a una zona supuestamente de acceso local.”

    En concreto no entiendo cuando dices “forzar a que localmente nos resuelva devel.dominio.com a esa IP publica”

    Te refieres a hacer:

    dig @name_server devel.dominio.com

    ¡Animo con el blog!

  2. Zerial

    julio 23, 2011 a las 3:08 am

    Hola newedge!

    Con ese ultimo parrafo me refiero a lo siguiente:

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

    sitio.com -> cualquier.ip.publica.xxx
    test.sitio.com -> 192.168.0.5 (ip privada)

    Cuando alguien de afuera intenta ingresar a test.sitio.com, resolvera a una ip privada, por lo que no podra acceder… Pero, que pasa si editas tu archivo /etc/hosts agregando:

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

    ??

    Pues, cuando ingreses a http://test.sitio.com podras verlo!

    A eso me refiero con “forzar”… editar tu archivo hosts para que el dominio resuelva a la ip que tu deseas.

    saludos!

  3. newedge

    julio 23, 2011 a las 6:50 am

    Ok, ya se lo que quieres decir!

    Muchas gracias

  4. agugliotta

    julio 23, 2011 a las 10:50 am

    Hola Zerial, te hago una consulta porque justamente hace unos meses agarre python para boludiar basicamente y hacer un par de scripts lo que surgio hacer una trasferencia de zona para averiguar los subdominios. Vi que tenian que tener habilitada la opciones “allow-transfer” en el archivo named.conf por lo tanto para testear busque paginas en google haciendo “allow-transfer” filetype:conf y funciono bastante bien. Ahora mi pregunta es: solamente con cambiando ese archivo desabilita la transferencia de zona? Es igual para IXFR? .

    Saludos

  5. W2P

    julio 23, 2011 a las 10:59 am

    Interesante artículo zerial, muy poca gente escribe sobre el protocolo dns y sus vulnerabilidades, por cierto, sería posible realizar otros ataques aparte del que has descrito en el texto?

    Saludos! y sigue posteando cosas interesantes!

  6. Pato

    julio 23, 2011 a las 4:26 pm

    Hola Zerial,

    Muy buena información 😉

    Una pregunta acerca de tu blog:

    ¿Tienes pensado habilitar el +1 de google?

  7. Zerial (Autor del artículo)

    julio 23, 2011 a las 7:50 pm

    agugliotta: Respecto a deshabilitar la transferencia de zona, por lo general se habilita pero se ponen restricciones por IP, que solo un esclavo (el dns secundario) pueda realizar esas transferencias, Tambien puedes deshabilitar y no permitir el AXFR, pero no te servira para tener un dns secundario como esclavo, a menos que cuando modifiques un registro en el master, lo modifiques a mano en el esclavo.

    Respecto al IXFR, a diferencia del AXFR es que es una “transferencia” incremental, que requiere un “Serial” (el tipico serial que se le ponen a las zonas) y te transfiere solo las zonas que se han modificado desde el ultimo serial.

    Te dejo estos links de apoyo:

    RFC1995 – Sobre IXFR: http://www.normes-internet.com/normes.php?rfc=rfc1995&lang=es

  8. Zerial (Autor del artículo)

    julio 23, 2011 a las 7:56 pm

    W2P: Hola! Pues, existen varios tipos de ataques a nivel de este protocolo, como por ejemplo dns spoofing, pero es a nivel de redes. Tambien hay otros usos que le podrias dar a un servidor de nombres mal configurado y que te permita hacer AXFR, como un DoS, ya que el servicio corre en el puerto 53/UDP y no tiene control de flujo y otras “propiedades” como el TCP (http://es.wikipedia.org/wiki/User_Datagram_Protocol)

  9. Zerial (Autor del artículo)

    julio 23, 2011 a las 7:57 pm

    Pato: No habia considerado ni se me habia ocurrido ponerle ese boton, pero ahora que lo mencionas… vere como puedo hacerlo 😛

  10. seth

    julio 24, 2011 a las 2:19 am

    Que programa usaste para probar los tres dns?

  11. Zerial

    julio 24, 2011 a las 1:01 pm

    hola seth: Use un script que hice. El script saca los DNS del dominio y luego uno por uno busca hacer un AXFR del dominio especificado

  13. Zerial (Autor del artículo)

    agosto 3, 2011 a las 11:46 pm

    seth: le corregiré unas cosas y lo subo, te aviso

  14. Israel L

    agosto 17, 2011 a las 12:40 pm

    Buen artículo.

    Al que esté de ocioso que pruebe con adsl.terra.cl y similares 🙂

    Saludos

  15. Eddy_TI

    diciembre 20, 2011 a las 12:51 pm

    Excelente información, muy util.

  16. tty0

    enero 2, 2012 a las 1:54 am

    sed -i ‘s/escalvo/esvlavo/g’

    Excelente artículo 🙂

  17. r0st3r

    noviembre 26, 2012 a las 5:25 pm

    wena compa, buena info 😉

    saludos.

1 Pingback

  1. Pingback: AXFR en Scotiabank | El rincón de Zerial

Los comentarios están cerrados.

© 2024 El rincón de Zerial

Tema por Anders Norén — Subir ↑