Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años?


Mucho está dando que hablar el boletín MS08-68 de Microsoft. Se dice que por fin, ha corregido una vulnerabilidad conocida desde hace siete años. Pero esto, como cualquier simplificación, no es del todo cierto. No es una vulnerabilidad como tal, ni ha sido corregida por completo, porque no se puede. Vamos a intentar aclarar algunos asuntos en dos entregas.
El protocolo NTLM

Es un protocolo de autenticación basado en un intercambio desafío-respuesta, usado por Microsoft desde hace muchos años. Sirve para autenticar a un ordenador que quiere, por ejemplo, acceder a una unidad compartida de una red en otro sistema, sin que la contraseña viaje en texto claro. Durante el protocolo de autenticación, se intercambian tres (tipos de) mensajes desafío-respuesta.

* Mensaje 1: El cliente le cuenta al servidor los distintos tipos de características de cifrado y otros parámetros, para que los dos sepan qué es lo que pueden soportar y esperar uno del otro.

* Mensaje 2: Este es el que devuelve el servidor al cliente que se quiere autenticar. En él viaja el desafío, que no es más que un trozo de datos aleatorios con el que el servidor desafía al cliente: “Si sabes manipular este trozo de datos correctamente con tu contraseña, entonces sé que eres quien dices ser”.

* Mensaje 3: En él se encuentran las respuestas que ha calculado el cliente, esto es, el cálculo de la combinación contraseña-desafío con el que el cliente pretende autenticarse.

Hay que destacar que el protocolo NTLM se usa para SMB (compartición de archivos) principalmente, pero también puede usarse para autenticación HTTP, POP3, SMTP… es importante porque el uso combinado de dos protocolos sirve para otros tipos de ataque que veremos en la próxima entrega.

El problema

El protocolo NTLM fue bien acogido y muy implantado en sistemas de todo tipo. Pero en 2001 se publicó un ataque que se aprovechaba de este diseño, y que resultaba inherente al protocolo. No se trata de una vulnerabilidad sino de un fallo de diseño, y esto, virtualmente, lo hace insalvable. Un protocolo no puede cambiar de la noche a la mañana, y menos cuando lleva tantos años implantado.

El mecanismo de autenticación de NTLM garantiza la confidencialidad de la contraseña gracias al uso de un desafío, pero no es posible para el cliente verificar el origen de este desafío ni la integridad del paquete. Un servidor SMB creado por el atacante podría proporcionar al cliente un desafío obtenido en otra conexión, y utilizar el resultado de la autenticación para autenticarse en esa otra conexión. Ni siquiera tiene la necesidad de conocer la contraseña en texto claro. Simplificando, se trata de “engañar” a un cliente para que cifre un desafío y usar su respuesta para autenticarte en otro sistema como si fueras el cliente engañado. Para engañarlo sólo es necesario montar un servidor SMB por ejemplo y que la víctima se conecte. Se retiene la conexión y se realiza el ataque cuando se obtenga la respuesta.

Esta vulnerabilidad es conocida como “replay attack”. Sin saber la contraseña de la víctima, se puede deambular por una red accediendo a los recursos como si se fuese el sistema atacado, replicando la respuesta al desafío. En 2001, Sir Dystic (miembro de The Cult of the Dead Cow) publicó la primera herramienta capaz de realizar ataques de “replay attack” contra el protocolo NTLM, llamada SmbRelay. Era muy inestable y sólo válida para NT. Más adelante existió una herramienta más sofisticada llamada SmbRelay2. Basándose en el mismo fallo, se puede hablar del “reflection attack”, que implica usar el desafío de la víctima para devolvérselo firmado por ella misma y entrar en su sistema con las credenciales del usuario (pero sin saberlas). En vez de utilizarlas para acceder a otro recurso de red, se usan para entrar en el sistema que ha “picado” con el ataque.

Via Hispasec.com

Las soluciones

Microsoft ha luchado durante los últimos años contra este fallo del protocolo sin poder atajarlo por completo. En realidad es imposible si no es con un cambio de protocolo. Y Microsoft introdujo ya con Windows NT 4.0 SP4, el NTLMv2, que corregía el problema. Sin embargo nunca lo activaba por defecto, por lo de siempre: compatibilidad hacia atrás. Así que su uso es poco generalizado incluso hoy en día.

La implementación de Kerberos de Microsoft también mitigaba el problema en entornos de Directorio Activo. El problema es que no siempre puede usarse este protocolo, y cuando se da el caso, se utiliza NTLM en su versión 1 ó 2.

También se puso a disposición de los usuarios de Microsoft una directiva muy poco usada, la firma digital del protocolo SMB, que mitigaría el problema. Realmente, quien quisiese estar a salvo del “replay attack” tenía muchas posibilidades de conseguirlo. El problema es que quizás no siempre todo sería compatible con el resto de sistemas antiguos o diferentes a Microsoft. Sin embargo, en entornos completamente Microsoft a partir de XP y 2003, es perfectamente posible utilizar estas medidas y estar a salvo desde hace tiempo.

Por último, en Windows 2008 por fin se cumplen todas las buenas medidas de seguridad que Microsoft viene implementando desde hace años: mínimos privilegios y configuración muy segura por defecto. De hecho es el primer sistema operativo que no soporta en sus configuraciones por defecto el uso del protocolo NTLM.

Por qué no han sido suficientes

Existen muchos factores que han alimentado que este problema todavía sea usado con éxito por atacantes. La desaparición de NTLMv1 no está cerca, se encuentra muy arraigado. La compatibilidad con sistemas que no son de Microsoft es otro factor a tener en cuenta. Pero el más importante quizás sea el desconocimiento de los administradores, tanto del riesgo como de las políticas que pueden mitigarlo.

Por qué ahora el parche

Una de los últimos intentos de solución ha sido precisamente este parche que mitiga el problema. Según Microsoft ha acumulado la experiencia suficiente para poder introducir esta actualización sin romper literalmente toda la comunicación entre sus sistemas. De haber realizado cambios drásticos en el pasado, las consecuencias hubiesen sido desastrosas… así que ha tenido que lastrar un protocolo débil durante estos años.

La política de Microsoft siempre ha sido priorizar parches para las vulnerabilidades que están siendo activamente explotadas o para las que existen pruebas de concepto. Las herramientas Smbrelay1 y 2 ya no eran funcionales bajo Windows 2000, XP y 2003. Pero hace poco, Metasploit publicó un módulo de relay que hacía que el ataque fuese trivial. También se anunció la publicación de SmbRelay3 (pensada en principio para enero, pero lanzada ya al público), una excelente herramienta de Andrés Tarascó que hacía de nuevo que el ataque fuese muy sencillo y efectivo. Probablemente esto ha obligado a Microsoft a tomar medidas.

¿Es efectivo el nuevo parche?

Este parche MS08-068, evita que el protocolo SMB permita la autenticación a través de NTLM con un desafío de red que acaba de ser generado para otra conexión saliente. El parche se queda exclusivamente ahí, por lo que si complementamos diferentes protocolos como HTTP y SMB el ataque sigue siendo efectivo. Del mismo modo, si se reenvían las credenciales contra otro sistema de la red, por ejemplo un servidor de ficheros o un controlador de dominio, el ataque también es factible, puesto que el tercer sistema no puede tener conocimiento de que este paquete está siendo reutilizado. Al tratarse de un fallo de diseño de NTLM, los parches de Microsoft solo podrán limitar el impacto…[]

Via Hispasec.com

Microsoft Security Bulletin MS08-068 — Important
http://www.microsoft.com/technet/security/bulletin/ms08-068.mspx

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s