SMB3 connections don't keep encryption across DFS redirects

Description

Client command line tools like ‘smbclient’ as well as applications
using ‘libsmbclient’ library have support for requiring
encryption. This is activated by the ‘-e|–encrypt’ command line
option or the smbc_setOptionSmbEncryptionLevel() library call.

By default, only SMB1 is used in order to connect to a server, as the
effective default for “client max protocol” smb.conf option as well
for the “-m|–max-protocol=” command line option is “NT1”.

If the original client connection used encryption, following DFS
redirects to another server should also enforce encryption. This is
important as these redirects are transparent to the application.

In the case where “SMB3”, “SMB3_00”, “SMB3_02”, “SMB3_10” or “SMB3_11”
was used as max protocol and a connection actually made use of the
SMB3 encryption, any redirected connection would lose the requirement
for encryption and also the requirement for signing. That means, a
man in the middle could read and/or alter the content of the
connection.

Patch Availability

A patch addressing this defect has been posted to

https://www.samba.org/samba/security/

Additionally, Samba 4.6.8, 4.5.14 and 4.4.16 have been issued as
security releases to correct the defect. Samba vendors and
administrators running affected versions are advised to upgrade or
apply the patch as soon as possible.

Workaround

Keep the default of “client max protocol = NT1”.

Credits

This vulnerability was discovered and researched by Stefan Metzmacher
of SerNet (https://samba.plus) and the Samba Team
(https://www.samba.org), who also provides the fixes.