- Join Windows 11 to an Active Directory domain - Thu, Jun 1 2023
- Change Windows network profiles between public and private - Wed, May 24 2023
- How to map a network drive with PowerShell - Wed, May 17 2023
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
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
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
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
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.
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.
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.
BTW another great post Wolfgang. Where are your topic ideas comes from? I would need some here too, hehe.
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.
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