3

IT support guy here (NOT security expert):

I have several clients who currently have at least one legacy appliance that runs a Samba (or something like it) server using SMBv1, which cannot be upgraded to use higher SMB versions. Other than replacing the appliance completely (which in some cases would be quite expensive (e.g. CNC machines)), their only choice is to continue using SMBv1 for now.

If we look at SMBv1 vulnerabilities ONLY, the two security extremes would be:

  1. No SMBv1 enabled on ANY device on the network: MOST secure
  2. SMBv1 enabled on ALL devices on the network: LEAST secure

I would like to understand some "middle ground" options:

  1. If have ONLY the appliance itself (call it APPServer) plugged in and accepting SMBv1 connections, have I introduced a vulnerability to ANY other device on the network? If so, how?

Obviously, if the APPServer is only speaking SMBv1 and it's the ONLY thing speaking SMBv1, it's gonna get pretty lonely, so...

  1. If I now enable SMBv1 (Client-side ONLY) on ONLY one of my Win10 clients so that it can communicate with APPServer, how much worse has my situation gotten? I'm guessing the APPServer could then be compromised if the Win10 Client was infected, but wouldn't everything else on the network be unaffected by SMBv1-related issues? If not, how?

I assume Microsoft separated the ability to disable SMBv1 between client and server on recent Win10 installs because a device accepting SMBv1 connections as a server is inherently more vulnerable than using SMBv1 from the client side. Is this assumption correct??

If so, am I correct in thinking that in scenario 2. above, the only device that is still vulnerable to an SMBv1-based attack is the APPServer?

If my reasoning about this is incorrect, please give a specific example if possible about how the WIN10 SMBv1 client (or ANY other device on the network) could be affected by an SMBv1-based attack.

I should mention that neither the APPServer or my Win10 Client in scenario 2. would be exposed to the public internet.

firepuppy
  • 31
  • 2
  • Is the APPServer exposed to public internet? If so, it could be used as an entry point. – MikeSchem Oct 29 '20 at 22:23
  • No (and I have edited the post to indicate that). Thanks for the comment. – firepuppy Oct 29 '20 at 22:37
  • Great question! Welcome to have you here. Just for your info, salutations such as "Thanks for your help" are frowned upon here, since they don't really provide any information for people answering the question. –  Oct 30 '20 at 11:40
  • @MechMK1 thanks for making it clear ;) – Redoman Apr 29 '21 at 14:12

1 Answers1

1

In general it seems like you've got a good understanding of the attack space. Going to attack each question independently as there are a few here.

Questions

  1. If have ONLY the appliance itself (call it APPServer) plugged in and accepting SMBv1 connections, have I introduced a vulnerability to ANY other device on the network? If so, how?

Not really. It would be a good place to establish persistence. Say there was another vulnerability, the attacker got in, their next move would be to gain access to as many devices as possible so when the original attack vector is squashed, they'd still have access.

  1. If I now enable SMBv1 (Client-side ONLY) on ONLY one of my Win10 clients so that it can communicate with APPServer, how much worse has my situation gotten? I'm guessing the APPServer could then be compromised if the Win10 Client was infected, but wouldn't everything else on the network be unaffected by SMBv1-related issues? If not, how?

No. Any device on the network can infect the APPServer, it doesn't need to use SMBv1 client to do so.

I assume Microsoft separated the ability to disable SMBv1 between client and server on recent Win10 installs because a device accepting SMBv1 connections as a server is inherently more vulnerable than using SMBv1 from the client side. Is this assumption correct??

Yes. That assumption is probably correct, though I'm not aware of MS explicitly saying this.

Publicly Exposed

I know you said that the AppServer is not exposed to the internet, but there always is the potential for the server to be exposed inadvertently or via an exploit on the router/firewall. I've seen some exploits that allow an attacker to add port forwarding rules, to which you could use to point at your AppServer then pivot through the network.

General

All this being said, I'd still never recommend having a SMBv1 server on the network at all, there might be a way to plug it into a SMBv3 server over USB and share or some other protocol.

Good security is not only having a strong wall on the outside but also secured devices inside.

MikeSchem
  • 2,266
  • 1
  • 13
  • 33
  • 1
    I tend to agree here, a "proxy" which accepts only SMBv3 and has a `/30` network with the App Server is definitely a viable approach here. –  Oct 30 '20 at 11:38
  • Yea, an SMBv3 proxy would be a perfect solution here. Haven't heard of any though. – MikeSchem Oct 30 '20 at 16:58
  • 1
    @MikeSchem - this sentence `Say there was another vulnerability, the attacker got in, their next move would be to gain access to as many devices as possible, so [...] they'd still have access` makes some assumptions that I fail to understand: `Another vulnerability, the attacker got it` - where, in the APPServer or some other host? `next move would be to gain access to as many devices` - how exactly? (this "how" is exactly what OP asked). `[...] they'd still have access.` - to which hosts? So could you please rephrase your answer to be a bit less cryptic and make the whole process more clear? – Redoman Apr 29 '21 at 16:34