Problem solve Get help with specific problems with your technologies, process and projects.

Server Message Block Version 2 security in question: Disable or patch?

Nick Lewis reviews the recent vulnerability discovered in a popular Windows file-sharing and printing protocol. Yes, there's a patch, but should you deploy it, or simply disable SMBv2?

In early September, Microsoft advised users of a remote code execution vulnerability found in its Server Message...

Block Version 2 (SMBv2) protocol. SMB is a file sharing and printing protocol used in Windows to pass messages between networked devices.

Researchers developed working exploit code that could be used to exploit the flaw and cause a denial of service (DoS) or unauthenticated remote code execution. This exploit code has been publically released as well.

Early on, Microsoft released a fix that disabled SMBv2. SMBv2, an update to the protocol, is only supported on Windows Server 2008, Windows Vista and Windows 7, and can only be used if both the client and server support it. Windows Vista SP2 and prior and Windows 2008 SP2 and prior are vulnerable. Windows 7 Release Candidate is also vulnerable, but was patched prior to Windows 7's official release. Windows XP, Windows 2003 and Windows 2008 R2 are not vulnerable.

Patch management expert resources

What patch management metrics does Project Quant use?

Should management processes change based on a patch release schedule?

Ask your own question

In October, the software giant issued a security patch as part of its normal Patch Tuesday cycle. Enterprises were recommended to apply this patch during their normal patching cycle, and if they could not deploy it, they should have done so prior to the next Microsoft patch release. In this tip, let's explore why enterprises should consider expediting SMB patch deployment or using one of the workarounds.

Remote code execution or denial-of-service attacks are serious threats to an environment. The Server Message Block Version 2 security vulnerability could be incorporated into bots, worms or other malicious code to attack an organization, access its data and gain a further foothold into its network. Many bots, worms, or other types of malicious code are developed in a modular fashion to easily incorporate new attack methods and vulnerabilities.

For example, the notorious Conficker worm (or Conficker/Downadup) used several different Windows vulnerabilities to spread and infect systems. Similarly, the SMB vulnerability has the capability to be included in a worm and spread quickly. While the exploit code hasn't yet been included in other malware, it could be incorporated into worms or bots and used in targeted attacks. It also has been included in the Metasploit open source penetration testing framework.

However, the likelihood of being exploited on client computers is negligible, unless several best practices are not followed, namely disabling the default host-based firewall and not firewalling Windows networking, including SMB functionality, at the perimeter(s). The exploits depend on malicious code reaching a vulnerable host over Windows network using SMBv2. The likelihood of being exploited on Windows Server 2008 is higher because a file or print server would not be able to firewall off Windows networking from clients' systems.

Enterprises unable to deploy the patch immediately should use one of the workarounds, which will disable SMBv2 to ensure adequate projection of your systems until the patch is deployed; we'll get to those in a minute. But one question an enterprise must answer before deploying a workaround is if doing so will be less effort than deploying the patch. The deployment mechanisms are potentially different between the patch and the workarounds.

The patch can be deployed with standard patching tools, but executing a workaround may require additional test and deployment efforts. There are two ways to disable SMBv2 using workarounds: Microsoft released a FixIt package that will disable version 2 of the Server Message Block. SMBv2 can also be undone via a registry key that requires restarting the server service. Both will require re-enabling SMBv2 after the patch is deployed to make the functionality available again.

Disabling the server service has been suggested as a workaround, but this may have a significant effect on systems because the server service is core to the operations of some management systems and providing Windows file and print services. An additional workaround is to re-enable the Windows firewall to the default state. Both of these options would need significant testing prior to deployment; dependent software or services need to be identified by re-enabling the Windows firewall.

For future similar Windows networking or SMB vulnerabilities, enterprises should follow the same advice and compare the effort to deploy the patch, workaround, and availability of exploit code to determine the most appropriate strategy for their environments. Compare the risk for a new vulnerability and exploit to your environment to the amount of effort to adequately protect your environment from a new vulnerability. Deploying perimeter firewalls and utilizing client firewalls will help reduce the risk from computers being exploited over the network by the SMBv2 vulnerability.

About the author
Nick Lewis (CISSP, GCWN) is an information security analyst for a large Public Midwest University responsible for the risk management program and also supports its technical PCI compliance program. Nick received his Master of Science in Information Assurance from Norwich University in 2005 and Telecommunications from Michigan State University in 2002. Prior to joining his current organization in 2009, Nick worked at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University. He also answers your information security threat questions.

This was last published in February 2010

Dig Deeper on Microsoft Patch Tuesday and patch management