Si nos siguen regularmente, sabrán que solemos dejar un par de días, como poco, entre entrada y entrada. Lunes, miércoles y viernes suele ser la periodicidad que personalmente más me gusta. Pero hay ocasiones, como esta, en las que las circunstancias imponen un cambio de planes. Ni que decir tiene que para aquellos que no la leyeron ayer, les recomiendo que le echen primero un vistazo a la entrada anterior, sumamente interesante y un fiel reflejo de la seguridad de las organizaciones y los riegos de carácter práctico que implica la movilidad y la portabilidad, tanto a nivel de datos de carácter personal como de cualquier otro tipo.
Pasemos ahora a eso que ha alterado el orden natural de publicación y hará que este viernes no vaya a haber ninguna entrada. Ya tienen bastante con lo que tienen, hasta la semana que viene.
Empecemos con una pequeña introducción. Hace unas semanas, tal y como avisamos aquí mismo, Dan Kaminsky informaba de un peligroso problema de seguridad en el servicio de DNS; no creo que nadie necesite que le explique para qué sirve el DNS, ni de cuál es su criticidad en el marco de Internet. El problema era de una importancia tal que dió de plazo aproximadamente un mes para desvelar los detalles técnicos del problema, hasta el 6 de agosto, en la conferencia que daría en Black Hat, tiempo que los proveedores deberían aprovechar para parchear sus sistemas. Cosa que la mayoría de grandes proveedores no han hecho, todo sea dicho.
Hace un par de días, Halvar Flake se puso a especular sobre el problema. Y parece que se acercó bastante. Ese mismo día, la gente de Matasano publicó en su blog una interesante entrada en su blog, dando muchos detalles sobre la vulnerabilidad, y violando —al parecer— el acuerdo que habían alcanzado con Dan Kaminsky. Aunque eliminaron la entrada y pidieron disculpas, Internet no olvida, y su entrada se encuentra tanto en Google, como en otros blogs, en Slashdot, PC World ya ha hablado de ello y vayan ustedes a saber dónde o quién más. En otras palabras, el problema es casi oficialmente de carácter público y es probable (aunque no seguro) que Dan Kaminsky aclare finalmente los detalles.
La explicación que les voy a dar no pretende ser técnicamente profunda, pero espero que les sea suficiente; por supuesto, si detectan algún error, hagánmelo saber. Seguiré básicamente, pero no al pie de la letra, los pasos que Matasano describía en su entrada. Como conceptos básicos, deben conocer qué es un servidor DNS, y la estructura recursiva que el protocolo tiene. Si el servidor A no conoce la dirección IP para www.victim.com, preguntará a uno de mayor nivel, y así sucesivamente. Veamos ahora dos tipos de ataques clásicos sobre el DNS.
a) DNS Forgery. Este ataque se basa en hacer creer al servidor DNS que www.victim.com no tiene la IP 1.2.3.4, que es la legítima, sino que es 4.3.2.1, que en realidad apunta a www.evil.com. De este modo, cuando alguien le pregunte al servidor DNS por la IP de www.victim.com, éste devolverá la IP de www.evil.com. Imaginen ahora que www.victim.com es la web de un banco y www.evil.com reproduce fielmente su interfaz. Seguro que ven el problema.
La idea es la siguiente. Cuando Pepe pide la dirección de www.victim.com, si su servidor DNS Pepe_DNS no tiene su dirección IP, preguntará a Alguien_DNS por dicha IP, y así recursivamente. Esa solicitud lleva asociado un query id (QID), que sirve para autenticar la respuesta. La intención del ataque es devolverle a Pepe_DNS la IP de www.evil.com como si fuese la de www.victim.com, antes de que el servidor DNS legítimo lo haga, con la gracia de que además, Pepe_DNS guardará esa dirección IP en caché durante un tiempo, por lo que muchas de las siguientes consultas devolverán la IP de www.evil.com.
Claro que para hacer eso, necesito saber el QID de la petición, o la respuesta será descartada. Antes, cuando los QIDs eran consecutivos, algo así podía resultar sencillo. Ahora los QIDs se generan aleatoriamente (¡vaya!). Imaginen ahora que puedo hacer que Pepe_DNS pida no una, sino 1000 veces la IP de www.victim.com; hay 1000 veces más QIDs, y sólo tengo que adivinar uno de ellos. Imaginemos además que empiezo a preguntarle a Pepe_DNS como resolver direcciones que controlo; podré acceder a los QIDs y eventualmente, con suerte y algo de tiempo, quizá consiga predecir la semilla de generación de los QIDs.
La solución básica para eso es lo que hace DJBDNS, que es combinar el QID con el puerto de petición del cliente DNS, con lo que aumentamos la seguridad de 16 bits a 32 bits, haciendo la cuestión de adivinar sensiblemente más complicada.
b) DNS RRset poisoning. Este ataque está basado en la estructura de los paquetes de respuesta del DNS. La idea es que en la respuesta que recibo del servidor, además de la información solicitada, existe una parte del paquete que puede contener información adicional “de interés”. Por ejemplo, si yo pregunto por www.evil.com, Pepe_DNS puede contestarme con la IP de www.evil.com y en el campo de “información de interés” darme la IP de www.victim.com, que por supuesto no es la IP legítima.
Claro que alguien se preguntará porqué podría alguien pedir la IP de www.evil.com. Imaginen que acceden a un blog, que tiene una imagen alojada en www.evil.com. Con sólo eso, ya estamos intentando resolver www.evil.com, y el resto ya lo saben. La solución a esto es muy sencilla, al menos en el nivel teórico: no hagas caso del campo “informacion de interés”, excepto si contiene información sobre el dominio sobre el que he preguntado; es decir, que si pregunto por www.evil.com, puede interesarme mail.evil.com, pero no mail.victim.com.
c) Pasemos finalmente al ataque de Dan Kaminsky, que está basado en una combinación de los dos anteriores ataques. Imaginemos que preguntamos por aaaaa.victim.com. Seguramente el servidor legítimo, que es más rápido, le conteste diciéndo que no existe tal dominio (NXDOMAIN). Sigamos intentándolo con aaaab.victim.com, con aaaac.victim.com, de manera recursiva, hasta que llegado un determinado punto, seremos más rápidos y conseguiremos que Pepe_DNS crea que xgsdty.victim.com tiene la dirección 4.3.2.1.
Claro que xgsdty.victim.com es una dirección inexistente, y aunque en la práctica tenemos un DNS “poisoned” (envenenado), no parece servir de mucho ya que nadie va a preguntar por la IP de xgsdty.victim.com. Pero ahora, mediante la técnia del segundo ataque descrito, podemos decirle a Pepe_DNS cuál es la IP de www.victim.com, incluyendo su dirección en la “información de interés”, que sí que nos aceptará por pertenecer al dominio victim.com.
Dicho de otra forma, se trata de conseguir que Pepe_DNS acepte como respuesta legítima una respuesta ilegítima de nivel 3 (xgsdty.victim.com), que aunque no sirva de nada, incluya información sobre la IP de otros dominios de nivel 3 (www.victim.com) del mismo dominio de nivel 2 (victim.com). Tomando un ejemplo más real, si consiguimos que el servidor acepte como válido un paquete que le dice que tazxvb.google.com tiene como IP 1.2.3.4, éste aceptará como válida cualquier información adicional sobre google.com: www.google.com, mail.google.com, etc.
Les dejo a ustedes sacar las conclusiones sobre qué pasaría si el DNS que habitualmente utilizan piensa que www.google.com tiene la IP de www.evil.com. Bien. Pues les adelanto que la mayoría de DNS son (aún) tristemente vulnerables (pueden comprobarlo en el blog de Dan Kaminsky). Ah. Y no saben lo peor, o lo más divertido, depende de su gusto por la ironía; que su DNS no sea vulnerable no significa que estén a salvo, gracias a la estructura jerárquica del servicio de DNS de Internet.
¿No les parece fascinante, y a la vez, un problema “de cagarse”? Nada más. Buen fin de semana a todos.
Para acabar de “meter miedo” (que nunca viene mal), ya existe un exploit para esta vulnerabilidad que está incluido ni más ni menos que en la Metasploit Framework que para el que no lo conozca es un entorno muy conocido para la realización de tests de intrusión que incorpora bastante exploits y que convierte la explotación de una vulnerabilidad en casi casi un “Siguiente Siguiente Aceptar Aceptar Siguiente Aceptar”. ¿Que quiere decir esto?, pues que a partir de este momento cualquier “chaval” que sepa descargarse la metasploit y que tenga unos conocimientos no demasiado avanzados de seguridad es capaz de envenenar las cachés de nuestros servidores DNS.
En cualquier caso (y esto sirve aunque no existiera esta vulnerabilidad) intentemos usar HTTPS y en general protocolos seguros mediante los cuales podamos verificar la identidad del sitio remoto revisando el certificado (ojo, protocolos como el HTTPS no sirven para nada si aceptamos cualquier certificado que nos llegue, quizá escribamos un post pronto sobre esto :P).
Lo dicho, asustaros, asustaros y asustaros, y luego dejad el susto a un lado y a parchear.
No está de más tampoco usar la herramienta metasploit para verificar que efectivamente no somos vulnerables, que es para lo que realmente está hecha :P .
Saludos.
Enhorabuena por la explicación de la vulnerabilidad ;)
Los certificados no son la solución, el 95% de los exploradores son Internet Explorer e incluso Mozilla, tienen una lista muy grande de ‘entidades certificadoras de confianza’ como para conocer la seriedad de cada una en la emisión de certificados, así que dependiendo de la configuración del explorador muchos certificados son aceptados sin más por el navegador.
Yo el mayor problema que veo es, en este caso, la propia jerarquía de DNS que hace que aunque parcheemos, si tenemos que redirigir peticiones ya estamos vendidos porque no podemos responder por el resto de cachés y servidores DNS del mundo mundial. Lo que nos llega como una respuesta válidad, ya puede haber sido manipulada antes.
Bueno, jholguin, hay que decir en justicia que la entrada es en gran parte una traducción resumida de la explicación de Matasano, y creo que ha sido lo acertado porque los ejemplos son muy buenos (la analogía del sandwich, impagable :-) y su traducción bastante comprensible, como ha demostrado Manolo.