smbclient Security for Windows Printing and File Transfer

SMB Protocol Security

The unfortunate synopsis for SMB security is that, for the most part, there is none.

While the credentials establishing a login are encrypted, the network payload (that is, a print job or file transfer) is transmitted in clear text in Microsoft's SMB1 and SMB2 protocols, and there is no capability for native encryption. Microsoft introduced encryption options for SMB3, but they are not enabled by default due to performance. Sensitive content should not be transmitted over any version of SMB unless the server mandates encrypted transfers, and this is confirmed by a client attempting a clear-text login.

Samba for UNIX implemented encryption extensions for SMB1/NT1 starting with the 3.2 release in 2008. Microsoft ignored these improvements, and Windows users were forced to wait until 2012 for SMB3 encryption. Microsoft's improvements to SMB2 during this time focused foolishly on throughput, as if performance was somehow more important than security (even after total market victory, they were still struggling to beat Novell IPX/SPX technically).

Windows 7 and Server 2008 lack SMB3, and SMB transfers on these platforms with the native clients and servers are wide open. Do not transmit sensitive data using any SMB cleartext protocol over networks that you do not absolutely trust. Unfortunately, Windows 7 remains the most popular release in the field (due to the aesthetic challenges of Windows 8 and the Stalinesque oversight of Windows 10).

Windows 7 is the desktop OS leader as of February 2017 with 48.41% of the market. As Windows XP still holds 8.45%, one can say that the majority of the Windows market has chosen clear-text SMB over encryption. The Windows 7 community's refusal to upgrade has the unfortunate side effect of flooding their networks with clear-text transfers.

A workaround exists that uses third-party tools to wrap SMB in TLS encryption. The stunnel utility can cloak any version of SMB as demonstrated in a NetBSD tutorial. Unfortunately, the \\localhost share is used on UNIX clients, allowing only a single encrypted connection—if you need to access two sensitive servers, you have to decide which one you love more. For Windows clients, an elaborate invocation of "localhost" interfaces configured with entirely fictitious addresses are required (abandon all sanity all who enter here)—this effectively means that "map network drive" will be far too complex for general users (and require elevated rights that they should not possess). Such drive mappings will require a knowledgeable administrator.

Note also that, when enabling Microsoft's SMB3 encryption, SMB1 must be completely disabled (Samba for UNIX does not have this problem). Microsoft has disabled SMB1 by default with Windows 10 for obvious reasons and is evangelizing the removal on older systems. The user community might prefer that Microsoft simply replace its SMB stack with Samba (one can dream). A more realistic alternative is the installation of Microsoft's native port of SSH for the secure transfer of files and print jobs, if Windows administrators finally have the will to forego the flaws of SMB (the sshfs filesystem might be of particular interest).

In any case, you can force smbclient to insist on encryption of some kind (either Samba's NT1 or SMB3 varieties) with the -e flag—it will abort when encryption is unavailable (note that you may need to set the server signing = auto configuration option on Samba for UNIX). Below is an example of a connection to an encrypted SMB1/NT1 server:


$ smbclient -e //badsmb-cleartext.somecompany.com/public -U ntid -W w_dom
Enter ntid's password:
smb_signing_good: BAD SIG: seq 1
session setup failed: NT_STATUS_ACCESS_DENIED

$ smbclient -e //samba-secure.somecompany.com/public -U ntid -W w_dom
Enter ntid's password:
Domain=[W_DOM] OS=[Unix] Server=[Samba 3.6.23-13.0.1.el5_11]
smb: \> quit;
It will be necessary to enable SMB3 to successfully connect with forced encryption
where it is supported on Windows. If you attempt forced encryption without
enabling SMB3, you might see an error similar to the following:

$ smbclient -e //smb3enc.somecompany.com/shush -U nt_username -W dom

Enter DOM\NT_USERNAME's password:

 Domain=[DOM]
 OS=[Windows Server 2012 R2 Standard 9600]
 Server=[Windows Server 2012 R2 Standard 6.3]

Encryption required and server that doesn't support UNIX extensions - failing
connect

Notice above that the OS and Server entries are populated, and there is a mention of the (NT1) UNIX extensions—this is a hint that the connection was made over SMB1. Recall that SMB3 transfers blanked out these entries.

Be especially aware that only Samba version 4.1 enabled SMB2 and SMB3 in the smbclient utility. Even though Samba 3.6 fully supported SMB2 in the server software, the client could not use it until the 4.1 release:


Jeremy Allison 2013-08-20 18:19:11 UTC

One more thing in support of this patchset for 4.1.0...

I really want to enable -e encryption for SMB3 connections from [our] client
tools. In the current climate the only rational response is [to] encrypt
everything. Let's make that possible for our users!

Jeremy.

Boosting the allowed protocol within a capable smbclient enables this behavior. With smbclient, the Windows server can even run SMB1 concurrently with the encrypted SMB3 session (a feature that is beyond the capabilities of any existing Windows client):


$ smbclient -e //smb3enc.somecompany.com/shush -U nt_username -W dom -mSMB3

Enter DOM\NT_USERNAME's password:
Domain=[DOM] OS=[] Server=[]
smb: \> quit

If smbclient -e refuses to connect to a server holding sensitive data despite a thorough exercise of available protocols, then castigate the administrator until the protocols are secured. This is particularly important if the transfers involve the public internet.

Conclusion

Some might assert that NFS under UNIX is also a clear-text protocol with the same security weaknesses as SMB. While this is very true, NFS is usually enabled by knowledgeable administrators between servers in a data center, and similarly to SMB, there are procedures to wrap it in TLS. However, SMB is used by non-administrators outside data centers over (corporate) networks that are not as physically well defended. The users who access SMB likely also have far less technical understanding of the risk to their data. The lack of any data security discussion or warnings in the Microsoft tools puts users at needless risk.

What is particularly aggravating is that Samba solved this problem in 2008 with its encryption extensions to NT1, which should have appeared in XP. Their absence is easily explained as an example of "not invented here", which is unreasonable behavior from an operating system vendor.

There are more powerful tools to manipulate SMB—the Linux kernel especially can mount a Windows share as a native network filesystem with the historic "smbmount" utility, and new implementations can be found in SMBNetFS and FuseSMB. However, as the protocol is controlled by a corporation that does not accept feedback or contributions from the user community, the more basic question is should SMB be encouraged to proliferate?

Perhaps more user-friendly SMB tools should be greeted with minimal enthusiasm for these reasons.

Disclaimer: the opinions expressed here are those of the author and do not necessarily reflect the position of Linux Journal.

______________________

Charles Fisher has an electrical engineering degree from the University of Iowa and works as a systems and database administrator for a Fortune 500 mining and manufacturing corporation.