News

Microsoft Offers More Advice on Disabling Windows SMB 1

• By Kurt Mackie
• 05/18/2017

Microsoft's position on Server Message Block version 1 (SMB 1) in Windows systems is that organizations should just get rid of it.

That position has become crystal clear after SMB 1 proved to be a conduit for a ransomware outbreak this week. The ransomware, dubbed "WannaCry," used leaked hacking-tool code, purportedly from the U.S. National Security Agency, that targeted a Windows SMB 1 flaw. One of the "owners of SMB" at Microsoft, Ned Pyle, a principal program manager in the Windows Server high availability and storage group, had warned about continuing to use SMB 1 back in September in a TechNet article titled, "Stop Using SMB 1."

Essentially, the 30-year-old SMB 1 protocol permits man-in-the-middle exploits and it "isn't safe" to use, Pyle noted. An attacker can use SMB 2 to pull information from the insecure SMB 1 protocol if it exists in a network, he explained:

The nasty bit is that no matter how you secure all these things, if your clients use SMB1, then a man-in-the-middle can tell your client to ignore all the above. All they need to do is block SMB2+ on themselves and answer to your server's name or IP. Your client will happily derp away on SMB1 and share all its darkest secrets unless you required encryption on that share to prevent SMB1 in the first place. This is not theoretical -- we've seen it.

Analysis by Kaspersky Lab had indicated that SMB 2 was involved in the WannaCry ransomware attacks. It seems that the flaw actually resides in SMB 1, but attackers use SMB 2 as part of the exploit, according to Pyle's explanation above.

SMB 1 Exceptions
Some IT pros are finding to their surprise that SMB 1 is used in their networks. Moreover, disabling SMB 1 has led to problems, such as failed network shares, as described in this Spiceworks forum post.

Pyle acknowledged that SMB 1 still might be needed in certain cases, but he added that most end users or businesses shouldn't be affected by its removal. According to Pyle, the only reasons to continue to use SMB 1 include:

• You're still running XP or WS2003 under a custom support agreement.
• You have some decrepit management software that demands admins browse via the 'network neighborhood' master browser list.
• You run old multi-function printers with antique firmware in order to "scan to share."

Recent posts by Ralph Kyttle, a premier field engineer at Microsoft, explained that it's possible to disable SMB 1 in networks where SMB 2 or SMB 3 are present if using Windows Server 2008 or greater versions, since the server will seek out the next SMB protocol to establish communications. He acknowledged, though, that SMB 1 dependencies may exist for "printers, NAS, [and] manufacturing gear" that could be running Windows or Samba/Linux. He suggested capturing network traffic using the Microsoft Message Analyzer tool or PowerShell's Desired State Configuration Environment Analyzer to check for SMB 1 dependencies.

Microsoft introduced SMB 2 in Windows Vista and Windows Server 2008, while SMB 3 got added with Windows 8 and Windows Server 2012, according to a February Microsoft support article titled, "How To Enable and Disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server."

Enterprise Advice
This week, Microsoft posted a TechNet article on how to "Disable SMB v1 in Managed Environments with Group Policy." This article contains a caution for IT pros regarding the February support article's guidance. Some of the quick fixes to disable SMB 1, as listed in that support article, can be a problem for "large-scale managed enterprise environments," the TechNet article explained:

Microsoft in February updated and published a TechNet article on how to enable or disable various versions of SMB using:

• The Registry Editor for LanmanServer
• PowerShell's Set-SmbServerConfiguration for SMB server
• sc.exe with config options for lanmanworkstation

Caution! While these tools can work for quick configuration changes, this combination approach is not very manageable in large-scale managed enterprise environments where consistent configuration is required.

For enterprises, Microsoft's preferred approach for disabling SMB 1 is to perform a registry change to Group Policy Objects. Step-by-step guidance on how to use Group Policy can be found in the "Disable SMB v1 in Managed Environments with Group Policy" TechNet article.

Also this week, Microsoft offered guidance for users of its Azure services on protecting against exploits like the WannaCry ransomware attack. The recommendations included eight steps for "all Azure customers" to take, including installing MS17-010 (the "critical" March Windows patch), disabling Internet access on certain ports and disabling SMB 1, among other measures.

In addition to using Microsoft's tools to capture network traffic data to check for SMB 1 use, it's possible to run SQL queries in System Center Configuration Manager to check that MS17-010 has been installed across a network. Vinay Pamnani, a Microsoft CSS support escalation engineer, posted some queries that can be run to check for compliance in this TechNet blog post.

The Microsoft Dynamics team also indicated this week that it is taking action to protect against the WannaCry ransomware. The team is patching Dynamics AX virtual hard disk images used by Dynamics 365 developers, according to an announcement.