Kriptópolis

Si hasta ahora la explotación de la grave vulnerabilidad en los servidores DNS era más teórica que real, HD Moore, uno de los primeros en publicar exploits, detectó un servidor comprometido de AT&T en Austin (Texas, EE.UU.), que redirigía las peticiones realizadas a google.com hacia una página falsa que incluía marcos publicitarios.

Según Kaminsky (descubridor del fallo) hay otros ataques confirmados, pero ciertos acuerdos de confidencialidad impiden revelarlos...

No sólo ha sido Apple el gigante informático cuya reacción a esta grave vulnerabilidad ha sido más lenta, sino que además el parche finalmente publicado resulta insuficiente, ya que no funciona en las instalaciones de Mac OS X (Leopard y Tiger totalmente parcheados) como cliente, es decir, la inmensa mayoría.

El problema consiste en que el parche sigue sin aleatorizar el puerto de origen, una de las dos variables (junto al identificador de la consulta) que forman parte de la solución.

El tiempo apremia. No es ya sólo que varios exploits para el fallo de DNS estén corriendo por toda Internet, sino que además surgen nuevas ideas de explotación.

Es el caso de Evilgrade, una herramienta ideada por Francisco Amato, de Infobyte Security Research, que aprovecha el fallo DNS junto a otras vulnerabilidades conocidas para subvertir la actualización en línea de múltiples programas y aplicaciones muy populares, entre los que se encuentran Java, Winzip, Winamp, MacOSX, iTunes...

España no es diferente. Un estudio del CERT austríaco ha confirmado que dos de cada tres servidores DNS recursivos de los principales proveedores de acceso de ese país continúan a día de hoy siendo vulnerables al grave fallo hecho público por Kaminsky:

• Patching Nameservers: Austria reacts to VU#800113.

Como publicamos hace unos días, algo similar ocurre también en el resto del mundo.

Apple anda en otros asuntos y la vulnerabilidad en DNS no parece quitarle el sueño. Sólo así se explica que aún no haya publicado el correspondiente parche para MacOS X, puesto que éste utiliza los servicios de BIND, que fue parcheado el pasado 8 de julio, al hacerse pública la vulnerabilidad.

Y ello a pesar de que, según Kaminsky, Apple fue informado antes de que el parche se hiciera público, si bien el investigador no quiso precisar la fecha exacta. El retraso de Apple tampoco preocupa a Kaminsky, debido al bajo porcentaje servidores DNS que corren bajo Mac.

Sin embargo no todos los expertos opinan igual. "Si todos mis servidores corren bajo MacOS X, a mí sí me importa", dice Rich Mogull.

Pero hay algo en lo que casi todos los expertos están de acuerdo, y es en criticar el silencio absoluto de Apple al respecto...

Al menos eso dice hoy un artículo en The Register, que refleja una situación bastante similar a la de los proveedores de nuestro propio país. En concreto The Register califica como vulnerables (mediante el test de Kaminsky) a AT&T, BT, Time Warner y Bell Canada, así como a más de una decena de otros proveedores.

La burocracia interna podría ser una de las causas de la lentitud con que se está realizando la aplicación de parches en las grandes empresas. Según algunos expertos, la mera aprobación administrativa de la aplicación de un parche tan importante podría requerir un mes, y la actualización en organizaciones muy grandes requeriría probar sucesivamente diferentes configuraciones e irlas deshaciendo hasta dar con la más apropiada. Sin embargo, para la mayoría de empresas la actualización se limita a la aplicación de un parche en su servidor, a excepción de las que aún utilizan BIND 8, que han de actualizarse previamente a BIND 9...

Este test de DNS-OARC resulta más detallado que otros y muestra sus resultados de forma gráfica, aunque también requiere esperar los resultados algunos segundos más.

Informa por separado de la aleatoriedad de los dos factores implicados en la vulnerabilidad:

1. Aleatoriedad del puerto de origen.
2. Aleatoriedad del identificador de la transacción.

Los interesados en estos factores y en cómo intervienen en el fallo, disponen de una explicación técnica bastante sencilla (aunque en inglés) en la web de McAfee.

Mientras muchos nos preguntamos por qué algunos proveedores están tardando tanto en aplicar los parches contra la grave vulnerabilidad detectada en el sistema de servidores de nombres de dominio (DNS), también empezamos a comprender por qué algunos administradores muestran tan poca prisa en aplicarlos.

Por ejemplo, el parche elaborado por Microsoft (MS08-037) comenzó dando problemas a los usuarios de Zone Alarm, un popular cortafuegos personal. Pero ahora hemos sabido que los problemas tras la aplicación de ese parche no acaban ahí: servicios como Exchange Server, Active Sync, IPSec (Internet Protocol Security), IAS (Internet Authentication Services) están fallando al arrancar...

El genio está fuera de la botella. Los administradores que a pesar del aviso del pasado día 9 aún no hayan aplicado los corrrespondientes parches para sus servidores DNS, están ahora en serio riesgo de que sus dominios puedan ser redirigidos a cualquier sitio. El propio Kaminsky insiste en que se parchee o se utilice OpenDNS.

Y no se necesita mucho tiempo ni esfuerzo para provocar el desastre. H.D. Moore calcula que bastan 1-2 minutos para "envenenar" un caché y Kaminsky estima que sólo se necesitan unos segundos.

Mención especial merecen los usuarios de routers que ejecutan OpenWRT. Como avisamos en su día, su servicio DNS estándar (dnsmasq) también está tocado, y para colmo de males el parche que resuelve el problema (actualización 2.43) contiene un error que puede provocar la pérdida de algunos paquetes DHCP...

Hace unos días publiqué, en forma de comentario, cómo podíamos verificar si nuestros servidores DNS (o los de nuestro proveedor) seguían siendo vulnerables, utilizando para ello comandos de Linux y UNIX.

Hoy, la misma fuente nos ofrece un sistema similar para comprobar la vulnerabilidad, pero desde la línea de comandos de Windows...