Habló Kaminsky en Black Hat

Tal y como estaba previsto, Dan Kaminsky subió ayer al estrado de Black Hat y habló durante 80 minutos acerca de los detalles de la vulnerabilidad en DNS que ha puesto en jaque a toda Internet.

Prácticamente no hay nada nuevo en los detalles técnicos con respecto a lo que se había venido filtrando en los últimos días. Básicamente, las consultas DNS incluyen un identificador aleatorio de la transacción, pero sólo se dispone de poco más de 65.000 identificadores posibles. A base de "inundar" un servidor DNS con miles de peticiones para dominios con un nombre similar, el atacante puede acertar con el número que permite considerar válida una respuesta, y de ese modo redirigir el tráfico a su antojo.

Como dijo Kaminsky (Webinario), lo que existe ahora es una ventana de riesgo que puede ser aprovechada por los delincuentes antes de que el parcheo sea total. En ese sentido, Kaminsky estimó que el 42% de los usuarios de banda ancha ya están protegidos por los parches aplicados...

Como comentamos al tratar la famosa vulnerabilidad de DNS, una pequeña avanzadilla de S21sec estamos en Las Vegas para seguir de cerca qué se cuece tanto en BlackHat como en Defcon en esta edición de 2008. La verdad es que es imposible comparar la BlackHat de Europa con la de Las Vegas, no tiene nada que ver, tanto en el número de charlas, número de asistentes, o el ambiente que se respira.

Durante el día de hoy, la conferencia estrella ha sido, como se preveía, la de Dan Kamisky y su famosa vulnerabilidad de DNS: la sala estaba a rebosar y la gran mayoría de asistentes estabamos ahí para ver qué iba a contar, aunque ya le estropearon la sorpresa hace algunas semanas. En realidad ha dedicado poco tiempo a comentar la vulnerabilidad (tampoco se puede hablar mucho más) para luego enumerar muchas de las amenazas que puede haber al poder 'controlar' las respuestas de un servidor DNS, y quejarse de muchas de las realidades actuales, como el poco uso de SSL, la utilización de algoritmos débiles (MD5, ...), la poca predisposición de los usuarios, la mala implementación de algunas características en plugins como Java o Flash que ayudan a que se pueda cometer cualquier delito, lo fácil que es hacer que alguien solicite una petición de DNS para luego utilizar su ataque (desde el browser, SMTP, etc.).

La vulnerabilidad, rápidamente explicada, se basa en 4 puntos principales:

1. El uso de UDP por parte del protocolo DNS, con lo que es fácilmente spoofeable (aquí es donde tendríamos que hablar de egress filtering, que no muchos operadores lo implementan)
2. El uso del mismo puerto origen por parte del servidor DNS (a excepción de algunos como el djdbns), con lo que las probabilidades de acertar son mucho mayores. Recordemos que el objetivo que tenemos es acertar el QID (ID de la transacción). Este QID es de 16 bits con lo que tenemos 65535 probabilidades. Si realmente el puerto origen fuera aleatorio, las probabilidades de acierto serían muchas menos, puesto que pasamos de tener 1 puerto origen, a 65535 puertos origen probables, con lo que tendríamos que acertar no sólo el QID, sino también el puerto origen (hablaríamos de unos 32 bits (16+16) en vez de 16 bits).
3. El uso de 16 bits en el QID
4. El problema del huevo y la gallina. Cuando pedimos conocer que dirección IP tiene www.s21sec.com a nuestro servidor DNS, éste (si no lo tiene cacheado) pregunta primero al .com, que le dice que pregunte a ns1.s21sec.com, puesto que el servidor que maneja .com no tiene ni idea del dominio s21sec.com, sólo sabe que hay que preguntar a ns1.s21sec.com. ¿Pero cómo sabemos que dirección IP tiene ns1.s21sec.com? Aquí es donde entra a juego los RR adicionales, que básicamente nos dice que ns1.s21sec.com tiene la dirección IP 212.31.206.66.

Conjugando estos cuatro puntos, ya es cuestión de tener suerte (se tardan unos 10 segundos), y hacer que la víctima empiece a solicitar direcciones para ver si en alguna acertamos el QID. Es decir, hago que la victima empiece a pedir aaaaaaa.dominiomalicioso.com, aaaaaab.dominiomalicioso.com, así hasta que en alguna de ellas, por probabilidad, acertemos el QID (recordemos que son 65535 posibilidades). En la charla de Dan, ha comentado que sólo intenta las 200 primeras, y sino pasa al siguiente dominio malicioso. Cuando acertemos el QID, y podamos entonces spoofear la respuesta del servidor DNS, en vez de decir que cxdfeag.dominiomalicioso.com (suponiendo que es este el que hemos acertado) es la dirección x.y.z.w, le digo que no sé que dirección es, pero que puede preguntar a www.s21sec.com cuya dirección es 6.6.6.6, con lo que habremos podido envenenar la cache de ese servidor DNS, y todos sus clientes que pidan por www.s21sec.com, serán dirigidos a 6.6.6.6.

También ha comentado que cuando publicó que tenía una vulnerabilidad, en 51 horas un sueco le envió todos los detalles de la misma, así como muchas personas le han enviado nuevas ideas para explotar mejor esta vulnerabilidad (de hecho, ha dado las gracias y nombrado a varias personas).

Según ha comentado, mucha gente ha parcheado ya sus servidores DNS, pero todavía quedan muchos que no. Aunque como comentamos, hay que comprobar bien el parche puesto que algunas veces (en ciertas plataformas) crean problemas de eficiencia en los servidores DNS. Y realmente no tenemos que olvidar que también sufren el mismo problema los servidores internos de las empresas, puesto que hay que recordar que muchos de los ataques que reciben las empresas provenienen de empleados internos.

Todavía no está la presentación en la página de BlackHat, pero sí que se pueden descargar de la página de Dan. También es interesante algunos datos que nos dan los de Arbor sobre algunos ataques ya detectados. Lo que sí que parece es que si el dominio que se quiere spoofear está cacheado en el servidor DNS, hay que esperar a que desaparezca de la cache (TTL), no hay ninguna forma de forzar meter el dominio spoofeado.

En resumen, la charla ha estado bien, pero como casi siempre, ha faltado una pequeña demostración (ha comentado que tiene una herramienta que se llama DNSRake para realizar el ataque, pero será similar a lo que ya hay por Internet), puesto que los Powerpoints muchas veces se quedan un poco teóricos.

Fuentes:
http://www.kriptopolis.org/hablo-kaminsky
http://blog.s21sec.com/2008/08/blackhat-las-vegas-2008.html
http://www.itwire.com/index.php?option=com_content&task=view&id=19895&Itemid=53
http://www.pcworld.com/article/149514/2008/08/.html
http://voices.washingtonpost.com/securityfix/2008/08/kaminsky_details_dns_flaw_at_b.html
http://www.theregister.co.uk/2008/08/06/kaminsky_black_hat/
http://www.doxpara.com/DMK_BO2K8.ppt
http://asert.arbornetworks.com/2008/07/30-day-of-dns-attack-activity/

Suscríbete a nuestro Boletín