smbclient security for Windows Printing and File Transfer

by Charles Fisher

Introduction

Microsoft Windows is usually a presence in most computing environments, and UNIX administrators will likely be forced to use resources in Windows networks from time to time. While many are familiar with the Samba server software, the matching smbclient utility often escapes notice.

The "map network drive" function of Windows relies upon the Server Message Block network protocol that has evolved chiefly within the descendents of NT. The smbclient utility presents an interface reminiscent of FTP that allows file transfer to and from disk directories and printers on an NT server over SMB where sharing is enabled.

In this article, we present connection examples for Windows services, then develop a general script for pushing content to Windows shares. We will discuss when the SMB protocols should be used and, more importantly, when they should not.

Connection Examples

Samba for UNIX is well-known for server software that interoperates with clients on Windows networks. However, it also includes the smbclient program that can manipulate any SMB server. The smbclient program is immediately familiar to those experienced with command-line FTP.

The smbclient program can query SMB servers for a list of visible shares using the -L option:

$ smbclient -L dc.somecompany.com -U nt_username -W nt_domain

Enter nt_username's password:

Domain=[NT_DOMAIN]
OS=[Windows Server 2008 R2 Standard 7601 Service Pack 1]
Server=[Windows Server 2008 R2 Standard 6.1]

     Sharename       Type      Comment
     ---------       ----      -------
     C$              Disk      Default share
     file_stash      Disk     
     Fancy_laser     Printer   Really Expensive
     Cheap_laser     Printer   What a deal!

After cataloging the file and printer shares on a server, we can connect to a specific share and manipulate it. Below are examples of several types of transfers.

$ smbclient //dc.somecompany.com/file_stash -U nt_username -W nt_domain

Enter nt_username's password:

Domain=[NT_DOMAIN]
OS=[Windows Server 2008 R2 Standard 7601 Service Pack 1]
Server=[Windows Server 2008 R2 Standard 6.1]

smb: \> mkdir "smbclient test"
smb: \> cd "smbclient test
smb: \smbclient test\> prompt
smb: \smbclient test\> mput samba*
putting file samba.schema.oc.IBM-DS as
  \smbclient test\samba.schema.oc.IBM-DS
  (955.7 kb/s) (average 955.7 kb/s)
putting file samba.schema.at.IBM-DS as
  \smbclient test\samba.schema.at.IBM-DS
  (3590.1 kb/s) (average 2272.9 kb/s)
putting file samba.schema as
  \smbclient test\samba.schema
  (7454.2 kb/s) (average 4000.1 kb/s)
putting file samba.ldif as
  \smbclient test\samba.ldif
  (1615.9 kb/s) (average 2808.0 kb/s)
putting file samba-schema.IBMSecureWay as
  \smbclient test\samba-schema.IBMSecureWay
  (1023.7 kb/s) (average 2553.1 kb/s)
putting file samba-schema-netscapeds5.x.README as
  \smbclient test\samba-schema-netscapeds5.x.README
  (61.0 kb/s) (average 2336.4 kb/s)
putting file samba-schema-FDS.ldif as
  \smbclient test\samba-schema-FDS.ldif
  (5572.1 kb/s) (average 2709.8 kb/s)
putting file samba-nds.schema as
  \smbclient test\samba-nds.schema
  (247.3 kb/s) (average 862.9 kb/s)

smb: \smbclient test\> dir
  .                                   D        0  Fri Mar  3 13:31:24 2017
  ..                                  D        0  Fri Mar  3 13:31:24 2017
  samba-nds.schema                    A    19754  Fri Mar  3 13:31:24 2017
  samba-schema-FDS.ldif               A    17118  Fri Mar  3 13:31:24 2017
  samba-schema-netscapeds5.x.README      A      125  Fri Mar  3 13:31:24 2017
  samba-schema.IBMSecureWay           A     3145  Fri Mar  3 13:31:24 2017
  samba.ldif                          A    14892  Fri Mar  3 13:31:24 2017
  samba.schema                        A    22900  Fri Mar  3 13:31:24 2017
  samba.schema.at.IBM-DS              A    11029  Fri Mar  3 13:31:24 2017
  samba.schema.oc.IBM-DS              A     2936  Fri Mar  3 13:31:24 2017
 
              708626943 blocks of size 4096. 95072482 blocks available

smb: \smbclient test\> lcd /tmp
smb: \smbclient test\> get samba.schema.oc.IBM-DS
getting file \smbclient test\samba.schema.oc.IBM-DS of size 2936 as
  samba.schema.oc.IBM-DS
  (409.6 KiloBytes/sec) (average 409.6 KiloBytes/sec)

smb: \> help
?              allinfo        altname        archive        backup        
blocksize      cancel         case_sensitive cd             chmod         
chown          close          del            dir            du             
echo           exit           get            getfacl        geteas        
hardlink       help           history        iosize         lcd           
link           lock           lowercase      ls             l             
mask           md             mget           mkdir          more          
mput           newer          notify         open           posix         
posix_encrypt  posix_open     posix_mkdir    posix_rmdir    posix_unlink  
print          prompt         put            pwd            q             
queue          quit           readlink       rd             recurse       
reget          rename         reput          rm             rmdir         
showacls       setea          setmode        scopy          stat           
symlink        tar            tarmode        timeout        translate     
unlock         volume         vuid           wdel           logon         
listconnect    showconnect    tcon           tdis           tid           
logoff         ..             !             
smb: \> quit

A distinctive property of printer shares is that logging in and issuing any type of put will send the file transfer directly to the attached printer. Most commercial laser printers will accept Postscript output, in addition to text files with DOS-style line endings.

There have been several revisions to the SMB protocol over the years. The version 1 protocol was finalized and offered as an internet standard as the "Common Internet File System" (CIFS) in the late 1990s. Many extensions with new features were developed for CIFS by various parties, but Microsoft accepted none of them into the Windows implementation.

Windows Vista marked the first appearance SMB2, a complete rework of the protocol, which consolidated the command set and reduced the number of round trips required for data transfers. Protocol support for SMB2 was experimentally introduced with Samba 3.5 server, and went production with Samba 3.6. Note that smbclient did not receive SMB2 until the 4.1 release.

Windows 8 (and Server 2012) introduced further important improvements with SMB3, which (finally) introduced encryption and high-availability features. Protocol support for SMB3 was introduced with Samba 4.1, where the Samba server and client achieved protocol version parity.

Below is the Samba project's documentation on the various revisions of SMB:

The smbclient program allows a specific protocol version to be locked to a server as the maximum supported revision:

-m|--max-protocol protocol
This allows the user to select the highest SMB protocol level that smbclient will use to connect to the server. By default this is set to NT1, which is the highest available SMB1 protocol. To connect using SMB2 or SMB3 protocol, use the strings SMB2 or SMB3 respectively. Note that to connect to a Windows 2012 server with encrypted transport selecting a max-protocol of SMB3 is required.

The commentary presented upon initial login (Domain, OS, and Server) can change when different protocol revisions are selected (the previous login identified Server 2008 on the same server):

$ smbclient //dc.somecompany.com/file_stash -U nt_username -W nt_domain -mSMB3

Enter nt_username's password:

Domain=[NT_DOMAIN] OS=[] Server=[]

smb: \>

Printer Script

The script below uses a number of shell features to transmit print jobs. It bundles a mechanism for prompting and setting environment variables, prompting for a password without character echo, and using a named pipe (fifo) to transmit both credentials and reformatted text.

#!/bin/sh

function chkv {  # $1:var              $2:default_value    $3:prompt
 [[ -z "$(eval echo \$$1))" ]] && if [[ -z "$2" ]]
                                  then echo -n "$3"; eval read $1
                                  else eval $1=$2; fi;
}
chkv               W_DOM               YOUR_WIN_DOMAIN     ''
chkv               W_SERVER            dc.yourcompany.com  ''
chkv               W_PRINTER           office_laser        ''
chkv               W_USER              ''                  'NT Uname: '

if [[ -z "${W_PASS}" ]]
then echo -n 'NT Pass: '; stty -echo; read W_PASS; stty echo; echo ''; fi

W=$(mktemp -dt W-XXXXXX); mkfifo -m 600 "$W/fifo"

for x
do (echo -e "username=${W_USER}\npassword=${W_PASS}\ndomain=${W_DOM}" > \
    "$W/fifo"; awk 'BEGIN{ORS="\r\n"}; {print}' < "${x}" > "$W/fifo") &

   smbclient "//${W_SERVER}/${W_PRINTER}" -A "$W/fifo" \
             -c "put $W/fifo $(basename ${x}).txt"

done; rm -f "$W/fifo"; rmdir "$W"

Below is an example of a run of the script:

$ export W_USER=$LOGNAME W_SERVER=winserv.foo.com
$ export W_PRINTER=a_laser W_DOM=DFOO

$ ./winprint /etc/passwd /etc/group

NT Pass: 

   Domain=[DFOO] OS=[Windows Server 2008 R2 Standard 7601 Service Pack 1]
                             Server=[Windows Server 2008 R2 Standard 6.1]
   putting file /tmp/W-s14793/fifo as \passwd.txt (130.1 kb/s)
                                          (average 130.1 kb/s)...

A few specific observations about the script:

It would be possible to improve the efficiency of the script by launching smbclient as a "coprocess," authenticating only once, then issuing multiple puts without exiting the client. The Korn shell's long-known coprocess syntax was disregarded in the newly-introduced BASH coprocesses, so such a pursuit of efficiency would require differing syntax depending upon the branch of the Bourne shell tree.

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 (i.e. a print job or file transfer) is transmitted in cleartext 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 cleartext 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 of 2017 with 48.41% of the market. As Windows XP still holds 8.45%, we can say that the majority of the Windows market has chosen cleartext SMB over encryption. The Windows 7 community's refusal to upgrade has the unfortunate side effect of flooding their networks with cleartext transfers.

A workaround exists that uses 3rd-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, then 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 a general user (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 Microsoft to simply replace their 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 file system 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 cleartext 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 of datacenters 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 their 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.