Encuentro Alternativo

En este post intentaré explicar una de las vulnerabilidades que tenía planeado tapar en los servidores DNS que administro. La vulnerabilidad es la de transferencia de zonas DNS bajo AXFR, que está corriendo en la red desde hace un buen tiempo, pero nunca había hablado de ella en este blog.

AXFR es el mecanismo que se usa para replicar las transferencias desde los dns maestros a los esclavos, esto debería siempre estar bajo esta condición, pero una de las cosas que se suelen olvidar (también em mi caso en su tiempo) es securizar la transferencia de zonas. ¿Qué implica no securizarlas? Pues.. implica que la información de cada registro DNS de la zona del dominio que despacha el server DNS vulnerable, está expuesta a todo el mundo, y en especial a los posibles atacantes, los cuales pueden hacer uso de un simple DIG para ver toda la red de registros que posee tu infraestructura, para posteriormente, lanzar ataques.

Para este ejemplo, les contaré del banco más importante de Uruguay, tiene esta vulnerabilidad abierta, exponiendo así los servidores de correo, aduanas, concursos, entre otros. En si, esto no es tan malo si los servidores están correctamente securizados a nivel de aplicaciones y resto de los servicios, pero vamos a asumir que no lo están, puede derivar en un grave problema de seguridad, ataques ddos o escalada de privilegios, entre otros.

Como testear un server DNS por transferencias de Zonas:
Elegimos el sitio, supongamos: banco.com.uy

[webtech@vostrolan ~]$ dig banco.gub.uy NS | grep NS
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;banco.gub.uy. IN NS
;; ANSWER SECTION:
banco.gub.uy. 21598 IN NS garchalf2.banco.gub.uy.
banco.gub.uy. 21598 IN NS paddok.banco.gub.uy.
[webtech@vostrolan ~]$


La línea que nos interesa, es la resaltada en negrita, la cual delata los Name Servers que usa el server, la tomamos y realizamos el test AXFR, en este ejemplo he quitado algunas líneas excesivamente largas, pero deberías ver algo así:

[webtech@vostrolan ~]$ dig @paddok.banco.gub.uy banco.gub.uy axfr
; <<>> DiG 9.6.1-P3-RedHat-9.6.1-16.P3.fc12 <<>>
@paddok.banco.gub.uy banco.gub.uy axfr
; (1 server found)
;; global options: +cmd
banco.gub.uy.		21600	IN	NS	paddok.banco.gub.uy.
banco.gub.uy.		21600	IN	NS	garchalf2.banco.gub.uy.
banco.gub.uy.		21600	IN	A	200.40.149.67
banco.gub.uy.		21600	IN	MX	10 mail.banco.gub.uy.
aduana.banco.gub.uy.	21600	IN	A	200.108.xxx.xxx
correo.banco.gub.uy.	21600	IN	A	200.108.xxx.xxx
localhost.banco.gub.uy.	21600	IN	A	127.0.0.1
morosos.banco.gub.uy.	21600	IN	A	200.108.xxx.xxx
tasas.banco.gub.uy.	21600	IN	A	200.108.xxx.xxx
valores.banco.gub.uy.	21600	IN	CNAME	portal.banco.gub.uy.
www.banco.gub.uy.		21600	IN	CNAME	www1.banco.gub.uy.
www1.banco.gub.uy.	21600	IN	A	200.40.xxx.xxx
www2.banco.gub.uy.	21600	IN	A	200.40.xxx.xxx
zerozerosix.banco.gub.uy.	21600	IN	A	200.108.xxx.xxx
;; Query time: 393 msec
;; SERVER: 200.40.149.76#53(200.40.149.76)
;; WHEN: Mon Feb  8 10:29:43 2010
;; XFR size: 46 records (messages 1, bytes 1195)
 
[webtech@vostrolan ~]$

Si ves eso, es que el server está abierto, por el contrario, si ves algo así, es que está cerrado a transferencias de zonas:

[webtech@vostrolan ~]$ dig @ns1.pepito.com pepito.com axfr
; <<>> DiG 9.6.1-P3-RedHat-9.6.1-16.P3.fc12 <<>> @ns1.pepito.com pepito.com axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.
[webtech@vostrolan ~]$

En próximo post explicaré como securizar la transferencia de zonas en Bind.

Lecturas recomendadas:

http://cr.yp.to/djbdns/axfr-notes.html