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

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:
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.
The machine with the IP address 192.168.1.111 is our attacking machine, where we are running capture/smb Metasploit module
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.
The vulnerable folder now contains our SCF file

At this point, our Metasploit console must be showing something like this
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.
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.
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
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!