Microsoft Will Disable WannaCry Attack Vector SMBv1 Starting This Fall (bleepingcomputer.com)

An anonymous reader writes: Starting this fall, with the public launch of the next major Windows 10 update — codenamed Redstone 3 -- Microsoft plans to disable SMBv1 in most versions of the Windows operating systems. SMBv1 is a three-decades-old file sharing protocol that Microsoft has continued to ship "enabled by default" with all Windows OS versions.

The protocol got a lot of attention recently as it was the main infection vector for the WannaCry ransomware. Microsoft officially confirmed Tuesday that it will not ship SMBv1 with the Fall Creators Update. This change will affect only users performing clean installs, and will not be shipped as an update. This means Microsoft decision will not affect existing Windows installations, where SMBv1 might be part of a critical system.

Comments

Microsoft kills what made it great

[klingens]

The old Microsoft was backwards compatible to old software. Yes it was hard, yes it meant to support shitty old protocols like SMB v1, but they did it, and lots of stuff worked, just worked together, Microsoft code that actually worked!

When they disable SMB v1, one cannot put XP or anything before it in the same network as a current Windows to share files. E.g. a XP VM for some old scanner or printer that you can still use via VM and the current host OS can access.

Re: Microsoft kills what made it great

[Brockmire]

If the manufacturer didn't support the scanner, why should Microsoft? Do you know what "few" means? If Linux had your scanner driver, why didn't you switch a decade earlier?

Re:Microsoft kills what made it great

[Bert64]

SCSI scanners actually use a standard protocol and shouldn't need drivers...

Re: Microsoft kills what made it great

[dougdonovan]

msft will get to it when they get to it. its been this way for 35 years.

Problem is not the age of the protocol

[140Mandak262Jamuna]

30 year old protocols are not ipso facto bad.

What is bad is not upgrading the security of a protocol that is ON by default for 30 years.

Let us take something equally ancient on the unix side, like the Xwindows. Is it on by default in linux? Does it suck as much as SMBv1 in terms of security? What kind of security enhancements have gone into each protocol over these three decades?

I don't know which one is better, but that will give us a sense of how much blame to heap on Microsoft.

Re:Problem is not the age of the protocol

[chipschap]

30 year old protocols are not ipso facto bad.

What is bad is not upgrading the security of a protocol that is ON by default for 30 years.

Let us take something equally ancient on the unix side, like the Xwindows. Is it on by default in linux? Does it suck as much as SMBv1 in terms of security? What kind of security enhancements have gone into each protocol over these three decades?

I don't know which one is better, but that will give us a sense of how much blame to heap on Microsoft.

No. It will give us a sense of how much blame to heap on Xwindows. The fact that there are potentially bad practices going on elsewhere doesn't excuse them.

Re:Problem is not the age of the protocol

[mccalli]

Well, "what kind of security enhancements" covers the existence of SMB v3. It's not surprising that v1 might not be up to modern security - it was written for a different time.

Re:Problem is not the age of the protocol

[chispito]

What is bad is not upgrading the security of a protocol that is ON by default for 30 years.

It HAS been upgraded to version 3. This is not a neglected protocol, this is default backwards compatibility. They are now defaulting to NOT be backwards compatible, due to lack of security.

But I agree that it should have been turned off much sooner.

Is there a reason not to disable it on home

[rsilvergun]

and small networked systems? I honestly haven't paid much attention to the underlining protocols of Windows file sharing. What, if any, advantages are there to having it on by default?

while you are at it

[Anonymous Coward]

disable by default:

* cortana
* search
* xbox
* windows store updates
* non critical updates
* old app profiling
* prefeching the unprefetchable
* apps in suspended mode
* task scheduler
* onedrive
* remote access
* remote admin
* windows media
* shared folders

and the list goes on and on and on

btw do you know you can boot with a linux usb and delete all the windows store/windows apps folders? some registry cleanup after boot but hey no more ghost process in background eating cpu and memory

Re:while you are at it

[Opportunist]

And ENable by default showing file extensions and showing "hidden" files while you're at it!

Old protocols are a huge problem

[Sycraft-fu]

When you take something that wasn't designed with security in mind and try to expand and adapt it, you have a lot of issues. Better to start with something designed for the purpose it is being used from the start.

HTTP is a good example. It was designed as a stateless protocol for transferring text documents with markup. We now rely on it to do stateful transactions for things like shopping carts online and this has lead to tons of security issues since you have to hack on state to a protocol that isn't designed to support it using things like cookies. It would be much more secure had it been designed from the ground up to handle stateful transactions with people.

IP is another great example. There's all kinds of shit in IPv4 that is completely stupid from the perspective of a protocol used on the Internet. Like source routing, where you can specify the routers that a packet must go through, or the fact that you can just claim to be from any IP you want. This is a bad design for a global communications network. However it is that way because IP wasn't designed for a global communications network, it was designed for an ARPA project and it grew. IPv6 fixes a lot of this because it was designed later, around how IP is actually used these days.

Also talking about Xwindows is funny because man you wanna talk security risk, X is a huge. If you have an X server that talks on the network any system on the network can just draw to your local display, and you have no easy way of knowing that it isn't your system. Someone can phish passwords in a very hard to detect way using it. Now of course most distros are smart enough to block remote X using the firewall, and you do something like tunnel it over SSH. However that is a hack, it is putting up barriers around something insecure. If those barriers are bypassed, the insecurity is still there. Better if it were designed secure from the ground up. Then you still put the barriers in place as well so that you aren't relying on any one level of security.

Discontinuing the use of older protocols is a good idea for security, when possible. It isn't always possible, of course, I mean IPv4 is still far and away the most widely used IP spec. But you stop using them when you can (and indeed modern OSes will prefer IPv6 when they have both available).

Re:Old protocols are a huge problem

[WaffleMonster]

When you take something that wasn't designed with security in mind and try to expand and adapt it, you have a lot of issues. Better to start with something designed for the purpose it is being used from the start.

If more things were designed without security we would see much better outcomes.

Security where possible should be treated as an aspect and simply punted to subsystems actually dedicated and capable of providing it rather than continuously (poorly) re-implemented.

HTTP is a good example. It was designed as a stateless protocol for transferring text documents with markup. We now rely on it to do stateful transactions for things like shopping carts online and this has lead to tons of security issues since you have to hack on state to a protocol that isn't designed to support it using things like cookies.

HTTP is the wrong layer for security. People have issues because they insist upon entering credentials into adhoc web forms in plaintext over HTTPS instead of authenticating via secure authentication protocol cryptographically bound to encrypted channels. One continues to offer security even when the user attempts to authenticate with an attacker... the other is the clusterfuck we have today.

IP is another great example. There's all kinds of shit in IPv4 that is completely stupid from the perspective of a protocol used on the Internet.

IPv4 and IPv6 are nothing more than an envelope of information with a with globally unique source and destination address. The design is in every way that matters perfect because it only says what is obviously necessary for communication.

Just because old baggage and routing options exist is quite irrelevant if they are effectively disabled and not actually an issue/used in the real world.

Like source routing, where you can specify the routers that a packet must go through,

It's not so much a bad design as it is the wrong layer. Specifying where traffic goes is full time job of traffic engineers. The fictional problem which does not actually exist would be the practice of exposing routing decisions to IP... This is not occurring.

or the fact that you can just claim to be from any IP you want. This is a bad design for a global communications network.

I will go to my grave believing this is a feature to be celebrated although attempts to curb ala BCP 38 and crew are also to be celebrated. I believe it is practically impossible and morally perilous to even try to create a trusted global communications network open to everyone. The best humanity can do is make a network that with some predictable regularity delivers information to where it's supposed to go and let people establish their own end to end trust relationships. All known alternatives suck much worse than what we have now.

However it is that way because IP wasn't designed for a global communications network, it was designed for an ARPA project and it grew. IPv6 fixes a lot of this because it was designed later, around how IP is actually used these days.

While there will always be interesting implementation drama IPv6 is the exact same shit in every way that matters as IPv4. The expanded address space adds some interesting new challenges such as local broadcast spam and places slight damper on others such a tractability of global scans and associated exploit campaigns. High level it really is just 96 more bits of address space.

Also talking about Xwindows is funny because man you wanna talk security risk, X is a huge.

X risks hail from spaghetti code.

Now of course most distros are smart enough to block remote X using the firewall, and you do something like tunnel it over SSH. However that is a hack, it is putting up barriers around something insecure.

It seems to me if you want to control acc

Protect vs. WanaCry easily 2 ways

[Anonymous Coward]

From MS - SMB Ports 445/139 (TCP) & 137/138 (UDP) protection via:

Disable SMBv1 on the SERVER, configure the following registry key:

Registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters Registry entry: SMB1

REG_DWORD: 0 = Disabled
REG_DWORD: 1 = Enabled

Default: 1 = Enabled

Enable SMBv2 on the SERVER, configure the following registry key:

Registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters Registry entry: SMB2

REG_DWORD: 0 = Disabled
REG_DWORD: 1 = Enabled

Default: 1 = Enabled

---

Disable SMBv1 on the CLIENT, run the following commands:

sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi

sc.exe config mrxsmb10 start= disabled

Enable SMBv2 & SMBv3 on the CLIENT, run the following commands:

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi

sc.exe config mrxsmb20 start= auto

---

* The above is per https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1,-smbv2,-and-smbv3-in-windows-vista,-windows-server-2008,-windows-7,-windows-server-2008-r2,-windows-8,-and-windows-server-2012/

APK

P.S.=> For a SINGLE 'standalone' non-networked PC (no home network/LAN but TCP/IP connected online) turn off Server & Workstation services.

That shuts off any "handles" (port 445) this thing propogates thru + turn off NetBIOS over TCP/IP in your internet connection & uncheck/disable Client for Microsoft Networks + File and Print Sharing. Port 139 & 445 always pop up issues over time. It also makes your packet trains smaller (no encapsulation of LanMan)

I covered all this 11++ yrs. ago in a security guide I wrote for users with a single system & apparently, its advice STILL STANDS THE "TEST OF TIME" https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22HOW+TO+SECURE+Windows+2000%2FXP%22&btnG=Google+Search&gbv=1/ vs. even today's threats like this one.

This effectively makes this threat a non-issue + saves you CPU cycles/RAM & other I/O wasted on services you don't NEED as a single PC user only... & you don't. They're just wastes with a single PC really. Many services are (covered in guide above based on CIS Tool guidance (who took fixes to their ware from "yours truly" too, no less)) & again, no more encapsulated packet bulk.

AND?

Don't be STUPID & click on attachments in bogus malicious emails this thing propogates thru also (Chrome/Opera/Webkit users - BEWARE of the ShellControlFile issue that just popped up (.scf file) noted here-> http://www.theregister.co.uk/2017/05/17/chrome_on_windows_has_credential_theft_bug/ ) ... apk

How to disable SMBv1 ..

[najajomo]

At least us Windows users have a modern GUI interface to play with instead of all those text config files under Linux.

Re:How to disable SMBv1 ..

[chipschap]

Give me the text config files any day. Easy to edit, easy to do version control, easy to diff, etc. Easy to add comments, for that matter. No mouse needed, just the keyboard. Fast and accurate.

GUIs are nice for casual administration (if there is such a thing) but to do any sort of heavy lifting, text files are efficient and manageable.