El caso del DNS y la díscola señora

Este podría ser el título de la historia de Mortadelo y Filemón de este verano. Cómo ha habido muchas informaciones al respecto y todas muy distintas, he disfrutado siendo un espectador más.

Dan Kaminski, el ilustre descubridor de este fallo se encuentra trabajando en Spectra como vendor cuando se anuncia que va a contar en Blackhat USA 2008 los entresijos de un fallo en el sistema de caché de DNS que permite volver atrás en el tiempo y envenenar de nuevo las cachés de los DNS.

Hasta el momento se habían desarrollado, a lo largo de la historia, varios trucos para poner realizar una ataque de envenenamiento de caché DNS. Algunos muy curiosos. Los trucos utilizados han sido muy curiosos. Algunos de ellos muy divertidos:

Truco uno: Predicción Sencilla

Cada petición de resolución de nombre tiene un numerito de consulta. El ID de query. Este numerito inicialmente era incrementado como los números de la carnicería, así que, sí tenías un cliente que pedía a su servidor DNS la resolución de dos nombres seguidos y sabías el ID de la query 1, podrías inferir el número de la siguiente. Así, si tenemos un cliente que pregunta a su DNS por un nombre que está en un dominio de un atacante (por ejemplo cargando una imagen en una página web) el DNS del atacante, este puede devolver la IP asociada al nombre que le ha sido pedido, inferir el QID de la siguiente petición y responder con la IP asociada a la siguiente resolución sin ser él el DNS cuestionado y hacerlo antes de conteste el DNS legítimo. Este truco está muy bien, pero se parcheo aplicando algoritmos de generación de QID aleatorios. Fin de la fiesta.

Truco dos: Predicción compleja. La fecha del cumpleaños

Dice la estadística que cuando juntas un grupo de 23 o más personas la probabilidad de que dos de ellas hayan nacido en el mismo día es mayor del 50 %. Es curioso cómo funciona la estadística pues parece que 23 personas para cubrir 365 días no son muchas. La idea con el DNS es ¿Cuántas peticiones deben realizarse y cuantas respuestas deben enviarse para que la probabilidad de que una respuesta falsa del DNS atacante llegue con el QID correcto antes que la respuesta del DNS legítimo?

Sobre esta base se han ido realizando bastantes trabajos para conseguir optimizar el número de peticiones necesarias. Para ello se han ido analizando los números utilizados en los QID e intentar predecir los números que van a ser utilizados en las peticiones. En Junio del año pasado Amit Klein publicó un trabajo con la posible predicción de números en el BIND 9 y Alla Bezroutchko lo hizo con el DNS de Spectra. Lógicamente aparecieron parches y volvíamos al principio. A jugar con 16 bits de posibilidades y el ataque del Birthday en bruto.

Truco tres: Más respuestas que preguntas

Otro truco que surgió para hacer DNS caché poisoning consistía en aprovechar la facilidad que ofrece el estándar de peticiones DNS de responder hasta a tres resoluciones en una única respuesta por parte del DNS del atacante. Así, se hacía preguntar al DNS víctima por un dominio controlado, por ejemplo por www.elladodelmal.com y luego el DNS atacante devolvía una respuesta con la IP asociada a www.elladodelmal.com y…ya que estamos… www.tubanco.com está en esta IP. El DNS víctima cacheaba las dos respuestas y listo. Para solucionar esto, se prohibió que un DNS respondiera con información sobre dominios que no había sido preguntado. Así que… si se pregunta por www.elladodelmal.com sólo se pueden responder con registros .elladodelmal.com.

Y aquí estábamos hasta que Dan anuncia que se le ha ocurrido un truco. La idea era hacerlo coincidir con las BH USA y al mismo tiempo con el lanzamiento de una release del parche por parte de los fabricantes (incluido Spectra) para que todos se actualizaran a la vez y nadie pudiera hacer ingeniería inversa del parche y averiguar cómo explotarlo cuando…. Empiezan los rumores y una señorita, que a la postre resultó ser la mujer de uno de los implicados en el bug, contó alegremente en su blog detalles de cómo sería el ataque.

El truco combinado

La idea parece ser tan simple como unir los ataques 2 y 3 mediante un engaño en el cliente. Imaginad que un cliente pide por www.tubanco.com. Bien, este es un registro que existe con lo cual cuando llegue al DNS que intenta ser atacado este va a pedirlo al DNS legítimo. El DNS atacante tendrá la posibilidad de realizar un ataque pero sin mucho tiempo, pues el DNS legítimo responderá pronto.

Ahora bien, hagamos que el cliente pida unamierda.tubanco.com. Este registro no existe, luego el DNS legítimo no va a responder con una IP. Cuando llegue una respuesta de negativa, el atacante puede continuar con unamierda1.tubanco.com, unamierda2.tubanco.com, etc... teniendo así muuuuchas posibilidades. Perfecto, porque una vez que la petición de unamierdaX.tubanco.com sea legítima, pues aprovechamos y te metemos información sobre otros registros de ese dominio, por ejemplo de www.tubanco.com o bancaonline.tubanco.com. Y ya tenemos la fiesta.

Lo curioso es que, a pesar de que se borró del blog (que se quedó en la sempiterna caché de google) la información que la díscola esposa filtró en su blog sin conocimiento de los descubridores del fallo ha posibilitado que hasta el tato sepa como explotar esto y que ya hayan aparecido formas de explotar esto con mucha facilidad y está siendo explotado.

Las consecuencias: Phising, evilgrades, malware, etc... Ya veis, todo iba bien hasta que una blogger "boquitas" se metió por medio. En fin, el culebrón del verano.

Saludos Malignos!