Categoría: Técnico

DNS es un sistema para, entre otras cosas, averiguar qué número usar para «llamar» a alguien a través de Internet. Dado que hay muchísima gente, en muchísimos lugares, no puede haber sólo un directorio. A menudo, cuando le pides un número a un servidor, éste te remite a algún otro sitio. Y cuando acudes a allí, podrías ser enviado a un tercer destino. Este proceso –“recursividad»– se repite una y otra vez, hasta que finalmente obtienes el número del nombre que te interesa.

Por supuesto, en Internet, no estás «yendo» realmente a ninguna parte. Lo que sucede en realidad, es que estás enviando mensajes y recibiendo respuestas. ¿Qué impide entonces que un CHICO MALO te envíe sus propias respuestas, con sus propios números falsos como respuesta a lo que fuera que estabas buscando?

No mucho –pero tampoco nada–.

El sistema DNS puede ser concebido como una carrera: la solicitud es enviada. Un CHICO BUENO y un CHICO MALO quieren conseguir que se confíe en sus respectivas respuestas. El CHICO BUENO parte con una ventaja: él ve la solicitud, y dentro de ella aparece un número secreto, un número entre cero y sesenta y cinco mil. La carrera no está ganada hasta que alguien cruza la línea de meta con el número secreto, y aunque el CHICO MALO podría adivinarlo, sólo tiene 1 entre 65536 posibilidades de acertar. Peor aún, ¡el ganador de la carrera tiene la potestad de decidir cuánto tiempo pasará hasta la próxima carrera! Haciendo números es fácil ver que se necesitarían meses, incluso años para que el CHICO MALO finalmente ganara una carrera.

Sin embargo, existen tres problemas. Los dos primeros eran ya bastante conocidos. El tercero es muy nuevo.

En primer lugar, el CHICO MALO es quien da el pistoletazo de salida. Él decide cuándo sale la solicitud –es decir, no puede saber el número secreto, pero en realidad sabe que la carrera ha comenzado antes que el CHICO BUENO–.

En segundo lugar, el CHICO MALO no está solo. Puede tener en la carrera a tantos «corredores» como quiera –ésta sólo termina cuando alguien llega con el número secreto correcto–. El CHICO MALO puede probar suerte con un número equivocado tras otro y, hasta que el CHICO BUENO no aparezca con el correcto, puede seguir así indefinidamente. Si le da tiempo a probar con un centenar de números, las probabilidades pasan de una entre sesenta y cinco mil a una entre seiscientas cincuenta y cinco.

Pero esas son probabilidades bajas todavía, y si pierde, podría tener que esperar un día para volver a intentarlo.

O tal vez no.

Lo nuevo es que, de hecho, el CHICO MALO no tiene que esperar para empezar otra carrera. El DNS, de hecho, se parece más a una carrera de relevos que a un sprint. Recuerda, tú envías una petición a un servidor, y deberías obtener una respuesta como: «¿www.foobar.com? Claro, aquí está la dirección IP que debes usar». O bien podrías obtener un mensaje que dice: «¿www.foobar.com? No sé, pregúntale a ns1.foobar.com, aquí tienes su dirección». Esto es la recursividad. No es un error, o una característica poco utilizada. El DNS te envía siempre a diferentes servidores para encontrar un registro –así es como trabajan los servidores de las «.com»–.

Eso sí, existe un límite: no funcionará cualquier otro nombre como respuesta –de lo contrario, yo podría responderte «¿www.foobar.com? Oh, eso está alojado en www.google.com. Aquí tienes su dirección», y tendrías que creerme (hace once años, esto funcionaba)–. Sin embargo, los nombres cercanos a www.foobar.com —1.foobar.com, 2.foobar.com, 3.foobar.com— están, por decirlo de alguna manera, «en la misma jurisdicción»¹. La referencia a un nombre «de la misma jurisdicción» será siempre acatada.

Y así, el ataque. Si alguien intenta atacar a www.foobar.com, no da el pistoletazo de salida para ese nombre. Después de todo, el servidor puede estar dispuesto a no salir en busca de www.foobar.com durante horas. No, él inicia carreras para 1.foobar.com, 2.foobar.com, 3.foobar.com, y así sucesivamente.

El CHICO MALO probablemente perderá estas carreras. Las probabilidades, incluso con una ventaja de cien «corredores» contra uno en cada carrera, están contra él.

Pero él puede correr tantas carreras como quiera. Y en algún momento, ganará una de ellas. Y cuando gane –cuando el CHICO MALO adivine el número secreto entre 0 y 65536–, no se limitará a dar una respuesta para el nombre aleatorio que ganó. Simplemente fingirá ignorancia: «¿83.foobar.com? No sé, pregúntale a www.foobar.com, aquí tienes su dirección. Ah, y recuerda esto hasta la próxima semana».

Él ha ganado la carrera. Él es quien tiene la palabra.

Ahora bien, se han producido algunos ataques de DNS problemáticos en el pasado. Amit Klein fue capaz de adivinar el número secreto que el CHICO BUENO debía entregar. Joe Stewart fue capaz de hacer que muchos números secretos fueran aceptados. Pero ninguno de estos ataques podía anular una carrera que ya había sido ganada. Una vez que un servidor de nombres ha almacenado –“cacheado»– el número para un determinado nombre, sencillamente no correrá otra carrera por ese mismo nombre. ¿Para qué hacerlo? ¡Ya conoce su número!

El ataque de Joe necesitará otra carrera para www.foobar.com. El ataque de Amit necesitará otra carrera para www.foobar.com.

En mi ataque, nunca participamos en una carrera por www.foobar.com. Corremos por otros nombres. Esto da muchos problemas. Dirigir el ataque resulta muy trabajoso.

Autor: Dan Kaminsky
Fecha original: 24 de Julio de 2008
Enlace original
¹ En el original en inglés, «in-bailiwick» (N. del T.)

Empieza a ocurrir lo que nos temíamos: ya han publicado varios exploits para la vulnerabilidad DNS. Como dicen en Kriptópolis, «el genio está fuera de la botella», y muchos servidores siguen sin estar parcheados.

También tenemos nuevas herramientas para comprobar si un servidor es seguro o no, aparte de la herramienta del blog de Kaminsky, que ya citamos. Y, sobre todo, insito en utilizar OpenDNS cuanto antes (recuerda los pasos para configurar tu ordenador).

Para utilizar las nuevas herramientas de comprobación, podéis encontrar un listado de DNS de los diferentes ISP españoles en la siguiente dirección: http://bandaancha.eu/analizador-dns. Y basta con seguir los pasos que se detallan a continuación.

Nota: Los ejemplos están puestos para comprobar el DNS de Ya.com, cuya IP es 62.151.2.65. Para comprobar otro servidor, basta con cambiar esta IP por la correspondiente.

En Windows

Vamos a Inicio > Ejecutar, tecleamos cmd y pulsamos Enter. En la consola, introducimos el siguiente comando:

[code lang=»plain»]nslookup -type=txt -timeout=30 porttest.dns-oarc.net 62.151.2.65[/code]

La salida obtenida será parecida a la siguiente:

[code lang=»plain»]z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"62.151.2.8 is POOR: 26 queries in 4.4 seconds from 1 ports with std dev 0.00"[/code]

Hago notar el «POOR». Si nuestro servidor es seguro, la salida será parecida a la siguiente (para el caso de OpenDNS):

[code lang=»plain»]z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"208.69.34.10 is GOOD: 26 queries in 4.1 seconds from 26 ports with std dev 18417.55"[/code]

En Linux

Es necesario tener instalado previamente el paquete bind-utils de nuestra distro. Una vez instalado, abrimos una consola y tecleamos lo siguiente:

[code lang=»plain»]dig +short @62.151.2.65 porttest.dns-oarc.net txt[/code]
La salida será análoga a lo comentado en el apartado de Windows.

Parece ser que se ha filtrado información concreta acerca de la vulnerabilidad en los servidores DNS, sobre la que ya hablábamos en días anteriores. Para los rezagados, aquí tenéis la explicación completa:

• Cómo de crítico era el fallo en los servidores DNS (I).
• Cómo de crítico era el fallo en los servidores DNS (II).
• Cómo de crítico era el fallo en los servidores DNS (III).

Dan Kaminsky, el descubridor de la vulnerabilidad, informó hace unas semanas a las grandes empresas del sector para que publicaran parches para sus servidores. En un principio, dio un plazo suficientemente amplio (hasta principios de agosto, tengo entendido) tras el cual haría públicos los detalles técnicos del problema. Presumiblemente, ese tiempo sería suficiente para que todos los administradores del mundo actualizaran sus servidores.

Prácticamente a las horas de descubrirse el fallo, las grandes empresas tenían preparados sus parches. Parecía fácil: los administradores sólo tenían que darle a «actualizar» en sus servidores y problema resuelto. Sin embargo, a día de hoy muchísimos DNS siguen sin estar actualizados. Los de Telefónica, aquí en España, sin ir más lejos. Y lo que es peor: se ha filtrado información técnica antes de tiempo y, aunque el artículo en cuestión fue borrado, sigue siendo accesible en la caché de Google y en Slashdot. Esto es una mala noticia, puesto que significa que hay más peligro de que alguien implemente un exploit y nos haga una de vaqueros…

Y Telefónica sin actualizar sus servidores; desconozco qué pasará con otros ISP. Kaminsky ha desarrollado una herramienta para comprobar si el servidor DNS que usamos es seguro o no. Podéis pasaros por allí y clickar en Check My DNS. Llevo unos días negro, enrabietado al comprobar que seguimos siendo vulnerables por la dejadez de Telefónica. ¿Viven al margen del mundo, o qué? ¿No se enteran?

En fin. Por el momento, creo que lo más sensato será cambiar de DNS, al menos hasta que amaine la tempestad. Que seguramente no pasará nada, pero por si acaso yo ya lo he hecho, y os recomiendo que también los cambiéis. La alternativa más fiable, a mi juicio, es OpenDNS, un servidor DNS internacional rápido, seguro y que pasa el test de la página de Kaminsky sin problemas (el propio Kaminsky lo recomienda). Y no pongáis esa cara, tranquilos, porque configurarlo es algo fácil y rápido. La página que os acabo de enlazar es más que nada de información, por si queréis echarle una ojeada, pero no es necesario. Tan sólo tenéis que seguir unos sencillos pasos en vuestro propio ordenador y navegaréis de manera más segura. A continuación os detallo los pasos para Windows y para Linux. Si utilizáis otros sistemas y no sabéis cómo hacerlo, entrad en la página de OpenDNS y allí encontraréis instrucciones.

Cambiar de DNS en Windows

Vais a Inicio > Panel de Control > Conexiones de red. Click derecho sobre la conexión que estéis utilizando para conectaros a Internet (Conexión de área local o Conexiones de red inalámbricas típicamente) y pinchad en Propiedades. Aparece un nuevo diálogo y bajo Esta conexión utiliza los siguientes elementos aparece una lista; pues bien, seleccionáis en ella el elemento que reza Protocolo Internet (TCP/IP) y pincháis en Propiedades.

En el nuevo cuadro de diálogo que aparece, probablemente tendréis seleccionada la opción Usar las siguientes direcciones de servidor DNS, y si no es así, la seleccionáis. Por último, en los campos Servidor DNS preferido y Servidor DNS alternativo escribís 208.67.222.222 y 208.67.220.220 respectivamente. Aceptar y Aceptar, y listo.

Cambiar de DNS en Linux

Tenéis que abrir como root el fichero /etc/resolv.conf con vuestro editor de texto favorito. Por ejemplo, introduciendo lo siguiente en la consola:

[code lang=»bash»]gedit /etc/resolv.conf[/code]

A continuación, editáis dicho archivo de manera que contenga lo siguiente:

[code lang=»bash»]nameserver 208.67.222.222
nameserver 208.67.220.220[/code]

Y por último, reiniciáis la interfaz de red (también como root) con los siguientes comandos:

[code lang=»bash»]ifconfig nombre_interfaz down
ifconfig nombre_interfaz up
route add default gw 192.168.1.1[/code]

Comprobar que el cambio se ha producido

Pinchad en este enlace para comprobar si el cambio se ha producido satisfactoriamente y efectivamente estáis usando los servidores de OpenDNS. En ese caso, podéis navegar tranquilos.

En la entrada anterior ya vimos los efectos del agujero de seguridad, ahora nos quedan por ver las causas.

Envenenamiento de la caché

Las consultas DNS no requieren conexión porque utilizan el protocolo UDP. Esto significa que se envía un único paquete con la consulta y se espera la respuesta en otro paquete UDP. Entonces, ¿nos fiamos de cualquier paquete de respuesta que llega? Obviamente no. Cada paquete entrante tiene una serie de indicadores que sirven para comprobar su validez: la dirección IP de quien envía el paquete, el puerto utilizado para la comunicación, un identificador (ID) aleatorio de 16 bits y el propio contenido del paquete. El servidor DNS se realiza las siguientes preguntas al recibir un paquete de respuesta:

• ¿Le acabo de preguntar algo a la IP que me envía este paquete?
• ¿Es una respuesta a la pregunta que yo he realizado?
• ¿El ID coincide con el que yo he enviado?
• ¿El puerto de llegada es el mismo desde el que yo pregunté?

Si las respuestas a todas estas preguntas son afirmativas, el servidor DNS acepta la respuesta como válida y la almacena en la caché. La primera respuesta válida que llega se acepta.

¿Qué tendría que hacer un atacante para explotar el agujero de seguridad? Para empezar, ser más rápido contestando que el servidor al que preguntó el DNS atacado. Esto es fácil: bastaría con realizar un ataque DDoS para inutilizar ese servidor y enviar muchos paquetes iguales al DNS atacado para asegurar el éxito.

¿Qué más? Cambiar la IP del que manda el paquete por otra cualquiera es algo trivial. Los únicos impedimentos que quedan por salvar son el ID y el puerto de destino, y aquí están los fallos graves. Me explico. Resulta que el ID aleatorio es de 16 bits, lo que nos da 65.536 posibilidades (muy pocas, porque 65.536 paquetes distintos se envían muy rápido), y lo que es peor: un servidor DNS utiliza siempre el mismo puerto para las consultas. Por lo tanto, es relativamente sencillo para un atacante averiguar qué puerto utiliza un servidor DNS y predecir el ID que utilizará para las consultas. Es decir, debido a las peculiaridades en la implementación del protocolo DNS, es fácil para un atacante confundir a un servidor y envenenar su caché con datos falsos, lo cual nos deja a los usuarios indefensos.

Los grandes fabricantes solucionan el problema

Desconozco qué medidas se habrán tomado al respecto, pero hago notar que tan sólo con permitir que cada consulta se haga desde un puerto aleatorio, las posibilidades aumentan notablemente –65.536 puertos posibles a los que hay que restar 1.024 puertos restringidos, y 65.536 ID posibles por cada puerto; en total 4.227.858.432 posibilidades–, y por consiguiente la dificultad para el atacante es muchísimo mayor.

En cualquier caso, no hay por qué preocuparse. Los grandes fabricantes –como Debian, Cisco, Infoblox, ISC, Juniper, Microsoft, Red Hat, Sun (Solaris)…– se pusieron manos a la obra y sacaron los parches pertinentes para sus servidores con gran rapidez. A día de hoy, seguro que todos los administradores del mundo han actualizado sus equipos y ya no hay nada que temer.

Más información en esta nota técnica del US CERT que describe la vulnerabilidad o en esta otra nota del SANS Institute.

Vamos a continuar con la explicación del protocolo DNS. Nos quedó pendiente en la entrada anterior detallar cómo es una petición DNS, esto es, qué ocurre en la red para que nos den el «teléfono» para «llamar» a Google con nuestro navegador.

Funcionamiento del protocolo DNS

En el siguiente gráfico se detalla el proceso de una resolución de dominio completa, aunque no siempre se requieren todos los pasos, ya veremos por qué:

1. En primer lugar, desde nuestro PC se genera una petición DNS hacia el servidor de nuestro proveedor de conexión. Dicha petición va en un paquete UDP y en él se pide la IP para la dirección «www.google.com» (en nuestro ejemplo).
2. Como nuestro servidor DNS no tiene conexión directa con la página solicitada, en principio, no sabe su dirección, así que tendrá que averiguarla. Para ello, realiza la misma consulta a uno de los Root Servers de los que sí sabe la dirección, puesto que son fijos.
3. El Root Server tampoco conoce la dirección de «www.google.com», pero sí que conoce la dirección del DNS que alberga los dominios «.com», así que se la entrega a nuestro servidor DNS, con lo cual ya está un poquito más cerca de lo que busca.
4. Nuestro DNS de nuevo realiza la misma consulta, pero esta vez al DNS encargado de los dominios «.com». Éste último tampoco conoce la respuesta final, pero sí que conoce la dirección del DNS que alberga los dominios «google.com»…
5. … así que se la entrega.
6. Una vez más, nuestro DNS realiza la misma consulta al DNS ubicado en «google.com». Y, por fin, él sí conoce la respuesta, puesto que se encuentra en su misma red.
7. Se dice que es «autoritativo» para esa dirección. Le entrega la respuesta final a nuestro servidor DNS.
8. Tras estos pasos que, aunque largos, se realizan en un lapso de tiempo pequeño, nuestro servidor ya conoce la respuesta a nuestra pregunta y nos la entrega.
9. Ahora ya podemos comunicarnos directamente con «www.google.es» puesto que conocemos su dirección IP.

Fácil, ¿no? Y diréis, ¿siempre se realizan todos estos pasos? Evidentemente, no es necesario. Una vez que un servidor DNS ha realizado una consulta y conoce una IP más, la guarda en su memoria caché para agilizar futuras peticiones, ya que es esperable que las direcciones IP no estén variando todo el tiempo. Como sí pueden variar, estas entradas de la memoria caché se guardan un tiempo máximo y luego se borran, por lo que habrá que volver a averiguarlas con los pasos anteriores.

Buscando el agujero de seguridad

Ahora bien, cuando recibimos la respuesta de un servidor DNS, nuestro ordenador confía en esos datos ciegamente. ¿Qué ocurriría si un atacante consiguiera hacerle creer al servidor DNS que la dirección IP para «www.google.com» (u otra página) es otra diferente a la real? Pues bien, en ese caso el servidor DNS guardaría en su caché esa asociación falsa para futuras consultas, y cuando nosotros solicitáramos la dirección de Google, nos haría entrega de esa dirección falsa en la cual nuestro ordenador confiaría ciegamente (porque no tiene manera de comprobar su validez).

En consecuencia, un atacante lograría llevarnos a donde él quisiera de manera indetectable mediante este método, denominado cache poisoning o envenenamiento de la caché. Por poner un ejemplo ilustrativo, imaginemos que alguien realiza una réplica de la página web de nuestro banco y la instala en su ordenador. Mediante envenenamiento de la caché del servidor DNS, logra que éste asocie el dominio de nuestro banco con la IP de su ordenador. Al ingresar nosotros en la web de nuestro banco, en realidad estaremos cargando la página alojada en el ordenador del atacante, y al enviar nuestros datos de conexión se los estaremos dando en bandeja de plata. Y lo peor de todo: ¡es imposible enterarse!

En la próxima entrega, profundizaremos en las causas de este agujero de seguridad y qué han podido hacer para solucionarlo.