The SMB protocol has repeatedly proven to be a weak point that hackers exploit for their attacks. CVE-2020-0796 is the latest example of this. In addition to installing patches to mitigate known vulnerabilities, you should only allow the most necessary SMB communication on the computers in your network.

The recently discovered remote code execution vulnerability affects SMB 3.1.1, which is used in Windows 10 1903 and 1909. The March cumulative update (KB4551762) includes a fix for this issue. It is distributed as usual via WSUS and Windows Update. For offline patching, it can be downloaded from Microsoft's catalog.

Querying the status of services

In order to be better prepared for future vulnerabilities in SMB, computers that do not share directories or printers should not respond to SMB requests.

However, there is a threat not only from malicious access to a PC but also in the other direction, when the PC connects to a compromised SMB server. The simplest solution would therefore be to deactivate the LanmanWorkstation and LanmanServer services. You can check their status in PowerShell using the

Get-Service -Name Lanman*

query.

Querying the status of Lanman services with PowerShell

Querying the status of Lanman services with PowerShell

SMB is indispensable

The problem with this approach, however, is that machines in a domain need the workstation service to retrieve group policies from a domain controller (DC). In addition, virtually all companies use a file server or NAS that would not be accessible without the SMB client.

Hence, even if the server service is switched off, it is still necessary to secure the client. One measure is to make sure that SMB1 is not installed. Normally, no modern system or application should require this outdated protocol anymore.

Disabling SMB1

In newer versions of Windows, SMB1 is disabled by default. You can verify this in PowerShell by using the following command:

Get-WindowsOptionalFeature -online | where FeatureName -like SMB1*

and if necessary, to uninstall it using

Get-WindowsOptionalFeature -online | where FeatureName -like SMB1* |
Disable-WindowsOptionalFeature -Online
Using PowerShell to check if SMB1 is installed

Using PowerShell to check if SMB1 is installed

Blocking SMB connections to the Internet

Since you can't simply do without SMB in Windows domains, firewalls must be used to restrict access. SMB communication to computers on the Internet is usually not necessary, especially if it is initiated from outside. Therefore, port 445 should be closed on perimeter firewalls for incoming and outgoing traffic.

To prevent internal attacks, configure the Windows Defender Firewall on machines that do not share resources and block access to these services:

  • Netlogon Service (NP-In)
  • File and Printer Sharing (SMB-In)
  • Remote Event Log Management (NP-In)
  • Remote Service Management (NP-In)

Checking the status of the rules

The namesake rules are deactivated in Windows 10 by default for all profiles. PowerShell can verify this with:

Get-NetFirewallRule -Direction Inbound |
where {($_.DisplayName -Like "*(NP*" -or $_.DisplayName -Like "*(SMB*") } | 
select DisplayName, Enabled, Profile
Default Windows Defender Firewall rules for file services

Default Windows Defender Firewall rules for file services

Microsoft also recommends creating an additional rule to block port 445 for incoming traffic and not to rely only on the default settings. The default rules could inadvertently be activated by installing a software package so that PCs answer incoming SMB requests.

Defining an additional firewall rule that blocks incoming SMB traffic

Defining an additional firewall rule that blocks incoming SMB traffic

Such a port rule should apply to TCP, all remote computers, programs, and profiles. In centrally managed environments, it can be distributed using group policy.

Custom rule for Windows Server

Windows servers have the same default rules for port 445 as Windows 10. If file/storage services are activated, such as on DCs or file servers, then at least the File and Printer Sharing (SMB inbound) rule will also be enabled.

In this case, you could deactivate this rule and create your own that limits access to certain IP addresses. With PowerShell, you could do it like this:

Subscribe to 4sysops newsletter!

New-NetFirewallRule -Name "AllowSMB" -DisplayName "Allow SMB" -Enabled True `
-Profile Domain -Direction Inbound -Action Allow -RemoteAddress 192.168.0.64 `
-Protocol TCP -LocalPort 445 -Program System

For RemoteAddress, you can also specify a range in the form 1.2.3.0-1.2.3.100. Alternatively, this parameter accepts predefined constants such as DNS, DHCP, WINS, DefaultGateway, Internet, or Intranet, but these are not documented. LocalSubnet speaks for itself, which will fit in many cases.

avataravataravatar
5 Comments
  1. Samir 3 years ago

    This probably sounds crazy but if smb over tcp/ip is the issue, don't use tcp/ip as the protocol.  For years smb was run over ipx and even netbeui.  I'm sure a modern day solution could use such a technique to avoid the issue altogether in certain environments.

    • Leos Marek (Rank 4) 3 years ago

      SMB, from what I know, was always communicating via TCP protocol. NetBEUI or NetBIOS, is also running on TCP and has a bit different purpose than SMB…

      The topic Wolfgang writes about is a known thing. SMB had serious vulnerabilities issued over the years and it is recommended that you disable SMB in your environment everywhere, where its not needed. It is quite common that the Server service (thus SMB) is disabled on workstations.

      In Windows, however, you need SMB to communicate with the DC.

  2. Leos Marek (Rank 4) 3 years ago

    BTW another great post Wolfgang. Where are your topic ideas comes from? I would need some here too, hehe.

    • Wolfgang Sommergut 3 years ago

      Hi Leos, thanks for your kind words 🙂 The idea for this post came up when I did some research about the recent CVE-2020-0796.

      avataravataravatar
  3. Ingmar Koecher 3 years ago

    Thanks for pointing this out – definitely an important info. For what it's worth, we recently published instructions on how to remedy this CVE with EventSentry. Although EventSentry is primarily a monitoring solution, the applications scheduler feature can be adapted to fix this vulnerability:

    https://www.eventsentry.com/kb/415

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2023

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account