Vulnerabilidades en BIND y Soluciones

Advertencia de Seguridad

Secure Networks Inc.
CORE SDI S.A. Seguridad de la Información

22 de Abril de 1997

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.

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.

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 sirve. 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 esta descripto en el paper "Adressing weaknesses in the Domain Name System Protocol" de Christopher Schuba y Eugene Spafford [6]. En la medida de nuestro conocimiento, este problema no ha sido plantedo con anterioridad. El paper asume que el atacante tiene privilegios de superusuario en algún nameserver primario, en esta advertencia demostramos que ese 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:

• 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 previo al inicio del ataque. Nuevamente, y a fin de simplificar la descripción, asumimos que es el único name server de SPOOFED.COM

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 enviara 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 solo 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 no) 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 así 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

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.

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 enviar paquetes DNS apócrifos como 'sniffear' dichos paquetes en la red local. En particular aquellos enviados a DNS.ATTACKER.COM. Esto no necesariamente implica que el atacante tiene 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 autenticas 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 ese 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)

• Todos los sistemas usando BIND como DNS y configurados para permitir recursión.
• Windows NT (server) versión 3.51 & 4.0 DNS server. Microsoft a sido notificado del bug y concordado en que se trate de un problema serio. No hay información sobre una forma de arreglarlo al momento de publicarse esta advertencia.

Esto puede permitir a un atacante, en el peor de los casos, ejecutar cualquier comando en un servidor remoto.

Todos los sistemas corriendo BIND.

Asimismo, una distribución de archivos fuentes de BIND-4.9.5-P1 con los patches instalados esta en:

The OpenBSD Project

Quienes idearon una buena solución para el problema, la desarrollaron y llevaron a cabo varias pruebas para asegurar el buen funcionamiento de dicha solución. Algunas de las personas involucradas en este esfuerzo son:

Otros agradecimientos:

1. Vixie P. , "DNS and BIND security issues". Publicado originalmente en los proceedings del 5to USENIX Security Symposium, este documento esta 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", Tesis 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: