Skip to content
Naked Security Naked Security

Samba update patches plaintext password plundering problem

When Microsoft itself says STOP USING X, where X is one of its own protocols... we think you should listen.

If you use the venerable Samba open source tool anywhere on your network, you’ll want to read up on the latest update, version 4.15.2.

Samba is the closest pronounceable word to SMB that Andrew Tridgell, who created the project back in the 1990s, could come up with.

SMB, short for Server Message Block is (or, more precisely, used to be) the general name for Microsoft’s once-proprietary networking protocol, inherited from IBM.

Tridge, as Dr Andrew Tridgell OAM is better known, wanted a way for his Linux computers to be able to join Windows networks, without which the job of exchanging data between Windows and Unix networks required a bunch of messy workarounds.

(There weren’t even USB drives in those days to help with getting data across an airgap – and a typical floppy disk could hold just 1.44MB or even less. Plus, networks were supposed to connect computers, not to segregate them.)

SMB turned into CIFS

Microsoft eventually allowed SMB to become an open standard, which you may know as CIFS, short for Common Internet File System, but the name Samba stuck for the open source implementation.

As you can imagine, SMB, and therefore CIFS, and therefore Samba, have evolved enormously over the years, and some early aspects of SMB have been retired, mainly for security reasons.

More precisely, they’ve been junked by default by everyone, including Microsoft, for insecurity reasons, namely that they were designed and first coded long before we became as serious about cybersecurity as we are today, or at least before cybersecurity became something we are rightly expected to take seriously whether we want to or not.

Microsoft itself notably published an article back in 2019 with the unequivocal title of Stop using SMB1, the first version of the file sharing protocol.

The SMB2 and SMB3 flavours of the protocol are not only much faster and more scalable, but also get rid of a bunch of insecure operating “features” permitted by the ancient SMB1.

In fact, right back in 2017, Microsoft stopped installing SMB1 support by default in Windows 10 v1709 and Windows Server v1709.

If you desperately need SMB1 for legacy reasons (and if you do, why not use this article as the impetus to figure out how to get rid of it at last?), you can add it as a Windows component later on, but by default, it’s not installed and you therefore cannot turn it on, whether by accident or design.

Beware downgrade attacks

One significant reason for making sure you don’t have SMB1 is that it’s vulnerable to manipulator-in-the-middle (MiTM) and downgrade attacks.

That’s where someone monitors the SMB1 traffic on your network, and replies to new users on your network to say, “Oh, really sorry, we’re very old fashioned here. Please don’t send encrypted passwords to log in, use plaintext passwords instead.”

Even if your clients and your servers don’t normally support SMB1, a rogue reply of this sort can trick an otherwise secure client (one that hasn’t been instructed never to comply with requests of this sort) into communicating insecurely…

…and thus allow the attackers to sniff out the plaintext password for later.

Of course, once the interlopers know your password, they no longer need to bother with SMB1 at all.

They can use the now-purloined password to login themselves using SMB2, and thereby connect uncontroverially, without raising any anomalies in your security logs.

Well, one of the bugs fixed in Samba 4.15.2 is dubbed CVE-2016-2124, and it’s described as follows:

An attacker can downgrade a negotiated SMB1 client connection and its capabitilities. […] The attacker is able to get the plaintext password sent over the wire even if Kerberos authentication was required.

Before you blame Samba

Before you blame Samba for having had this bug, however, stop to think that you shouldn’t still be using SMB1 at all, and that Samba, like Windows, doesn’t enable it by default.

So you would need a very backward-looking and unusual smb.conf file (Samba’s configuration files for clients and servers) for this bug to have been exploitable in the first place.

In particular, the Samba team note that you would need all of these Samba options set at the same time:

    client NTLMv2 auth = no
    client lanman auth = yes
    client plaintext auth = yes
    client min protocol = NT1 # or lower

The defaults (if you don’t have any entries with these names in your /etc/samba/smb.conf file) are all different, as follows:

  client NTLMv2 auth = yes
  client lanman auth = no
  client plaintext auth = no
  client min protocol = SMB2_02

Notably, plaintext authentication is suppressed by default, meaning that Samba clients won’t generate sniffable network packets containing plaintext passwords in the first place.

What to do?

  • Stop using SMB1 anywhere. On Windows, uninstall the SMB1 component from Windows computers altogether. For Samba, consider adding an explicit client plaintext auth = no entry to your configuration file to make your intentions clear.
  • Upgrade to Samba 4.15.2. The patches fix a bunch of other CVE-numbered bugs as well. If you are running earlier but still-supported Samba versions, the exact version numbers you want are 4.14.10 or 4.13.14 or later.
  • Plan to review all your authentication, password hashing and protocol settings regularly. Whether it’s deprecated ciphers such as RC4, withdrawn digest algorithms like MD5, dangerous password hashing functions such as LANMAN, or unwanted protocols such as SMB1, don’t simply assume they’ve been removed from your ecosystem. Make a point of checking as a matter of routine.


Thanks Paul. Very useful!

Are there any currently supported versions of Windows Server which have SMB v1 installed by default?




I am not a Windows sysadmin (phew :-), so I can’t give you an answer from personal experience, but my own inference from the article I linked to above is that SMB1 was installed by default until Windows Server 1709 came out:

That’s based on the wording “Since Windows 10 Fall Creators Update [1709] and Windows Server, version 1709 (RS3), the Server Message Block version 1 (SMBv1) network protocol is no longer installed by default. It was superseded by SMBv2 and later protocols starting in 2007. Microsoft publicly deprecated the SMBv1 protocol in 2014.”

The fact that the article explicitly says that SMB1 “is no longer installed by default” implies that before that date is was installed automatically unless you took steps to prevent it. (As far as I know, the version number 1709 is Y2K-non-compliant shorthand for “September 2017”, which aligns roughly with the season “fall” in Redmond, thus Fall Creators Edition for the non-server version.)


OK, thanks Paul.
I guess I’ll check manually, just to be safe.


There are some PowerShell scriptage hints in the Microsoft article I mentioned above for discovering not only if you have it, but also if you need it (in case anyone is worried that you might “break” something, even though it’s their legacy system that’s most likely to break something, i.e. the entire network).


I just went through all my W2012R2 machines. Every single one of them had SMB1 by default. Some quick auditing showed the only thing using it was an old monitoring service/application, and that was just a scanning application more less, so I was able to disable SMB1 by removing the “feature.” No damage so far except a reboot is required.


Dear Readers, Since this well written article specifically refers to the open-source implemented solution, you may discover if the SAMBA version IS or IS NOT enabled on CENTOS/RHEL/ROCKY by executing the following command using the CLI:

smbclient -L localhost -N

SMB1 disabled — no workgroup available


That doesn’t seem to work unless you have a local Samba server running for the smbclient program to initiate a connection to. I got a “Connection to localhost failed” before I got as far as any messages about SMB1 being enabled or not.

A better bet might be to use “testparm -v” (or “testparm -v /path/to/config.file” if the configuration is in a non-standard location), which shows *all* the parameters, including defaults (a long list!) that the samba suite of programs will use when executed.

You can capture (or “less”) the output and look for the relevant settings. My system comes out like this, adding “-s” for “no stopping” (no press enter prompts during the listing):

$ testparm -sv | egrep -i ‘client (ntlm|lanman|min prot|plain)’
[. . .]
client lanman auth = No
client min protocol = SMB2_02
client NTLMv2 auth = Yes
client plaintext auth = No


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!