lunes, julio 28, 2008

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!

14 comentarios:

romansoft dijo...

¿Seguro que no responde el dns si le pides una entrada incorrecta? Yo creo que sí respondería como un "non existant domain"...

-r

Anonimillo dijo...

@Maligno: Ya era hora de que hablásemos del envenenamiento DNS!!!! empezaba a creer que te habían recomendado discreción, porque mira que has tardado en sacar el tema :)

Me parece una guarradilla lo que le han hecho a Kaminsky (por no decir una putada muy gorda) pero era cuestión de tiempo... el error hubiese sido igual de importante si no lo hubiese presentado en la blackhat, pero claro, como nos gusta más ser la reina de la fiesta que a Paris Hilton... Y no digo que no mereciese ser la reina de la fiesta, pero era un riesgo que asumió, y le salió mal.

coder dijo...

@romansonft: sí que responde, NXDOMAIN de toda la vida xD de hecho es parte del truco, o eso entiendo yo: te pones a hacer queries DNS de dominios inexistentes a saco, averiguas el algoritmo para genera los QIDs, y cuando lo sacas, bombardeas con respuestas con el flag RR activado y voilà, a poisonear.

Lo que ha hecho Matasano a mi me parece deleznable.

Mikelats dijo...

Bueno, en el pecado está la penitencia.

En las Pwnie Awards que se repartirán el 6 de agosto en Las Vegas, tenemos nominado como "Pwnie for Most Overhyped Bug" (al bug más sobrevalorado) el del DNS de Kaminsky. Se valora más si es imposible de utilizar en la práctica.

En el "Pwnie for Mass 0wnage" (al más utilizable y explosivo) aparece entre otros tu colega Luciano Bello.

De todas formas Kaminsky es la leche porque también está en esta última nominación y en la "Best Client-Side Bug".

Anónimo dijo...

¿Coño no era que los informáticos no ligaban? ¿Y este tío tiene novia?

Esto no te pasará a ti chemaCuidadorDeDelfines.

Anónimo dijo...

Chema, no tira el reto VIII desde hace unos días, ¿está cerrado?

saludos

dreyer dijo...

Roman tiene razon, normalmente se devuelve un NXDOMAIN que cachea la respuesta negativa. Si no no haria falta toda esta parafernalia puesto que tendrias infinitos intentos sin espera para hacertar el QID (una vez la entrada expire).

Lo importante no es que sea mas tiempo o menos. El tema aqui es ir preguntando tumierda1.lala.com, e intentar acertar por pura chorra el QID (con el additional record para que si funciona se lo trague). Que no aciertas, pues lo haces con tumierda2.lala.com. Al final acertaras y se tragara de paso la informacion extra (siempre que cumpla el bailiwick check). Como tumierda1.lala.com y tumierdaX.lala.com no estaban en cache se ira a preguntarlos, por lo tanto tienes infinitos intentos.

Por cierto, aqui no hay birthday attack porque solo hay una pregunta en el aire que puedes intentar acertar.

Maligno dijo...

@dreyer, funciona como tú dices, pero por cada petición de tumierda1.elladodelmal.com realiza muchas peticiones de respuesta posible del DNS intentando averiguar el QID, algo similar al Birthday date.

SAludos!

tayoken dijo...

Por lo que explica Kaminsky en su web la posibilidad de acierto es de 1 entre 65536 cada intento (pudiendo hacer muchos intentos por segundo).

Y tras el parche es de 1 entre dos mil millones (algo así será: 2147483648), vamos, que ha cambiado el QID de int a word.

Lo que me "preocupa" es que en lo único que confía es en el "ruido" que hará un ataque de este tipo, ya que no sé yo hasta qué punto estarán todos igual de concienciados que él... de hecho, hoy por hoy un ataque así ya debería hacer mucho "ruido".

dreyer dijo...

@maligno

Se que envias muchas, hice un PoC cuando se publicaron los detalles, pero esto es _1_ a muchas. El birthday attack es un ataque N-M.

No hay birthday attack porque las posibilidades no son cruzadas. Tienes una respuesta en el aire, y respondes con unas cuantas posibilidades.

Birthday attack existia cuando podias tener varias preguntas en el aire para el mismo dominio con diferentes QIDS.

Cosa que en el pasado se ha dado en algunos casos. Ie:

http://archive.cert.uni-stuttgart.de/bugtraq/2003/04/msg00311.html

http://securityvulns.com/news2773.html

Maligno dijo...

@dreyer, llevas toda la razón.

@tayoken, ya hay unos activex "muy graciosos" circulando por ahí.

Maligno dijo...

@anonimo, retos up!! hemos cambiado la ubicación de las máquinas virtuales. Todas están listas. ;)

otro anonimo agradecido por los retos dijo...

Maligno eres un cielo. Pena que yo sea un hombre hetereosexual sino te daría un beso.

CentOS de prepago xDD dijo...

gracias por el post, aunque tarde es de lo mejor que hay por ahí en la lengua de Cervantes... ves qe fácil sin flames?? xDDDDD

Preveo tormenta pa mañana, dos días seguidos sin tirar piedras ya sería mucho jajajaaj

Saludos!

Wi®

PD: Kaminsky y la novia de nosequien me deben cuatro horas extra esta semana de mi curro , grrr cabroneees xDDDDD

Eleven Paths Blog

Seguridad Apple

Entradas populares