This white paper details what additional steps IT pros need to take to safeguard their networks and systems and why they should leave the newer versions of SMBs alone.
With the recent appearance of the “WannaCry” ransomware cyber attacks, the vulnerability of the 30-year old SMB1 protocol was finally laid bare. Through the use of an exploit tool called “ETERNALBLUE” and leaked from the NSA by the “Shadow Brokers” hacker group, the vulnerabilities in the Server Message Bock (SMB) services were successfully exploited to spread its malicious denial-of-service mayhem.
Most of the hacks affected those with older, less-secure systems, as with Windows XP and Windows Server 2003, which are so old that they are no longer even supported. Security bulletin MS16-114 detailed the vulnerabilities of the protocol implementations in those (mostly older) Windows versions.
The Microsoft Corporation hurriedly issued a “critical” security bulletin release to be installed in networks as a safety measure but even Microsoft’s engineers are in agreement that the only reliable way to stop the spread of the virus is to disable the SMB1 protocol completely.
But, you say, I have a newer version as well as SMBv2 or 3 and besides, aren’t the Microsoft protections enough to stop the ransomware’s infestation? Why bother with tinkering with the SMB at all – isn’t that a bit of overkill?
That’s only part of the story: even with a patch or other protective installations and newer versions of the SMB, there is remains the very real problem of interaction with other devices that may need to continue to connect with SMB1, such as printers or other peripherals. The real problem is, according to Microsoft field engineer Ralph Kyttle, that SMB1 is still lurking in your computer’s innards or those of your clients, who can unwittingly act as SMB servers by ‘talking’ to devices using SMB1, including printers or NAS or anything else that might be running Windows or Samba/Linux. This is why even those at Microsoft highly recommend getting rid of SMB1 as soon as you download their version-specific instructions.
Solution #1: Follow Microsoft’s instructions for disabling the SMB feature
If you want to remove the possibility of a future hack or another SMB1-related security issue, the best – really, the only – way, according to Microsoft’s Principal Program Manager and engineer Ned Pyle, is to remove it completely. Microsoft gives somewhat differing instructions according to this link depending on which OS you are using. Be sure to backup your data before trying to follow their advice as there is a possibility there may be a change to the Windows Registry – and not following the steps as set forth by Microsoft could result in your machine crashing altogether.
Solution #2: Banishing SMB1 “zombies”
Like a zombie rising from the grave, even a disabled SMB1 has a way of coming back to haunt users all over again. Because of the real possibility of post-removal SMB1 interactions, Kyttle recommends that IT pros use one of more of the following methods to detect SMB1 network dependencies, such as network capture and other software and tools to detect and remove any noncompliant configuration.
It’s worth noting that Microsoft offers tools for IT pros to detect whether SMB1 is being used within a network. One is the Microsoft Message Analyzer, a tool which displays logs of inbound and outbound traffic which can be subject to filtering for SMB1 activity.
Another useful tool is PowerShell’s Desired State Configuration Environment Analyzer (DSCEA) module. Requiring PowerShell version 5.0, DSCEA shows compliance information via Power BI or HTML, allowing IT pros to use the scans to repair problematic configurations.
Finally, users should be aware that depending on an individual computer’s configuration as well as other variables, there have been reports that SMB1 had to be reinstalled at least temporarily, in order to authenticate domains and access shares.
Solution #3: SMB2 and SMB3: Love ‘em or leave ‘em?
Most experts say to leave them because unlike with SMB1, they’re there for some pretty good reasons. Microsoft warns that disabling them should be viewed only as a temporary measure – be sure to enable them once done with troubleshooting tasks.
Here’s what you stand to lose if you leave these two important SMB protocols disabled:
In Windows 7 and Windows Server 2008 R2:
Disabling SMB v2 deactivates the following:
- Caching of folder and file properties allowing clients to retain file copies
- Improved use of faster networks through larger reads and writes
- Durable handles which permit transparently reconnection to the server in case of a temporary disconnection
- Request compounding which allows the user to send multiple SMB2 requests as a single request
- Improved scalability for sharing files, increasing the number of users, shares and open files per server
- Improved message signing with MD5 hashing algorithm replaced by HMAC SHA-256
- Better support for symbolic links
- Client oplcock leasing model which limits transferred data between client and server, resulting in improved SMB server scalability and performance with high-latency networks
In Windows 8, Win 8.1, Win 10, Windows Server 2012, and Windows Server 2016:
Disabling SMBv3 deactivates the following (as well as previously-described SMB2 functions):
- Concurrent access of shared data on file cluster nodes via Scale Out
- End-to-end encryption and protection from eavesdropping by untrustworthy networks
- Transparent failover allowing clients to reconnect to cluster nodes without interruption during failover or maintenance
- Directory leasing which improves branch offices’ application response times via caching
- Multichannel aggregation of fault tolerance and network bandwidth if multiple paths are available between client and server
In the aftermath of this hacking, taking steps for immediately removing SMB1 should be a no-brainer. Removal, however, is only part of the solution: doing so can bring in other, possibly unwelcome consequences. Thanks to the sheer pervasiveness of SMB1, IT pros can’t let down their guard even after disabling the pesky protocol. So, while it may at first seem like overkill, in today’s cyber environment it’s better to be safe than sorry.