Español | English
rss facebook linkedin Twitter

La Vulnerabilidad de los Servidores DNS

Durante el día de hoy está apareciendo en todo tipo de medios la noticia de la vulnerabilidad descubierta por Dan Kaminsky inherente al protocolo DNS y presente el todos los servidoresy resolvedores de DNS existentes en Internet (a excepción del genial djbdns de Daniel J. Bernstein de donde sale la idea de los puertos origen aleatorios). En principio, al usar djbdns esta características, es francamente difícil realizar ataques de cache poisoning puesto que hay que saber combinar no sólo el transaction id, sino también el puerto origen, aunque no es imposible (existen cerca de un billón de combinaciones).

La vulnerabilidad que aparece en los medios hoy, se trata también de una vulnerabilidad que podría utilizarse para realizar ataques de cache poisoning (DNS spoofing). Básicamente consiste en forzar las respuestas de un servidor o resolvedor DNS para que devuelva la dirección IP que se quiera en vez de la dirección IP real. Este tipo de ataques ya fue observado en 1993 en un artículo llamado 'Addressing Weaknesses in the Domain Name System Protocol' y posteriormente durante los años siguientes han aparecido varias vulnerabilidades parecidas generalmente relacionadas con problemas de generación de números aleatorios. Uno de estos más ataques más famoso ha sido debido a la Paradoja del Cumpleaños, pero realmente ha habido algunos más.

En este caso, todavía no se conocen los detalles de la vulnerabilidad, pero el CERT norteamericano es claro en un aspecto: la única solución válida para evitar la vulnerabilidad es usar DNSSEC, una extensión al protocolo DNS que lleva muchos años disponible pero no ha tenido mucho éxito su implementación. Aún así, han salido varios parches que mitigan en parte la vulnerabilidad, pero no la eliminan por completo, con lo que hay que tener cuidado a la hora de actualizar los servidores DNS y analizar las consecuencias. El descubridor de la vulnerabilidad 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. Esperemos que no sea (como a veces ha pasado) una vulnerabilidad anunciada a bombo y platillo de la que luego se demuestra que no es tan grave como parece.

ISC (creadores del Bind) reconocen que los parches que han sacado pueden afectar al rendimiento de los servidores DNS, por lo que es importante analizar bien las consecuencias como se ha comentado anteriormente, y lo que recomiendan es pasarse a DNSSEC (presentación rápida).

El propio descubridor ha puesto en su página una pequeña herramienta que comprueba si un servidor DNS es vulnerable o no.

En resumen, habrá que esperar a ver en qué consiste esta nueva vulnerabilidad (y esperar también la respuesta de todos los fabricantes de software con sus actualizaciones). Está claro que si existe esa vulnerabilidad y es relativamente fácil de explotar, las posibilidades son inmensas en Internet: phishing, infecciones, robos de credenciales, defacements, ... pero hasta que no se sepa verdaderamente el alcance, y puesto que se ha comentado que no se está utilizando esta vulnerabilidad in the wild, tenemos que ser cautelosos.

Más información sobre los fabricantes afectados en la página del US CERT. Es importante recalcar que no sólo afecta a los servidores DNS, sino a cualquier otro elemento que reenvíe, cachee o resuelva peticiones DNS (resolvedores en este post)

Actualización (10/07/2008 11:52): parece que la vulnerabilidad no es la típica de siempre y que realmente puede ser grave. Paul Vixie, una persona mítica en Internet (empezó a desarrollar Bind en 1988, entre otras cosas), parece que conoce los detalles de la vulnerabilidad y ha comentado que realmente no es la misma vulnerabilidad de siempre y que realmente es grave (de hecho en el año 95 publicó un paper donde hablaba de la ya consabida vulnerabilidad).  También existe ahora un script en perl que hace lo mismo que al conectarnos a la página de Dan Kamisky. Después de analizar los pocos datos que existen en Internet, está claro que es un vulnerabilidad relacionada a tres hechos: usar generalmente UDP (por lo fácil que es spoofear una dirección IP origen), utilizar 16 bits para el transaction id, y no utilizar puertos UDP origen aleatorios. Realmente estos tres hechos siempre han sido los causantes de las diferentes vulnerabilidades que se han comentado desde el 95, por lo que tendremos que seguir esperando hasta el 7 de Agosto. S21sec estará en Las Vegas para informar in situ de los detalles.

David Barroso
S21sec e-crime

(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login