On 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 80’s, 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).
Disabling SMBv1 do it slow or don’t do it!
If you are a systems administrator and you manage IT infrastructure that relies on SMBv1, and you haven’t done so yet, you should prepare to remove SMBv1. Since Windows Server 2003 is gone, the main concern will be third party software or hardware like printers, scanners, NAS devices and WAN accelerators.
Disabling SMBv1 is very complicated as many applications, platforms, printers, etc., are heavily dependent on it. SMBv1 should be carefully examined on an OS basis before hardening is performed. An in-depth test must be performed prior to disabling SMBv1 in order to map all the SMBv1 communication between Windows machines and devices/applications. Learn more about automating SMBv1 mapping with CalCom hardening automation learning capabilities.
You should make sure that any new software and hardware that requires the SMB protocol is able to negotiate newer versions (at least SMBv2, preferably SMBv3). For existing devices and software that only support SMBv1, you should contact the manufacturer for updates to support the newer dialects.
Microsoft really wants organizations to get rid of SMBv1. During the last 6 months two critical remote code execution vulnerabilities have been discovered in the protocol and patches were published.
- September 2016: MS16-114: Security Update for Windows SMBv1 Server (3185879)
- March 2017: CVE-2017-0147, MS17-010 Security Update for Microsoft Windows SMB Server (4013389)
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) perspectives.
What might break when disabling SMBv1
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/shares communication or communication with high level clients
- File/Shares 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 change 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
There are dozens, if not hundreds, of potential dependencies that should be carefully studied and examined before disabling SMB1. We recommend learning and maping the activity of SMB1 on your servers. IT teams should keep in mind that there is an operational risk in disabling SMBv1; the usage of the SMBv1 protocol should be mapped and all the dependencies must be revealed on servers before hardening. Using the Calcom Hardening Solution (CHS) learning capabilities saves time and lowers the operational risk related to hardening SMBv1. CHS’s learning mode provides automated usage mapping and reveals the systems and applications dependent on the protocol.
Disabling SMB1 must be integrated to 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.
References and additional information:
- Microsoft KB: How to enable and disable SMBv1, SMBv2, and SMBv3 in Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012
- Microsoft TechNet Blog: Stop Using SMBv1 (and how to disable on Windows 8.1, 2012 R2, and above)
- Microsoft TechNet Blog: The Deprecation of SMB1 – You should be planning to get rid of this old SMB dialect
- US-CERT: SMB Security Best Practices
- The Register (news): Kill it with fire: US-CERT urges admins to firewall off Windows SMB
- US-CERT – Warning, Shadow Brokers Hackers are offering an SMB Zero-Day exploit