0

I noticed that my SMB shares from a Samba server no longer appeared in Windows 10 network browsing (network neighborhood) in Windows file explorer. The reason turned out to be that this functionality has originally been relying on SMBv1 to work -- which seems to have been installed and enabled by default as late as Windows 10 1703 -- but has since moved on to use WS-Discovery. Samba doesn't appear to support the latter.

What are the security implications of a SMBv1 client that only uses the protocol to discover SMB network services, without actually making a connection to a server? This blog post lists several vulnerabilities, but I don't know enough about SMB to determine whether they apply only to an SMBv1 client that is connecting/connected to a server, or if it applies even if it just sits there trying to discover servers without trying to connect.

  • I'm not sure the question is on-topic here. You appear to be asking why MS did something. If the question was how we as users/admins could configure it to be more secure, that might be on topic. Can you clarify your question? – schroeder Oct 26 '18 at 14:40
  • @schroeder Thanks, I'll take a look at the guidelines and see if it can be salvaged. – Andreas Oct 26 '18 at 14:41
  • If the question is about "what-if" about the protocol, it's off-topic (and not security related). If you want to know how to use the insecure protocol in the most secure method, then maybe. – schroeder Oct 26 '18 at 14:46
  • This was the point of my answer. The only people who can answer why a feature wasn't carried over to a new version is a question for the company, and more likely, the dev team. It doesn't change the fact that unless SMBv1 cures world hunger, it shouldn't be used regardless of the desired feature is provides, from an InfoSec perspective, which is what this site is specifically for. – thepip3r Oct 26 '18 at 14:57
  • @schroeder I started by removing any mentions of Microsoft or their intentions so that there's no further confusion about whether the question is about the technology, or about mind reading. Will take a closer look at the question guidelines at first opportunity. – Andreas Oct 26 '18 at 15:05
-1

DO NOT USE SMBv1. It's been deprecated for so long that you actually have to manually enable it on Windows to make this work. It's terribly slow, insecure, and exposes that host to exploits that have existed on the Internet for over 2 decades... DO NOT USE IT.

EDIT:

SMBv2 was a complete rewrite of SMBv1. Every reference to higher order SMB "versions" is nothing more than a dialect of SMB2 (e.g. SMB 3.1 is just a dialect of SMB2). As an example of the differences:

  • SMB1 sends one packet per file system command. SMB2 sends multiple commands per packet.

  • SMB1 has over 100 specific commands. SMB2 has like, 12 (that may not be entirely accurate, but the number is very low).

They are essentially different protocols. Don't turn on SMBv1. You're exposing your host to a whole host of vulnerabilities for the sake of a function you could get around by providing a drive mapping to the share.

Final Edit to Address the OP's Edits:

The problem with SMBv1 is SMB Relay Attacks and ultimately the attacker harvesting credentials using it.

Windows provides a way to require digital signing of network communications, specifically related to SMB communications.

Set this policy to enabled for all SMBv1 communications in local policy or group policy: Microsoft network client: Digitally sign communications (always)

This will likely break access to your SAMBA server unless you can configure it to also digitally sign SMBv1 communications.

FWIW, and if I hadn't made it clear, I don't recommend using SMBv1 in light of its inefficiencies and insecurities. The minute you misconfigure this on a single host, you've enabled one of the most commonly exploited vulnerabilities that exist today on a network. Good Luck.

  • 1
    Thank you for your answer. Though I suspect you might have misunderstood the question — I'm interested in why the subset of smbv1 that was needed for service discovery couldn't continue to be used after the transition to v2 – Andreas Oct 26 '18 at 14:24
  • because SMBv2 was a complete rewrite of SMBv1. What I was implying without explicitly saying it is that the core underlying features of SMBv1 relative to SMBv2 are not the same because they are essentially different protocols with the same name and different increment number. – thepip3r Oct 26 '18 at 14:29
  • No, I'm saying the discovery portion was likely ommitted. However, it is not at all locked down. In fact, you can download the entire specification and read about each feature in nauseating detail from MS: msdn.microsoft.com/en-us/library/cc246482.aspx. If you want to know the 'why', you'll have to ask the SMB team. – thepip3r Oct 26 '18 at 14:34
  • I was always assuming the nauseating details were available — hence my question here ;) I.e. I'm not asking someone to go read them, I'm looking for someone who perhaps already has. – Andreas Oct 26 '18 at 14:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.