Sistemas que implementen:
* Caching DNS resolvers
* DNS stub resolvers

La vulnerabilidad detectada es inherente al protocolo DNS y está presente en todos los servidores y "resolvedores" de DNS existentes en Internet basados en BIND.

Riesgo:   Alto

La técnica de envenenamiento de caché DNS permite a un atacante modificar las respuestas que entrega un servidor DNS a sus clientes para redireccionarlos a otras direcciones IP, en vez de las originales. La gravedad de una vulnerabilidad de la resolución de nombres es crítica y permite lanzar ataques de phishing, inyección de código malicioso, posibles virus, malwares, troyanos, rootkits, etc.

El error ha sido descubierto por el experto en seguridad "on line" Dan Kaminsky, de IOActive. Kaminsky publicará los detalles de la vulnerabilidad el próximo 7 de Agosto en la BlackHat de las Las Vegas, aunque ya se ha adelantado que tiene que ver con problemas de aletoriedad del transaction id.

Cada consulta a un DNS se identifica únicamente con tres datos: puerto UDP de origen, IP y DNS ID. Al parecer, la vulnerabilidad está relacionada con la posibilidad de averiguar el identificador DNS para poder envenenar la caché de los servidores. El número de identificación DNS consiste en 16 bits de "espacio" en la cabecera de un paquete e identifica de forma única una petición. Las posibilidades son de unas 32.000. Con el tiempo, se han ido añadiendo mejoras para evitar la fuerza bruta y hacer más compleja la posibilidad de conocer este identificador, pero el método usado sigue siendo el problema y además el protocolo DNS no utiliza generalmente métodos de autenticación.

Es posible que la vulnerabilidad no sea un fallo totalmente nuevo, puesto que la debilidad de confiar en un número tan pequeño de posibilidades se conoce desde hace años, sino alguna forma novedosa de aprovecharlo que lo hace más sencillo y por tanto, peligroso.

Los parches publicados por los proveedores modifican el cálculo de este identificador para que resulte mucho más difícil predecirlo. ISC (creadores del Bind) reconocen que los parches que han publicado pueden afectar al rendimiento de los servidores DNS, por lo que es importante analizar bien sus consecuencias, y recomiendan usar DNSSEC.

Kaminsky proporciona en su página web una herramienta para comprobar si un servidor DNS es vulnerable.

Se recomienda a todos los administradores que parcheen sus sistemas cuanto antes.

Algunos proveedores ya han publicado sus respectivas actualizaciones:

* Cisco
http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml

* Debian
Security Advisories DSA-1603, DSA-1604 y DSA-1605

* dnsmasq
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q3/002148.html

* Infoblox
http://www.kb.cert.org/vuls/id/MIMG-7ECL8Q

* Internet Software Consortium (ISC)
http://www.kb.cert.org/vuls/id/MIMG-7E6K7P

* Juniper
https://www.juniper.net/alerts/viewalert.jsp?actionBtn=Search&txtAlertNumber=PSN-2008-06-040&viewMode=view

* Microsoft
Microsoft Security Bulletin MS08-037

* Nominum
http://www.kb.cert.org/vuls/id/MIMG-7F9PFM

* Nixu
http://www.kb.cert.org/vuls/id/MAPG-7G7NUC

* Red Hat
https://rhn.redhat.com/errata/RHSA-2008-0533.html

* Sun Microsystem
http://sunsolve.sun.com/search/document.do?assetkey=1-26-239392-1

* Wind River
https://portal.windriver.com/windsurf


Los administradores cuyos proveedores todavía no han publicado un parche, pueden limitar la exposición de la vulnerabilidad siguiendo una serie de recomendaciones alternativas:

Restringir el acceso
Limitar el número de fuentes que pueden solicitar recursión. Hay que tener en cuenta que restringir el acceso no evitará que atacantes con acceso autorizado a hosts exploten la vulnerabilidad. Securing an Internet Name Server contiene instrucciones para limitar la recursión en ISC BIND.

Filtrado de tráfico en el perímetro de la red
Debido a la capacidad de falsificar direcciones IP, es necesario dirigir estos ataques. Los administradores deben filtrar las direcciones falsificadas (spoofed) en el perímetro de la red. Los documentos IETF Request for Comments (RFC) RFC 2827, RFC 3704 y RFC 3013 describen las mejores prácticas para realizar esta defensa. Es importante comprender la configuración y requisitos de servicio de la red antes de decidir los cambios apropiados.

Ejecutar una caché local de DNS
En lugar de utilizar características de generación aleatoria de puertos fuente en un "resolvedor" stub, se puede proteger el sistema empleando "resolvedores" de servicio completo de caché local; tanto en los sistemas cliente como en los servidores cercanos a la red de los sistemas clientes, junto con segmentación de la red y las estrategias de filtrado mencionadas anteriormente.

Deshabilitar la recursión
Deshabilitar la recursión en cualquier servidor de nombres que responda a peticiones DNS realizadas por sistemas no confiables. Securing an Internet Name Server contiene instrucciones para deshabilitar la recursión en ISC BIND.

Implementar la generación aleatoria de identificadores de puerto fuente
Se recomienda a los proveedores que implementan software DNS software, revisar el IETF Internet Draft draft-ietf-dnsext-forgery-resilience para obtener información adicional sobre cómo mitigar el riesgo de sus productos. El documento se encuentra en proceso de elaboración y puede ser modificado antes de su publicación como RFC, en caso de que sea aprobado.

CVE-2008-1447

Technical Cyber Security Alert TA08-190B
http://www.us-cert.gov/cas/techalerts/TA08-190B.html

Multiple DNS implementations vulnerable to cache poisoning
http://www.kb.cert.org/vuls/id/800113

La vulnerabilidad de los Servidores DNS
http://blog.s21sec.com/2008/07/la-vulnerabilidad-de-los-servidores-dns.html

Servidores DNS basados en BIND en peligro de envenenamiento
http://www.seguridad-informatica.cl/home/servidores-basados-en-bind-en-peligro-de-envenenamiento

Fuente:  CSIRTCV www.csirtcv.es