domingo, 2 de noviembre de 2008

Vulnerabilidad Dan Kaminsky (II)

Después de la entrada Vulnerabilidad Dan Kaminsky (I) donde introducíamos una serie de conocimientos necesarios. Vamos ahora a explicar en qué consiste la vulnerabilidad descubierta durante este verano de 2008. Para poder entender en qué consiste el ataque de Dan Kaminsky deberemos primero entender los siguiente ataques al protocolo DNS:

El siguiente texto es una traducción y recopilación de información obtenida de diferentes fuentes, con la excepción de los gráficos que son obra de www.pentester.es para aclarar aún más si cabe los detalles de la vulnerabilidad.

DNS Forgery

Pueden leer la descripción de este ataque aquí.

Para que quede más claro lo mostraremos con unos gráficos resumidos:






Llegados a este punto por probabilidad el atacante puede adivinar uno de los QID’s generados para las consultas del DNS VICTIMA. Si adivina el QID’s podrá generar una respuesta con lo podrá suplantar la respuesta que debía llegar de OTRO DNS.

DNS RRset poisoning

Pueden leer una traducción y explicación buena aquí.

Ataque de Dan Kaminsky

El ataque está basado en una combinación de los dos anteriores ataques. Y se trata de lo siguiente:

Generamos gran cantidad de querys recursivas de nivel 3 solicitando dominos como aaaa.ejemplo.es, aaac.ejemplo.es, bbbb.ejemplo.es, etc. A la vez que le enviamos la query, enviamos la respuesta hasta que seamos más rápidos que el servidor legítimo y coincida con alguno de los QID’s generados por el servidor DNS a comprometer en sus querys al OTRO SERVIDOR.
Cuando esto pase anotará en la cache una entrada de tercer nivel del estilo ababab.ejemplo.es tiene la ip 1.2.3.4. Esta entrada para lo único que sirve es para envenenar la cache de DNS, y por si solo no vale para nada, ya que nadie va a visitar esta entrada. En ese instante tiene sentido utilizar el segundo ataque que consiste en colocar en los paquetes de respuesta en el campo adicional entradas como www.ejemplo.es, mail.ejemplo.es apuntando a direcciones no legítimas. Estos campos adicionales serán aceptados porque pertenecen al mismo dominio de la petición.

Ejemplo:

- El atacante realiza N peticiones de *.google.es al servidor DNS a comprometer.

- Al mismo tiempo envía respuestas al servidor a comprometer. Esas respuestas llevan en el campo de RR adicionales entradas como:

www.google.es 1.2.3.4
gmail.google.com etc. 1.2.3.4
Siendo estas direcciones NO legítimas.

- En el momento que el QID’s de la petición (servidor dns victima -> servidor dns legítimo) y de la respuesta (atacante -> servidor víctima) coincide se almacena en la cache; al tener los recursos adicionales cualquier petición a www.google.es, gmail.google.es, serás servida por 1.2.3.4 y no por las direcciones de legítimas de Google.

A continuación se muestra un diagrama que trata de comprender todo el ataque:




Espero sobretodo que este último gráfico ayude a entender bien el ataque y en qué consiste.






No hay comentarios :