Blog / Windows ZeroLogon Part Three: Another Patch Coming Right Up…
Last October I wrote two blogs about the Windows ZeroLogon bug. It also did the rounds in the news and was a really, REALLY big deal in the world of computers for a while. To be honest, it’s one of those cyber pests that will probably go down the memory of any IT Security person, due to issue’s sheer scale. You can do a million things right, but mess things up badly enough and people will never forget.
So, why a third blog on this topic, after all this time? After all, Microsoft released a patch to fix the issues, right? Well, yes, that is true; they did. But the nature of the repair required them to make a change in the way Windows behaves with its Authentication Protocol.
The mend came in two parts: The first has already been put in place. It simply patched the flaw found in how Windows communicates a user logon between computers and Domain Controller. The long-term problem is that this communication protocol was created a long, LONG time ago. It was back in the days of NT4 and was never touched, until now.
The way it communicates is not secure; it’s in plain text. This means that while the vulnerability has been patched, it’s still susceptible to potential attacks. This protocol is how a Windows Domain divulges that someone has logged-on between all the various computers. To put it nicely and simply, it’s the backbone of Windows Authentication. Thus, it needs appropriate protection.
Microsoft didn’t implement the full fix right away, because there are a lot of vendors out there that need to integrate with Windows. If they corrected everything all at once, that would break a LOT of things, unless they delayed the patch to give vendors time to create updates. That was thrown out, probably because the bug was being actively exploited.
Hence, on February 9th, Microsoft is going to be releasing the second part of this patch, which is going to irrevocably change the behaviour of any modern Domain Controller, so that it’ll reject any sort of insecure Authentication request. The first part of the adjustment made these petitions an option but didn’t enforce them. Now that’s about to change…
What does this mean? Well, for starters, you won’t be able to connect a computer with an unpatched OS to your Domain. Any old Windows machines that don’t have the patch on them won’t be able to link to the domain. Any external device that tries to authenticate to Windows (NAS Storage, some VPNs, etc.), will stop working, if the vendor hasn’t updated it.
Will anything break for you? That depends on what you’ve got in your network. It would certainly be important to take a look now, while it’s not a problem. If a storage drive suddenly stops working on Feb 10th after the patch, that could be a serious issue. Thus, check for patches and updates beforehand. There’s less than a month before this occurs, so the time to monitor and correct things is running out…
Check your event logs for log ID 5829. That’s the event log for Windows that says it accepted an unsecure logon request. Use it to track the device generating those events, so you can update or reconfigure it for this to no longer happen. After the patch comes, those requests will no longer be accepted, so whatever device is generating them will stop working. So, fix it while there’s no trouble.
As William Shakespeare said in “The Merry Wives of Windsor“: “Better 3 hours too soon, than a minute too late.”
If you have any questions about Windows ZeroLogon, please reach out to your TRINUS Account Manager, for some stress-free IT.
By Kind Courtesy of Your Friendly Neighbourhood Cyber-Man.
