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

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

wenassssssssss


ayer comentabamos esto de la actualizacion que cerraba la puerta al gusano confiker y a muchos nos parecia extraño lo siguente:

http://foros.softonic.com/showpost.p...62&postcount=2


y ahora veo que esta noticia y aunque sea otra actualizacion distinta flipo con los de microsoft la verda..........

fuente-hispasec.com

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.

¿Qué ha hecho Microsoft durante estos siete años para atajar estos
problemas? ¿Está totalmente corregido este fallo con esta actualización?
Lo veremos en la próxima entrega.

¿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.

Re: ¿Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años

Eseeeeeee Wanmmmmmmmmm

Llegaste unos días tarde, esta también la puse unos días atrás jejeje

El agujero de seguridad que Microsoft tardó siete años en cerrar

Saludazos y a olearrrrrrrr

Re: ¿Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años

Mientras no hagan un sistema desde cero, esto va a ser cada vez más habitual. No paran de decir que la próxima versión será radicalmente distinto. Para nada, son sistemas arrastrados de otras versiones antiguas. Lo novedoso es que cada vez las versiones consumen más y acumulan más vulnerabilidades y no me refiero del segundo martes de cada mes al siguiente.



Saludos.

Re: ¿Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años

joe ultimamente no ago mas que meter la gamba xd ,pero aora voy aportar la segunda parte (no e digas que ya la pusiste tb ,que salio aora mismo )


¿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.

Re: ¿Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años

totalmente de acuerdo ai bugs en distintos protocolos que pueden ir corrigiendo pero seguiran saliendo fallas en dichos protocolos y la solucion es dificil ya que como muy bien dicen en el articulo

dixo por -hispasec.com

es como la reciente Gusano Conficker ,de el que se hablo ayer por el foro , es acojonante que este gusano use un agujero de seguridad en el protocolo rpc ,cuando este protocolo ya fue aprovechado por el blaster y sus variantes hace unos cuantos años ..............


osea vale parchearon la vulnarilidad de el que se aprovechaba el blaster y sus variantes pero ese protocolo sigue teniendo sus fallos aora lo volvieron a corregir con el parche sacado recientemente para el Gusano Conficker ,pero seguro que ese protocolo tiene mas falla ,por eso estoy de acuerdo totalmente en lo que comentas noctuido , el problema ya es de raiz .............


pero weno .........,,,,,,

Re: ¿Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años

Como bien dice el artículo, en el fondo de todo hay un error de diseño; como en casi todo lo que hace microbug, así que como no empiecen de cero nada va a cambiar...

Luego nos dicen pesimistas o cosas peores cuando hablamos mal de windows o productos de microbug que aun no han salido, pero es que si siguen con la misma línea, haciendo las cosas mal de base, es imposible que las cosas les salgan bien, no hace falta esperar a la release final para comprobarlo...


Saludos

Re: ¿Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años

Jajajajaja ahora si te gano angel

Re: ¿Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años

Y lo peor de todo es que NO aprenden...

Les gusta tropezar con la misma piedra una y otra vez, una y otra vez, una y otra vez... Parece que disfrutan tropezando, la verdad...

Saludos...

Re: ¿Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años

Que tal ALTO como las duracel y duran y duran jajajajaja

Re: ¿Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años

jajajajjajajajajajaj me tiro al suelo esta esta buena