Aclaraciones sobre el fallo de 1997 que "vuelve" a Windows, SMB redirect (y cómo protegerse)

martes, 14 de abril de 2015

En 1997, Aaron Splanger descubrió un fallo "mítico" en Windows. Se podía forzar a Windows (y a su navegador, más bien) a que enviara las credenciales a una unidad compartida de un servicio del atacante a través de SMB. Simplemente bastaba con poner un enlace a algo como "\\recurso" en una web... y las credenciales serían "enviadas" mientras se navegaba. El fallo nunca se "corrigió" realmente, solo se mitigó, pero ahora se le ha dado una vuelta de tuerca que lo hace más sencillo de explotar... Veamos si es cierto y cómo protegerse.

Ya en 1997 se sabía que, si alguien en una web apuntaba a un recurso tipo "img src="\\1.2.3.4\share\1.jpg", un atacante en 1.2.3.4 podía tomar las credenciales de la persona que visitaba la web. Es cierto que las credenciales estarían cifradas, pero en aquel entonces se hacía con LANMAN, o lo que es lo mismo, una pantomima de protocolo de cifrado que no servía para nada.

Windows envía las credenciales por defecto para que sea muy cómodo navegar por un dominio logueado con un solo usuario, y se accedan a recursos compartidos de manera transparente. Si no son válidas, se piden nuevas, si lo son, el usuario accede en el dominio a lo que tiene derecho. Es un comportamiento ideal que parece que nunca va a cambiar en Windows, y por tanto, no se "arregló" del todo. Lo que se hizo es, sobre todo, mejorar el cifrado y que hiciera falta realmente hacer "clic" sobre algunos enlaces para entender que realmente se quería acceder a la unidad. Además, actualmente, se utiliza también NTLMv2 como protocolo, que aunque no es perfecto, sí que ofrece una seguridad razonable. O sea, aunque exista un servidor SMB malicioso en la red y se envíen "sin querer" credenciales, lo más probable es que al supuesto atacante le cueste crackear la contraseña.

¿Y qué han descubierto nuevo?

La gente de Cylance ha descubierto que se puede conseguir el mismo efecto a través de la redirección HTTP y además usando "file://recurso" (era más habitual "\\recurso") para estimular el envío de los hashes. Esto abre nuevas puertas de ataque, volviendo "un paso atrás". En resumen, estas APIs (muy populares) dentro de URLMon.dll:

  • URLDownloadToFile
  • URLDownloadToCacheFile
  • URLOpenStream
  • URLOpenBlockingStream

...permiten que, si van a una página que redirige a un recurso SMB a través de un 301 o 302 de Apache (u otros métodos de redirección HTTP), terminarán enviándose los hashes de las credenciales. Ya no es necesario tener que intentar abrir una ruta UNC, o intentar montarlo en una unidad local. Desde ahora se sabe que cualquier programa que use URLDownloadToFile, por ejemplo, y se encuentre con un "file://servidor" en su tráfico, le dará las contraseñas cifradas a ese servidor. Para conseguirlo, basta con darle a ese programa páginas HTTP que redirijan a un "file://". Y esto incluye ya no solo sistemas de Windows, sino cualquier programa que utilice URLMon.dll, que no son pocos.

¿Es grave?

El módulo de Cain que caza credenciales SMB
Por un lado sí, abre las puertas a ataques más sencillos. Un atacante que controle un poco el tráfico en una red interna podría comenzar a cazar hashes de contraseñas del usuario más rápido y con solo redirigir el tráfico HTTP a un servidor SMB malicioso. También fuera de esa red.

Microsoft le resta importancia, por supuesto (e incluso da a entender que no hay nada que arreglar). En realidad el fallo ya era y es explotable. Es cierto que aporta un nuevo vector de ataque que lo facilita, pero el atacante que ya quisiera usarlo, lo estaría haciendo (y de hecho se hace en auditorías internas). Programas como Cain ya disponían de una forma cómoda de, en una red interna, capturar estos hashes.

También es cierto que esto no afecta a los atacantes más vulgares a los que no importan quién es su víctima sino cuántas son. A ellos no les interesan las contraseñas. A quien más beneficia esta vuelta de tuerca es a atacantes que buscan una empresa concreta a la que atacar... se les ha puesto en bandeja un método muy sencillo que le permitirá recopilar contraseñas de forma todavía más automatizada. Parece que facilita el ataque alojado "fuera de la red interna" (si es que se permite el tráfico SMB hacia redes externas) y en la interna lo potencia, además en que se amplía mucho el rango de programas o incluso scripts vulnerables.

¿Cómo protegerse?

Existen al menos tres formas, que ya debían estar implementadas para protegerse del ataque de 1997... pero vamos a recordarlas:

  • Obvia: mejorando las contraseñas. Las contraseñas que se envían están cifradas. Obviamente, si es más compleja de lo normal, puede que no pueda ser crackeada en un tiempo razonable.
  • Mejorando el protocolo. Por muy compleja que sea la contraseña, si se usa LM para autenticarse en red, nada servirá. Asegurarse de que se usa NTLMv2 y solo NTLMv2 para la autenticación en red. Eso está en esta opción de Windows (ver imagen). Pero no es suficiente con la opción por defecto... puesto que permitiría realizar un "downgrade" a LM quizás bajo ciertas circunstancias. Es necesario evitar el comportamiento por defecto y realmente rechazar LM.
Configurar Windows para que solo envíe hashes a través del protocolo NTLMv2

  • Limitando el tráfico SMB que sale. Normalmente el tráfico SMB va por el puerto 445 y 139 (UDP y TCP). El cortafuegos saliente podría evitar que saliese este tráfico a la red externa... Para limitar el tráfico se puede usar el cortafuegos corporativo, o el de Windows en local.

Usando el cortafuegos saliente de Windows para crear una lista blanca
de servidores SMB a los que se accede

  • También se puede mejorar la configuración de Windows. Existe un truco poco conocido que permite hacer una lista blanca de con qué servidores SMB nos vamos a comunicar, y evitar enviar credenciales al resto. Primero hay que "Denegar todo" en la opción de seguridad correspondiente. Y luego alimentar la lista blanca de direcciones IP o nombres NetBIOS. 


Creando una lista blanca hacia servidores externos desde las políticas de seguridad

Por último, jugar con la posibilidad de firmar el protocolo SMB, pero resulta algo más complejo. En resumen, la propia Microsoft ofrece muchas herramientas para protegerse. Y la razón de que haya tantas es por flexibilidad: la mejor forma será la que cause menos incompatibilidad en el sistema en el que se aplique.


Sergio de los Santos
ssantos@11paths.com

2 comentarios:

  1. En la revisión que acabas de publicar de: Maxima seguridad en Windows, viene ampliado este fallo?

    ResponderEliminar
  2. Hola. Por favor, contacta con el autor por email para responder a este tipo de preguntas. ¡Gracias!

    ResponderEliminar