El blog de J0hn

Primero lo primero: Esto no es mío. Es solo una traduccción de este post en el blog de mi buen amigo Buanzo -a quien le robo noticias seguido, solo que las publico más tarde, en castellano, y con mayor porcenataje de errores ortográficos XD-.

Sacado de Barrapunto:

La idea básica del ataque, que puede considerarse a estas alturas de dominio público, es la combinación de DNS Forgery y DNS RRset poisoning. Se trata de conseguir, mediante la repetición de peticiones, que un servidor DNS acepte como respuesta legítima una respuesta ilegítima de nivel 3, y que ésta incluya información sobre la IP de otros dominios de nivel 3 del mismo dominio de nivel 2. En otras palabras, si se consigue que el servidor acepte como válido un paquete que le dice que xhstrn.google.com tiene como IP 1.2.3.4, aceptará como válida cualquier información adicional sobre google.com: www.google.com, mail.google.com, etc. Fascinante.

La explicación completa:

Falsificación efectiva de DNS en el 2008: Un descubrimiento de Kaminsky, en Matasano Chargen, escrito por ecopeland.

[0] El gato se escapó de la bolsa (nota de traducción: no me convence esta frase en castellano). Sí, Halvar Flake se dio cuenta de la falla que Dan Kaminsky va a anunciar en la Black Hat.

[1] Pretendan por un momento que solo conocen el funcionamiento básico del DNS -o sea que traduce WWW.VICTIMA.COM a 1.2.3.4. El código (o programa) que hace esto se llama “resolver”. Cada vez que el resolver le pide al DNS una dirección, crea un paquete llamado consulta. El intercambio de paquetes se llama transacción. Como el número de paquetes revoloteando la internet requiere notación científica para ser expresado, se pueden imaginar que tiene que existir alguna forma de que no se mezclen.

Juan (NdeT: el tipo original erar Bob, lo cambién para que sea más castellano :p) va a un deli a comprar un sandwich. Juan va hacia el expendedor de tickets rojo y redondo, y toma uno. El ticket tiene un número. Este será el único identificador para la transacción de Juan para adquirir su sandwich. Cabe aclarar que el número será usado probablemente dos veces -una vez cuando lo llamen para hacer su orden, y otra para entregarle su sandwich-. Para los curiosos, a Juan le gusta el jamón en pan de centeno sin cebolla (NdeT: esto me recuerda: yo quiero un sangucheeeeeee).

Si entendiron al idea, ya entienden el concepto de transacción de IDs, que son números asignados para mantener diferentes transacciones en orden. Convenientemente, los primeros dieciseis bits de un paquete de DNS contienen este único identificador. Se llama ID de consulta (QID por Query ID en inglés). Y con la eficiencia del deli, el QID es usado para múltiples transacciones.

[2] Hasta hace muy poco tiempo, solo existían dos clases básicas de vulnerabilidades en los DNS. Una de ellas implica meterse con el QID en los paquetes de DNS y el otro requiere que sepan Magia Negra (NdeT: El orginal decía Deep magic, que es magia profunda, pero me parece más lindo esto XD).

Los primeros QIDs.

Juan es un resolver, y Alicia es un servidor de DNS. Juan le pregunta a Alicia la dirección de WWW.VICTIMA.COM. La respuesta es 1.2.3.4. A Matías le gustaría que la respuesta fuera 6.6.6.0 (NdeT: Cambié los nombres Alice y Mallory, por Alicia y Matías, porque se me canta, no jodan).

Esto es (aunque ya no más) un secreto que me da vergüenza, que por un largo período de mi carrera, crear y enviar paquetes era, para mí, Magia Negra. Luego se convirtió en parte de mi trabajo, y aprendí que era sorprendentemente trivial (NdeT: Esto fue una apreciación del autor original, no mía). Entonces, pongamos a un lado la idea de que falsificar paquetes IP es la parte más árdua del “DNS poisoning”. Si soy Matías (NdeT: demás de ser pelado y largo como la P*** de Dios) y estoy atacando a Juan, ¿cómo puede hacer para diferenciar mis paquetes de los de Alicia? Porque no puedo ver el QID en sus consultas, y el QID en mis respuestas no van a coincidir. El QID es la única cosa que protege al DNS de Matías.

Los ataque de QID comenzaron en los viejos tiempo, cuando BIND simplemente incrementaba el QID en cada consulta que respondía. Si pueden recordar 1995, este es un ataque de DNS funcional. Piensen rápido: 9372 + 1. ¿Les llegó 9372, o se lo perdieron y tienen 9373? Ustedes ganan, Alicia pierde. Matías envía un flujo constante de respuestas de DNS a la consulta sobre WWW.VICTIMA.COM. Son todas descartadas -hasta que Matías logra que Juan consulte por WWW.VICTIMA.COM-. Si la respuesta de Matías llega a sus computadoras antes que la respuesta legítima llege desde el servidor DNS de sus ISP, serán redirecionados a donde Matías les diga que vallan.

Solución obvia: querrán que los QIDs sean generados aleatoriamente. Ahora Alicia y Matías están en una carrera. Alicia ve las consultas de Juan y conoce el QID. Matías tiene que adivinarlo. El primero en entregar un paquete con el QID correcto gana. Los QIDs aleatorios le dan a Alicia una ventaja enorme en esta carrera.

Pero hay un montón más de problemas acá:

• Si convencen a Juan de preguntara a Alicia la misma pregunta 1000 veces a la vez, y Juan usa un QID diferente en cada paquete, han conseguido que la carrera sea 1000 veces más fácil para que Matías gane.
• Si Juan usa un generador de números aleatorios pedorro, Matías puede hacer que Juan consulte por nombres que él controla, como WWW.MALO.COM, y observar como se comportan los QIDs; y eventualmente podrá predecir las salidas del generador de números aleatorios.
• 16 bits nos es lo suficientemente grande para dar seguridad efectiva para el tráfico que se maneja en 2008.

El resolver de sus computadoras es limitado. Lo que significa que en realidad no conserva las respuestas. Ustedes no quieren que lo haga. En realidad le pregunta a un servidor de DNS real, probablemente el de sus ISP. Ese servidor tampoco lo sabe todo. No puede, y no debería, porquela idea del DNS es aprovechar la naturaleza orgánica y cambiante del sistema de nombres de dominio y sus direcciones. Frecuentemente, ese servidor, tiene que ir y preguntarle a otro, y así sucesivamente. Algunos llaman a esto “recursión”.

Las respuestas llevan otro valor tambien, llamado tiempo de vida (TTL, por Time To Live en inglés). Este número le dice a los servidores de DNS cuánto tiempo mantener la respuesta en al cache. ¿Por qué? Porque manejan infinidad de consultas. Quiensea que gane la carrera entre Alicia y Matías, sus respuestas serán mantenidas en cache. Todas las respuestas posteriores serán descartadas. Todas las respuestas futuras para esos mismos datos, durante el TTL, vendrán de esa respuesta. Esto es bueno para el que gane la carrera. Si Alicia gana, esto significa que Matías no puede envenenar la cache durante ese tiempo. Si Matías gana, las próximas 10000 o más personas que consulten en esa cache: ¿dónde está WWW.VICTIMA.COM? irán a 6.6.6.0.

[3] Además tenemos otro conjunto de vulnerabilidades de DNS. Estos requieren de que presten atención en clase. No se han comentado desde más o menos 1997. Y son difíciles de
encontrar. Porque tienen que entender cómo funciona el DNS. Dicho de otra forma, tiene que estar completamente locos, locos de remate (NdeT: el orginal decía locos como Lazlo Hollyfeld, pero no sé quién es). Estoy hablando, por supuesto, del RRset poisoning.

El sistema de DNS tiene una arquitectura complicada. No solo eso, sino que no todos los servidores de DNS corren el mismo código. Ergo no todos implementan el DNS de la misma forma. Y no conforme con eso, no todos están configurados de manera correcta.

Solamente describí un ataque de QIDs que envenena la cache del servidor de nombres. Este ataque necesita velocidad, agilidad, y suerte. Porque si la repsuesta “real” llega antes que la falsa, se temrinó. Afortunadamente para ustedes que tienen una máquina del teimpo, algunas versiones de DNS les ofrecen otra forma de envenenar la cache del servior de nombres. Para explicárselos tengo que explicar más sobre la estructura del paquete de DNS.

Los paquetes de DNS son variables en longitúd, y consisten de una cabecera, algunos flags, y registros de recursos (RRs  de Resource Records en inglés). Los RRs son sobre lo que se montan las cosas. Hay hasta tres conjuntos de RRs en un paquete de DNS, junto con la consulta original. Estos son:

• Los RRs de respuesta, que contienen la respuesta a lo que sea que hayan preguntado (como el registro A que dice que WWW.VICTIM.COM es 1.2.3.4).
• Los RRs de autoridad, lo cuales le dicen al resolver a qué servidores de nombre dirigirse para obtener la respuesta completa a una consulta.
• RRs adicionales, algunas veces llamados “pegamento”, que contienen cualquier otra información adicional para hacer que la respuesta sea efectiva.

Una palabra sobre los RRs adicionales. Piensen en un registro NS que, como el que el servidor de nombres de COM, nos dice que para encontrar dónde está WWW.VICTIMA.COM, tenemos que preguntarle a NS1.VICTIMA.COM. Eso es bueno saberlo, pero no nos ayudará a menos que sepamos dónde encontrar a NS1.VICTIMA.COM. Los nombres no son direcciones. es un problema del huevo y la gallina. La respuesta es: se provee de ambos, el registro NS apuntando VICTIMA.COM a NS1.VICTIMA.COM, y el registro A apuntando NS1.VICTIMA.COM a 1.2.3.1.

Ahora juguemos como en 1995.

Descarguen el código fuente de alguna implementación de DNS y hackeenla tanto como para que cada vez que envía una respuesta, también envíe un poquito de maldad -un RR adicional extra con información maliciosa-. Luego configuren un servidor malicioso con eso, y regístrenlo como MALO.COM. Ahora consigan un montón de páginas web com tags IMG apuntando a nombres hosteados en ese servidor.

Juan inocentemente, carga una página con los tags maliciosos que obligan a su navegador resolver ese nombre. Juan le pregunta a Alicia para resolver esos nombres. Acá entra la recursividad: eventualmente la consulta llega a nuestro server malicioso. El cual devuelve una respuesta con un RR adicional inesperado (malicioso).

Si la cache de Alicia hace honor a los registros inesperados, entonces estamos en 1995 y acaban de envenenar su cache. Aun peor, reemplazará la información “real”, que ya estaba en la cache, con la información falsa. Ustedes consultaron dónde estaba WWW.MALO.COM (o mejor dicho,  los tags de imágenes lo hicieron). Pero Alicia también “encontró” dónde estaba WWW.VICTIMA.COM: 6.6.6.0.  Cada resolver que apunte a este nombre será ahora redireccionado al sitio de al bestia.

[4] No es 1995. Es 2008. Hay soluciones al ataque que acabo de describir.

Solución 1:

La sucesión de QID está arreglada con números aleatorios: usando un generador de números aleatorios robusto, y teniendo cuidado con el estado en que se mantienen la consltas. Los IDs de consulta de 16 bits aun son muy cortos, lo cual nos atemoriza. Hay hacks para resolver esto. Por ejemplo, DJBDNS hace que los puertos de orígen de las respuestas sean aleatorios, y por tanto hará caso omiso a las respuestas a menos que vengan del que adivine el puerto de orígen de ~16 bits. Esto nos deja cerca de 32 bits, que es mucho más difícil de adivinar.

Solución 2:

El ataque de envenenamiento del conjunto de RRs se arregla con una verificación de la jurisdicción. Lo cual es una manera peculiar de decir que el resolver simplemente recordará que si está preguntando dónde está WWW.VICTIMA.COM, no está interesado en guardar en cache una nueva dirección para WWW.GOOGLE.COM durante la misma transacción.

Recuerden cómo funcionan estas soluciones. Son muy importantes.

Y así volvemos al tiempo presente.

[5] Intenemos nuevamente convencer a Juan de que WWW.VICTIMA.COM es 6.6.6.0.

Esta vez, en lugar de hacer que Juan busque WWW.VICTIMA.COM y luego vencer a Alicia en la carrera, o hacer que Juan busque WWW.MALO.COM y luego meterle estricnina en su sandwich de jamón, seremos más listos (astutos).

Haremos que Juan busque AAAAA.VICTIMA.COM. Le correremos a Alicia (NdeT: españoles abstenerse XD). La respuesta de Alicia es NXDOMAIN, porque no existe el nombre AAAAA.VICTIM.COM. Matías tiene una respuesta. Volveremos a ello. Alicia tiene una ventaja en la carrera, y asi ella vence a Matías. NXDOMAIN para AAAAA.VICTIMA.COM.

La ventaja de Alicia no es insuperable. Matías repite con AAAAB.VICTIMA.COM. Luego con AAAAC.VICTIMA.COM. Y así sucesivamente. En algún momento, probablemente alrededor de CXOPQ.VICTIMA.COM, ¡Matías gana! ¡Juan cree que CXOPQ.VICTIMA.COM es 6.6.6.0!

Envenenar CXOPQ.VICTIMA.COM no es muy valioso para Matías. Pero él tiene otro truco bajo la manga. Porque sus respuestas no solo dijeron que CXOPQ.VICTIMA.COM era 6.6.6.0. También contenían RRs adicionales apuntando WWW.VICTIMA.COM a 6.6.6.0. Estos registros están “en jurisdicción”: Juan en realidad está interesado en VICTIMA.COM en esta consulta. Matías ha combinado el ataque #1 con el ataque #2, venciendo las soluciones #1 y #2. Matías puede conducir este ataque en 10 segundos, sobre una conección a Internet rápida.

Otras fuentes:

• Para los que se lo preguntaban, ya existe un exploit para aprovechar esto.
• Para verificar que su DNS está parcheado: pueden probar con el botón “Check my DNS” en este sitio, el blog de Kaminsky, o en este otro sitio, que es más detallado.
• Acá hay otra explicación con gráficos.
  
• Para comprobar la vulneravilidad desde Window$.
• Más exploits.
• El parche de Window$ da problemas…

Espero que les sea de utilidad.

¡Hasta la próxima!