In various editions of Windows, Server Message Block version 1 (SMBv1), a widely exploited vulnerability in various operating systems, remains a key attack vector in ransomware campaigns. Despite six years since WannaCry, organizations still face successful attacks, underscoring the critical need to disable SMBv1 promptly.
In this article, you will learn what is:
- SMBV1 vulnerabilities
- SMBV1 attack campaigns- coverage of the main cyber attacks
- Disable SMBV1 using PowerShell
- Disable SMBV1 using GPO
- What might break when disabling SMBV1
List of the critical SMBV1 vulnerabilities
SMBv1, also known as SMB 1.0, developed by IBM in 1984 and later adopted by Microsoft, is a network protocol for file and printer sharing. It was a cornerstone in Windows and Active Directory.
A simplified overview of how SMBv1 works:
SMB1 is a network protocol that enables file and printer sharing and communication between Windows devices on a network, primarily in Windows-based environments. Here's a simplified overview of how SMBv1 works:
1. Request and Response: a client sends an SMB request to a server to access files/resources, specifying information about the desired file or resource.
2. Authentication: authentication verifies client identity with methods like username/password and optional domain information, ensuring only authorized users access resources.
3. Share and File Access: enables client access to shared resources on a server. The client specifies the desired share in its request, allowing authorized actions on files within the share.
4. Data Transfer: enables data transfer between client and server, supporting read and write operations for accessing, modifying, and saving files remotely.
5. Error Handling: incorporates error-handling mechanisms to address issues during file access or operations, with the server sending error codes to the client for corrective action.
6.Closing the Connection: Clients can request to close the SMB connection after completing tasks, aiding efficient network resource management.
SMBV1 vulnerabilities
CVE MS 17-010: In February 2017 Microsoft released MS17-010, a security update that prevents denial of service and remote code execution. If you need this security patch, you already have a much bigger problem: you are still running SMBv1.
"The original SMB1 protocol is nearly 30 years old, and like much of the software made in the 80s, it was designed for a world that no longer exists. A world without malicious actors, without vast sets of important data, without near-universal computer usage"(MSFT Technet).
MS CVE-2017-0144, CVE-2017-0145, CVE-2017-0146, CVE-2017-0148
Later in 2017 due to the Wannacry attack that utilized the EternalBlue exploit, Microsoft issued the following CVEs. This came with a recommendation to try and disable SMBV1.
The Server Message Block SMB version 1 (SMBv1) server in Microsoft Windows allows remote attackers SMBv1 server in Microsoft Windows allows remote attackers to execute arbitrary code via crafted packets, aka "Windows SMB Remote Code Execution Vulnerability." This vulnerability is different from those described in CVE-2017-0144, CVE-2017-0145, CVE-2017-0146, and CVE-2017-0148.
The associated ransomware attack, dubbed "WannaCry", is initiated through an SMBv2 remote code execution in Microsoft Windows. This exploit (codenamed "EternalBlue") was made available on the internet through the Shadowbrokers dump on April 14th, 2017, and patched by Microsoft on March 14.
SMBV1 attack campaigns
Here is a list of notable cyberattacks and incidents involving SMBv1:
- WannaCry Ransomware (2017): Perhaps the most infamous SMBv1-related attack, WannaCry exploited a vulnerability in SMBv1 to rapidly spread across the globe, infecting hundreds of thousands of computers. It encrypted files and demanded a ransom for their release.
- Petya/NotPetya Ransomware (2017): Similar to WannaCry, the Petya/NotPetya ransomware also exploited SMBv1 vulnerabilities to spread. It caused widespread damage, particularly in Ukraine, where it initially targeted critical infrastructure.
- EternalBlue Exploit (2017): EternalBlue was a Windows SMBv1 exploit allegedly developed by the U.S. National Security Agency (NSA) but leaked to the public. This exploit allowed attackers to remotely execute code on unpatched systems, leading to widespread cyberattacks
- Bad Rabbit Ransomware (2017): Bad Rabbit used SMBv1 vulnerabilities to propagate within networks. It posed as an Adobe Flash update and infected Windows systems, encrypting files and demanding a ransom.
- WanaKiwi (2017): This was a decryption tool developed by security researchers to help victims of WannaCry recover their files without paying a ransom. It leveraged flaws in the ransomware’s encryption implementation.
- EternalRocks Worm (2017): This worm used the same EternalBlue exploit as WannaCry to spread. It was more stealthy and didn’t deploy ransomware but instead acted as a malware delivery system.
- DoublePulsar Backdoor (2017): This was a malware implant used in conjunction with the EternalBlue exploit to create a backdoor on compromised systems. It allowed attackers to maintain access and control over infected machines.
Disable SMBv1 with PowerShell
Disabling SMBv1 on Windows Server is fairly simple, whether on newer systems or older ones like Windows Server 2008, and no reboots will be required. However, if you are running Windows Server 2019 or above, SMBv1 will not be installed by default, so this is only necessary if you are running Windows Server 2016 or earlier.
Run the following command to disable SMBv1 in an elevated PowerShell session:
Set-SmbServerConfiguration -EnableSMB1Protocol $false
Copy
You can verify the command has run successfully by checking the configuration:
Get-SmbServerConfiguration | Select EnableSMB1Protocol
Copy
If successful, your output should show a value of False.
SMBv1 Disabled
Ensure new software and hardware supporting the SMB protocol can negotiate at least SMBv2, preferably SMBv3, for enhanced security. For existing devices limited to SMBv1, contact manufacturers for updates to support newer dialects.
Microsoft urges organizations to eliminate SMBv1 on legacy systems. In Windows Server 2016, SMBv1 is preconfigured to disable, but older systems remain vulnerable.
Patching the systems is a temporary solution; it is a matter of time until more vulnerabilities will be detected in SMBv1. Therefore it is critical to solve the problem permanently - stop using the SMBv1 protocol.
Both client and server-side SMBv1 usage should be disabled, with server side SMBv1 disabling as the primary risk from a security and operational (affect on production systems) perspective.
Disabling SMBv1 Client and Server via Group Policy
System administrators managing SMBv1-dependent IT infrastructure should prepare to remove SMBv1. Main concerns include third-party devices like printers, scanners, NAS, and WAN accelerators.
In an Active Directory domain environment, you can disable SMBv1 on all servers and SMB client computers using Group Policies (GPOs). Since there is no separate SMB configuration policy in the standard Windows Group Policies, you will have to disable it through the registry policy.
- Open the Group Policy Management console (game.msc), create a new GPO (disableSMBv1), and link it to the OU containing the computers on which you want to disable SMB1;
- Switch to the policy editing mode. Expand the GPO section Computer Configuration -> Preferences -> Windows Settings -> Registry;
- Create a new Registry Item with the following setting:
Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value name: SMB1
Value type: REG_DWORD
Value data: 0
What might break when disabling SMB1
Here are a few examples of SMB1 dependencies that should be taken into consideration when disabling it:
- Un-encrypted/sign communication between OS's and applications
- LM and NTLM V1 / V2 communication
- Low-level clients file/share communication or communication with high-level clients
- File/Share communication between platforms, for example, Linux to Windows via CIFS
- Legacy applications and SMB1 fixed communication applications, for example: Sophos, SonicWalls, EMC VNX, vCenter/ vSphere (AD integration), Aruba, Juniper Pulse Secure SSO, and more
- Printers and Print servers, for example: HP, Konica's, Toshiba's, Ricoh's, Xerox's, etc.
- Android communication to Windows server applications
- Different versions of OSx communicating with Windows
- Filers like NetApp (by default use SMB1 and can be changed to SMB2 or SMB3)
- Databases: MDB files used by many users at the same time. With SMB 2/3, the MDB will get corrupt; the only way is to use SMB 1
- Backup applications, for example: dump the configs to a share and keep a version for x amount of time
Before disabling SMB1, either via PowerShell or through the Control Panel, carefully study potential dependencies. Map SMB1 activity on servers, revealing all dependencies. Consider operational risks, and leverage Calcom Hardening Suite’s learning capabilities for automated mapping, saving time and reducing risks.
Disabling SMB1 must be integrated into the organization's hardening policy. Both existing and new servers should be configured to use up-to-date versions of the SMB protocols. SMB1 is only one example of why you should harden a broad security policy for your servers. Echoing the recommendations of specialists like Ned Pyle, both existing and new servers should be configured to use up-to-date versions of the SMB protocols.
