In the wake of several high-profile malware events, it comes almost as no surprise that SMB1 is not enabled by default. The security vulnerabilities, in addition to the serious performance problems with the now-ancient file transfer protocol, are enough to push this over the edge. Undoubtedly, some enterprises will be running ancient file services (filer appliances that were never updated, old OS installs that can't be upgraded, and so on--the skeletons in the enterprise closet so to speak). And for those, enable away I suppose. Or maybe join the 2000s finally and leave them off.
For those who are not convinced, from Microsoft's own Ned Pyle, who owned SMB for some time as a PM:
When using SMB1, you lose key protections offered by later SMB protocol versions, such as:
- Pre-authentication integrity (SMB 3.1.1+ https://blogs.msdn.microsoft.com/openspecification/2015/08/11/smb-3-1-1-pre-authentication-integrity-in-windows-10/): Protects against security downgrade attacks.
- Secure Dialect Negotiation (SMB 3.0, 3.02 https://blogs.msdn.microsoft.com/openspecification/2012/06/28/smb3-secure-dialect-negotiation/): Protects against security downgrade attacks.
- Encryption (SMB 3.0+ https://blogs.msdn.microsoft.com/openspecification/2015/09/09/smb-3-1-1-encryption-in-windows-10/): Prevents inspection of data on the wire and MiTM attacks. In SMB 3.1.1, encryption performance is even better than signing!
- Insecure guest and blocking (SMB 3.0+ on Windows 10+ https://msdnshared.blob.core.windows.net/media/2016/09/2016-09-14_17-15-54.png): Protects against MiTM attacks.
- Better message signing (SMB 2.02+ https://blogs.technet.microsoft.com/josebda/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2/): HMAC SHA-256 replaces MD5 as the hashing algorithm in SMB 2.02; SMB 2.1 and AES-CMAC replaces that in SMB 3.0+. Signing performance increases in SMB2 and 3.
