martes, 2 de diciembre de 2008

¿Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años? (y II)

En la entrega anterior hablamos de este boletín de Microsoft y la polémica que ha suscitado. También del protocolo NTLM y su diseño, culpables en última instancia de un ataque que permite acceder a los mismos recursos a los que tiene acceso la víctima. ¿Qué ha hecho Microsoft durante estos siete años para atajar el fallo? ¿Está totalmente corregido el problema con este parche?

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.

Esto no es todo

Hay que tener en cuenta que este fallo se va a corregir en dos fases. La primera es el MS08-068 limitando el "reflection attack" (contra la misma estación de trabajo y el mismo protocolo). A mediados de 2009 saldrá publicado un boletín adicional que corregirá más vulnerabilidades de NTLM, centrado en la interacción de múltiples protocolos. Pero aun así seguiremos siendo vulnerables al uso de NTLM. Sólo será necesario recurrir a escenarios más elaborados. Se trata de una debilidad inherente al protocolo.


Sergio de los Santos
ssantos@hispasec.com


Más información:

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

Andrés Tarascó
http://www.tarasco.org/security/smbrelay/paper_smbrelay_ES.pdf

No hay comentarios:

Publicar un comentario en la entrada