Vulnerabilidades en BIND y Soluciones

CVE Name: CVE-1999-0024

Bugtraq ID: 678

 

Descripción de los problemas

Esta advertencia contiene descripciones y soluciones para dos vulnerabilidades presentes en las distribuciones actuales de BIND. Los problemas están siendo explotados activamente en Internet.

El uso de IDs predecibles en consultas y consultas recursivas de un nameserver permite corromper su cache. Esto posibilita que un atacante altere el cache de un nameserver de forma tal que modifique la resolución de direcciones y hostnames de hosts en Internet. La ausencia de comprobaciones de tamaño en el largo de los hostnames resulta en potenciales buffer overflows en programas que esperan una respuesta de BIND de un tamaño máximo de MAXHOSTNAMELEN.

 

Problema I. Uso de queyry IDs predecibles

Problema I. - Impacto
Usuarios remotos con privilegios de 'root' pueden contaminar el cache de BIND enviando paquetes UDP con direcciones de origen falsas. Es importante notar que, a diferencia de otros ataques documentados, en este caso no es necesario que el atacante tenga control sobre algún nameserver o que pueda hacer 'sniffing' en la red del name server a atacar.

Problema I. - Detalles técnicos
Este ataque requiere que el name server atacado esté configurado para aceptar recursión de consultas. Esta facilidad permite a un name server proporcionar respuestas sobre dominios que no sirven. Al recibir una consulta por alguno de dichos dominios el name server transmitirá la consulta al name server apropiado y una vez recibida la respuesta la enviará al cliente que generó la consulta originalmente.

El siguiente ataque está descripto en el paper "Adressing weaknesses in the Domain Name System Protocol" de Christopher Schuba y Eugene Spafford [6]. Dentro de nuestro conocimiento, este problema no ha sido planteado con anterioridad. El paper asume que el atacante tiene privilegios de superusuario en algún nameserver primario; en esta advertencia demostramos que ése no es el caso y que tampoco es necesaria la habilidad de enviar paquetes IP con opciones de source routing.

Usando la facilidad de recursión, cualquiera puede corromper el cache de un name server con el siguiente procedimiento:

Problema I. - Participantes en el ataque
· HOST.ATTACKER.COM es la máquina desde la que se realiza el ataque.
· DNS.ATTACKER.COM es el nameserver para el dominio ATTACKER.COM. A fin de simplificar la descripción asumimos que es el único nameserver del dominio.
· DNS.TARGET.COM es el namserver atacado que corre BIND. Lo que intentaremos hacer es agregar un registro A (resuelve un hostname a una dirección IP) en DNS.TARGET.COM de tal manera que resuelva WWW.SPOOFED.COM a 127.0.0.1. Nos aseguramos que WWW.SPOOFED.COM no está en el cache del namserver con anterioridad al ataque.
· DNS.SPOOFED.COM es el name server del dominio SPOOFED.COM. Esto lo determinamos previamente al inicio del ataque. Nuevamente, y a fin de simplificar la descripción, asumimos que es el único name server de SPOOFED.COM

Problema I. - El ataque
1. Primero el atacante envía un query a DNS.TARGET.COM pidiendo la dirección IP de UNKNOWN.ATTACKER.COM. Este pedido tiene el bit de recursión solicitada en 1 (RD), con lo cual si DNS.TARGET.COM soporta recursión enviara el pedido a otro nameserver (suponiendo que no tenga ya en el cache la respuesta).
2. DNS.TARGET.COM determinará primero quien sirve el dominio ATTACKER.COM, armará un paquete de pedido y lo enviará a DNS.ATTACKER.COM
3. El atacante, obtiene el paquete (utilizando técnicas de sniffing en la red local de TARGET.COM) enviado por DNS.TARGET.COM a DNS.ATTACKER.COM. Una vez hecho esto, podrá determinar el ID (qid0) usado por DNS.TARGET.COM. Es altamente probable que los próximos queries de DNS.TARGET.COM utilicen IDs en el rango (qid0,qid0+N] donde N sólo depende de la cantidad de queries generadas por DNS.TARGET.COM durante el período de tiempo en que se lleva a cabo el ataque.
4. Una vez determinado cual será el próximo ID, el atacante envía un query a DNS.TARGET.COM solicitando la dirección IP de WWW.SPOOFED.COM (bit RD en 1 aquí también).
5. A continuación, el atacante envía paquetes DNS de respuesta con la dirección IP de origen de DNS.SPOOFED.COM indicando que la dirección IP de WWW.SPOOFED.COM es 127.0.0.1
6. Si el atacante logró predecir el ID que DNS.TARGET.COM utilizó en su query a DNS.SPOOFED.COM y los paquetes enviados en E. fueron recibidos antes que la respuesta legítima de DNS.SPOOFED.COM, la respuesta del atacante será incorporada al cache de DNS.TARGET.COM. Respuestas subsiguientes, legitimas o nó, al mismo query, serán ignoradas por ser duplicados o no corresponder a un query en espera de respuesta. El atacante podría enviar muchas respuesta falsas (N*M) con distintos IDs en el rango (qid0,qid0+N] y entonces asegurarse que al menos uno de ellos sea el 'correcto' para el ataque. El factor M depende de la cantidad de paquetes UDP que se esperan perder en el camino a DNS.TARGET.COM

Problema I. - Resultado
Si el ataque tuvo éxito cualquier query a DNS.TARGET.COM, solicitando la dirección IP de WWW.SPOOFED.COM, obtendrá 127.0.0.1 como respuesta. En consecuencia, cualquier usuario en el dominio TARGET.COM se conectará a 127.0.0.1 si intenta contactar WWW.SPOOFED.COM.

El uso de 127.0.0.1 en esta descripción es a modo de ejemplo. Cualquier dirección IP puede ser usada, en particular la del atacante mismo (BADGUY.COM) de forma tal que todas las conexiones de máquinas en TARGET.COM a WWW.SPOOFED.COM vayan a BADGUY.COM. El atacante puede entonces simular en su máquina a WWW.SPOOFED.COM.

Es interesante considerar los efectos de un ataque de esta naturaleza destinado a simular un servidor de FTP con mucho trafico y punto de distribución de software de uso frecuente.

Problema I. - Notas
Para que el ataque sea exitoso se deben cumplir ciertas condiciones:
1. El atacante tiene completo control de la red local de DNS.ATTACKER.COM, puede tanto como enviar paquetes DNS apócrifos hasta 'sniffear' dichos paquetes en la red local. En particular aquellos enviados a DNS.ATTACKER.COM. Esto no necesariamente implica que el atacante tenga control sobre DNS.ATTACKER.COM.
2. Los paquetes apócrifos enviados por el atacante a DNS.TARGET.COM deben ser recibidos antes que las respuestas auténticas de DNS.SPOOFED.COM. Esto es sumamente sencillo de lograr y en las pruebas realizadas por SNI no se encontró ninguna situación en la que no fuera posible realizarlo.
3. El name server en DNS.TARGET.COM debe soportar recursión y mantener respuestas en su cache. Esto es una práctica común y la configuración por defecto. Es importante señalar que la mayoría de los name servers soportan recursión (a menos que se prohiba explícitamente en la configuración). Los root name servers no soportan recursión, por supuesto.
4. Si DNS.TARGET.COM incorpora a su cache las respuestas negativas (NCACHE), se abre la posibilidad de un ataque de denegación de servicio. En este caso el atacante envía paquetes apócrifos a DNS.TARGET.COM indicando que WWW.SPOOFED.COM no existe (y lo hace como si fuera la autoridad legítima del dominio SPOOFED.COM).
5. La existencia de varios nameservers para los dominios involucrados no altera de ningún modo el esquema básico del ataque. Si ése fuera el caso, el atacante simplemente enviaría paquetes de respuesta con dirección IP origen de cada uno de los 'I' nameservers de SPOOFED.COM. ( N*M*I paquetes, donde I es el número de nameservers de SPOOFED.COM)

Problema I. - Sistemas Vulnerables
· Todos los sistemas usando tanto BIND como DNS y configurados para permitir recursión.
· Windows NT (server) versión 3.51 & 4.0 DNS server. Microsoft ha sido notificado del bug y está de acuerdo en que se trata de un problema serio. No hay información sobre una forma de arreglarlo al momento de publicarse esta advertencia.

 

Problema II. Chequeo del largo de hostnames

Problema II. - Impacto
BIND permite que se pasen hostnames de largo mayor a MAXHOSTNAMELEN a programas. Como muchos programas utilizan buffers de MAXHOSTNAMELEN de tamaño y copia los resultados de un query a dichos buffers, puede ocurrir un buffer overflow.
Esto puede permitir a un atacante, en el peor de los casos, ejecutar cualquier comando en un servidor remoto.

Problema II. - Sistemas Vulnerables
Todos los sistemas corriendo BIND.
Información para solucionar los problemas
Patches para BIND-4.9.5-P1 que solucionan el problema están disponibles en ftp://ftp.secnet.com/pub/patches
El procedimiento para instalarlos se detalla en ftp://ftp.secnet.com/pub/patches/bind.random.README
Asimismo, una distribución de archivos fuentes de BIND-4.9.5-P1 con los patches instalados esta en:
ftp://ftp.secnet.com/pub/patches/BIND-4.9.5-P1.patched.tar.gz
O, si prefiere instalarlos manualmente, puede obtener la distribución oficial de BIND-4.9.5-P1 en ftp://ftp.isc.org/isc/bind/src

 

Agradecimientos

Ivan Arce
Emiliano Kargieman
The OpenBSD Project.
Quienes idearon, desarrollaron y llevaron a cabo varias pruebas para conseguir una buena solución y su consiguiente funcionamiento.
Algunas de las personas involucradas en este esfuerzo son:
Theo de Raadt
Niels Provos
Todd Miller
Allen Briggs
Niklas Hallqvist
Otros agradecimientos:
AUSCERT
David Sacerdote
Oliver Friedrichs
Alfred Huger

 

Información adicional:

1. Vixie P. , "DNS and BIND security issues". Publicado originalmente en los proceedings del 5to USENIX Security Symposium, este documento está también incluido en la distribución de BIND en el directorio doc/misc.
2. Kumar A., Postel J., Neuman C., Danzig P. , Miller S. "RFC1536: Common DNS implementation errors and suggested fixes". Referirse al problema 2 para una descripción de otras vulnerabilidades encontradas en el esquema de recursión.
3. Lottor, M., "RFC1033: Domain administrators operations guide"
4. Mockapetris, P., "RFC1034: Domain names - Concepts and facilities"
5. Mockapetris, P., "RFC1035: Domain Names - Implementation and specification"
6. Schuba L. Christopher, "Adressing weaknesses in the Domain Name System Protocol", Tésis para la Maestría en Ciencias de la Universidad de Purdue. 1993
7. Schuba Christopher y Eugene H. Spafford, "Countering Abuse of Name Based Authentication", COAST Laboratory, Department of Computer Science, Purdue University.

Comentarios y preguntas en relación a esta advertencia de seguridad pueden ser enviados a:
Ivan Arce
Emiliano Kargieman

Para mayor información acerca de CORE SDI S.A. Seguridad de la Información contáctenos o visítenos.

También es posible enviar mail encriptado a SNI utilizando la siguiente clave de PGP:

Type Bits/KeyID Date User ID
pub 1024/9E55000D 1997/01/13 Secure Networks Inc. <[email protected]>
Secure Networks <[email protected]>

 

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Versión: 2.6.3ia

mQCNAzLaFzIAAAEEAKsVzPR7Y6oFN5VPE/Rp6Sm82oE0y6Mkuof8QzERV6taihn5
uySb31UeNJ4l6Ud9alOPT/0YdeOO9on6eD1iU8qumFxzO3TLm8nTAdZehQSAQfoa
rWmpwj7KpXN/3n+VyBWvhpBdKxe08SQN4ZjvV5HXy4YIrE5bTbgIhFKeVQANAAUR
tCVTZWN1cmUgTmV0d29ya3MgSW5jLiA8c25pQHNlY25ldC5jb20+iQCVAwUQM1yd
EB/bLKAOe7p9AQFptAQAiYpaZCpSmGgr05E698Z3t5r5BPAKUEtgvF53AvZUQLxz
ZsYsVU5l5De0qKWJOQ/9LiDyWu1lvKhlTphbLy2RatWD4kO3oQL9v3TpSXm2WQhU
uIzyZvj7S5ENodNnKn+gCDIvbou6OMot+7dRbWWgN2oabbru4CSlOxbG++yaTz+J
AJUDBRAzTefbtOXez5VgyLkBAd0bA/43eGEgvPOFK+HHWCPpkSWCwtrtDU/dxOVz
9erHnT/CRxeojCI+50f71Qe+kvx9Q1odz2Jl/fLxhnPQdbPnpWblIbu4F8H+Syrj
HTilDrl1DWa/nUNgK8sb27SMviELczP1a8gwA1eo5SUCG5TWLLTAzjWOgTxod2Ha
OwseUHmqVIkAlQMFEDNOVsr/d6Iw8NVIbQEBxM0D/14XRfgSLwszgJcVbslMHm/B
fF6tHoWYojzQle3opOuMYHNN8GsMZRkc1qQ8QuNA9Aj5+qDqEontGjV5IvhBu1fY
FM77AhagskaFCZxwqV64Qrk328WDO89NGSd+RuovVNruDdn20TxNCEVuPTHjI0UA
8H+E6FW9jexg6RTHhPXYtCVTZWN1cmUgTmV0d29ya3MgPHNlY3VyaXR5QHNlY25l
dC5jb20+iQCVAwUQMtqTKB/bLKAOe7p9AQFw5wQAgUwqJ+ZqfEy/lO1srU3nzxLA
X0uHGHrMptRy/LFo8swD6G1TtWExUc3Yv/6g2/YK09b5WmplEJ+Q09maQIw+RU/s
cIY+EsPauqIq4JTGh/Nm0Z4UDl2Y1x4GNtm0YqezxUPS0P0A3LHVLJ3Uo5og0G8O
gPNrfbVz5ieT14OSCWCJAJUDBRAy2hd2/3eiMPDVSG0BAVNhBACfupfAcNhhnQaq
aI03DOOiZSRjvql1xw4V+pPhM+IksdSK3YNUZVJJtANacgDhBT+jAPRaYbBWI3A5
ZMdcSNM8aTG0LWMLIOiOYEm6Lgd3idRBFN0Js08eyITl8mhZ33mDe4I0KQri9UiV
ZcPYTbb9CWM6Hv2cMbt6S6kLnFziqIkAlQMFEDLaF0+4CIRSnlUADQEBCLoEAJwt
UofDgvyZ4nCDx1KKAPkkXBRaPMWBp46xeTVcxaYiloZfwHfpk1h2mEJAxmAsvizl
OtIppHl4isUxcGi/E2mLCLMvis22/IQP/9obPahPvgNaMLVtZljO1Nv3QFEkNciL
FEUTNJHR1ko7ibCxkBs4cOpirFuvTMDvWnNaXAf8
=DchE
- -----END PGP PUBLIC KEY BLOCK-----

 

Copyright:

El contenido de esta advertencia de seguridad es Copyright © 1997 de Secure Networks Inc y CORE SDI S.A. Seguridad de la Información, y puede ser distribuido libremente siempre y cuando se haga en forma gratuita y se otorgue el crédito apropiado a los autores originales.
Están disponibles otros Papers y advisories de Secure Networks o también puede visitar su página Web.
Para suscribirse al mailing list de advertencias de seguridad de SNI enviar un email con la línea subscribe sni-advisories en el cuerpo del mensaje.