Exploiting and Protecting Against CVE-2017-0016 (SMB 0-day)

The Vulnerability

CVE-2017-0016 has been explained on many sites, but has yet to be shown a walkthrough to put into perspective just how bad this flaw is and what we can do (in the meantime) until Microsoft releases a patch. The vulnerability exists in Windows 8.1 and newer systems (I successfully tested Windows Server 2012R2 (8.1) and Windows 10. The exploit did not seem to affect Windows 7.) Some sources with a rundown of the flaw include:

• http://malwarejake.blogspot.com/2017/02/why-you-should-care-about-cve-2017-0016.html
• http://www.darkreading.com/attacks-breaches/windows-smb-zero-day-exploit-on-the-loose-/d/d-id/1328056

The Exploit

The source code for this exploit has been released on Github over a week ago and is located here. To pull this off, the only thing the attacker needs is the two python scripts (win10.py refers to odict.py... so you only have to run win10.py from command line). 

The Exploit in Action

I'm simply using two Virtual Machine in VMware Workstation:

• Kali Linux Rolling
• Windows 10 (Free Microsoft IE/Edge test Virtual Machines located here)

The preparation for Kali is extremely easy:

• Open a terminal and create the two python scripts and paste (ctrl-shift-v) the Github code inside each one
  vi win10.py
  vi odict.py
• Create a "web page" in the default Apache directory with an embedded SMB link of some kind back to the attacker machine (My IP of my attacker machine is 192.168.190.132 and I'm using an "image" tag in my example)
• vi /var/www/html/badpage.html

• Start the Apache2 service
  /etc/init.d/apache2 start
• Run the win10.py script
  python win10.py

The "preparation" for the Windows 10 VM is simply a gullible user... This could come in the form of phishing, a defaced web site, or other client-side attack vector. In my example, I simply browse to "http://192.168.190.132/badpage.html" with either Internet Explorer or Edge since these browser STILL support SMB integration.

And... here's what I get seconds later:

Looks like the flaw worked as it crashed the client workstation (Denial-of-Service, if you will).

What Can be Done to Protect Ourselves?

Mitigation is rather easy for external attacks... Block all internet-bound SMB! There is likely NO need for this traffic. Ever. As a community, we've done a good job at blocking inbound TCP 139 and 445 due to the many previous service-side exploits against NetBIOS and SMB, but nothing for outgoing connections.

When it comes to internal attacks... there may be bigger problems since the "trusted" network is now infested with malware. One way to potentially prevent this is to only allow SMB between clients and approved servers (configurable in Windows Firewall or another host-based firewall).

Example Windows Firewall configuration:

• Start >> type "Firewall" and select "Windows Firewall

• On the left side of the screen, choose Advanced 

• Select "Outbound Rules" and "New Rule..."

• Walk through the prompts and choose:
• "Port"
• "Specific Remote Ports: 139,445"
• "Block the connection"
• Apply rules to all network types
• Give the rules a name (e.g., "Outbound SMB Block")
• The rule should now be at the top (if not, put it there so it is processed first -- before any other programs could potentially allow SMB connections).
• If SMB to a file server is needed, create a VERY SPECIFIC SMB rule above this one to allow only those approved SMB connections.

Upon re-testing this exploit by navigating to 192.168.190.132, it appears that this mitigation was successful... NO CRASH!

What's next?

This is likely only the beginning of this exploit. Many exploits begin life by crashing a system, but it's just a matter of time before it is morphed into something more malicious (e.g., information disclosure, privilege escalation).