SMB1 is baaaaaad!

Every once in a while, something comes along in the IT world where everyone panics.  And I mean PANICS!  The lastest SMB1 vulnerability is that panic generator.  It's so bad that they created 6 different CVEs to cover it.

Vulnerability title	CVE number
Windows SMB Remote Code Execution Vulnerability	CVE-2017-0143
Windows SMB Remote Code Execution Vulnerability	CVE-2017-0144
Windows SMB Remote Code Execution Vulnerability	CVE-2017-0145
Windows SMB Remote Code Execution Vulnerability	CVE-2017-0146
Windows SMB Remote Code Execution Vulnerability	CVE-2017-0148

Supposedly this zero-day vulnerability can leak information and allow for remote code execution.

What?   Zero day??   Remote code execution? Huh?  Let me try to break this down for you and give you the "what this means to me" speech.

1.  Zero-day Exploit

This is just a highly technical term to say this vulnerability has been in place since the initial release of this code/function/feature.  For this SMB1 vulnerability, this means that the vulnerability has been in Windows since at least Windows Vista (which is the earliest version that Microsoft still supports), and could possibly even be in Windows XP, Windows 2003 and Windows 2000.  But since Microsoft no longer officially supports those Windows versions so they won't divulge that information.

2. Remote code execution

This one is a little more nebulous of a term.   Well... ok you can execute something remotely on some machine.   Great!   I can do a "dir" on a remote machine.  Which machine?  The "server" or the "client"?  With SMB1 there is the concept if the "server"; the machine serving the files.  and the "client"; the machine that connects to the "server" to read, change or delete those files.  These particular SMB1 vulnerabilities allow for a malicious (read: highly modified) client to exploit that vulnerability to run commands on the SMB server. This can lead to being able to download things like password databases and other mean things.

TURN OFF SMB1!

The SMB1 code is old.  Ancient in fact.  It was developed for Windows 2000.  It's inefficient, clunky and chatty.  That being said, there are still devices out there that use it and cannot use anything newer.  Network printers, Linux hosts (fairly recent ones too) and a number of embedded systems still use the old SMB1 code to communicate and cannot use the SMB2 or 3 protocol to communicate so turning off SMB1 completely in your environment may not be possible.  What you can do in this situation is to turn off the protocol on devices that do not require any SMB1 connections to it.  Microsoft has a way to do this through GPOs (Group Policy Objects).  There is a good Technet blog on this here: https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

But I have a NetApp filer and can't turn off SMB1.   What can I do?

NetApp, both 7-mode and clustered Data ONTAP have SMB servers built in.  If you have them licensed, then you can serve Windows file shares through it.  Is it vulnerable?  Probably not.  The vulnerabilities with Windows, and specifically with these SMB1 ones are within the Windows Operating System code.  Data ONTAP does not run Windows Operating System code.  It has a custom built SMB server that adheres to the protocol standards, but the source code that runs that protocol is completely different than the Windows source code so the risk of having the vulnerability in two completely different implementations are almost non-existent.

How do I know if I still need SMB1??????

With devices still around that require SMB1 for their functionality to work, You need to be informed if devices are still using it.  The way the SMB dialects work, the negatiation on which version to use is basically a highest common denominator type negotiation.  When the client connects to the SMB server, the client sends all the SMB dialects it supports.  (SMB1, SMB2, SMB2,1, SMB3, etc)   THe server then picks the highest common version.  So if a server supports SMB1, SMB2 and SMB2.1 and the client supports SMB1, SMB2, SMB2.1 and SMB3, the result of that negotiation will result in an SMB2.1 conversation.

In 7-mode, you can see which version clients have been negotiated to by running the command:

cifs sessions -p smb

Then you get the output as follows:

Server Registers as 'TOASTER' in Windows domain 'MYDOMAIN'
Root volume language is not set. Use vol lang.
Selected domain controller \\TOASTER for authentication
====================================================
PC IP(PC Name) (user) #shares #files
10.10.1.15() (MYDOMAIN\administrator - pcuser) 2 0


The above indicates that you still have a device at 10.10.1.15 running SMB1.

In cDOT, you have a similar command:

cluster::> cifs session show -protocol-version SMB1

which outputs

Node:    cluster-01
Vserver: CIFS-SVM
Connection Session                                        Open            Idle
ID         ID      Workstation      Windows User         Files            Time
---------- ------- ---------------- ---------------- --------- ---------------
4268056359 1       10.10.1.15      MYDOMAIN\                0              5s
                                    administrator


and you can tell which systems have negotiated to SMB1.

Can I firewall it?

Well....   yes....    well..... no.....   well.........

There is but one TCP port that all SMB dialects use and that is port 445.  If you block port 445 within your internal network, then absolutely no Windows File Services will be available regardless of SMB dialect.  BUT I fully suggest that at your internet connection, you block all inbound and outbound connections to port 445!  It's always smart to allow only absolutely necessary traffic in and out of your network but that's getting into a post for another time.