Exploits against Windows 7 to 10 could spread from PC to PC—no user interaction needed.

Share this story

Microsoft is warning of a four new Windows vulnerabilities that are “wormable,” meaning they can be exploited to spread malware from one vulnerable computer to another without any user action in much the way the self-replicating WannaCry and NotPetya outbreaks did in 2017.

In such networks, it’s possible for exploits to ricochet from computer to computer. Leaving NLA on makes it harder for attacks to spread, since attackers must first have network credentials. The growing use of hacking tools such as Mimikatz, however, often enables attackers to surreptitiously obtain the needed credentials.

The race begins

Unlike BlueKeep—which affected only unsupported Windows versions or versions close to being unsupported—the bugs disclosed on Tuesday affect newer versions, specifically Windows 7, 8, and 10 and Server 2008, 2012, 2016, and 2019. That puts a much larger and potentially more sensitive fleet of computers at risk. Microsoft rated the severity of the vulnerabilities as 9.7 and 9.8 out of a possible 10. The company also said the chances of in-the-wild exploitation are “more likely.”

“The vulnerabilities include the latest versions of Windows, not just older versions like in BlueKeep,” independent security researcher Kevin Beaumont told Ars. “There will be a race between organizations to patch systems before people reverse engineer the vulnerability from the patches to learn how to exploit them. My message would be: keep calm and patch.”

Windows machines that have automatic updating enabled should receive the patch within hours if they haven’t already. Installing Tuesday’s patches is the single most effective way to ensure computers and the networks they’re connected to are safe against worms that exploit the newly described vulnerabilities. For people or organizations that can’t update immediately, a good mitigation is to “enable NLA and leave it enabled for all external and internal systems,” Beaumont said in a blog post.

Enabling NLA doesn’t provide an absolute defense against attacks. As noted earlier, attackers who manage to obtain network credentials can still exploit the vulnerabilities to execute code of their choice. Still, turning on NLA significantly increases the requirement, since the exploits can completely bypass the authentication mechanism built into RDS itself.

Harden the RDS

According to a blog post published Tuesday by Director of Incident Response at the Microsoft Security Response Center Simon Pope, Microsoft researchers discovered the vulnerabilities on their own during a security review designed to harden the RDS. The exercise also led to Microsoft finding several less-severe vulnerabilities in RDS or the Remote Desktop Protocol (RDP) that’s used to make RDS work. Pope said there’s no evidence any of the vulnerabilities were known to a third party.

The exercise came three months after the patching of BlueKeep, which was reported to Microsoft by the UK’s National Cyber Security Center. It’s possible—although Pope gave no indication—that the review came in response to that tip from the NCSC.

Some security researchers have speculated the original source of BlueKeep vulnerability report was the Government Communications Headquarters, the UK’s counterpart to the National Security Agency, as part of a vulnerabilities equity process that calls for bugs to be disclosed once their value to national security has diminished.

“So it'll be ironic if the GCHQ VEP killed a RDP bug because it only affect [sic] old boxes but then MS audited all of RDP and killed one of their goto new hotness bugs. (Another good reason not to kill bugs),” Dave Aitel, a former NSA hacker who now heads security firm Immunity wrote on Twitter.

So it'll be ironic if the GCHQ VEP killed a RDP bug because it only affect old boxes but then MS audited all of RDP and killed one of their goto new hotness bugs. (Another good reason not to kill bugs)

Whatever the case, the four wormable bugs disclosed Tuesday represent a threat not just to the Internet but to the health care, shipping, transportation, and other industries that rely on it. Administrators and engineers would do well to devote as much time as necessary to research the vulnerabilities to ensure they aren’t exploited the way WannaCry and NotPetya were two years ago.

In the case of, say, not at all hypothetically, the bunch of RDS terminal servers running business critical software that everyone freaks out about if we patch too aggressively...well, if we shut of RDP we might as well just pull the power as well, for all the good they'll do in that configuration.

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Can we stop with this nonsense?

Systems aren't patched in a timely manner for a number of reasons. Sometimes it's because "the business" doesn't want any downtime during a sensitive part of the year. Other times a vendor contract means you have to wait for *them* to "certify" the patched configuration. Sometimes IT is risk averse due to "the business" shouting at them when a patch actually breaks something.

On servers at least, just go into Remote Desktop (Control Panel, Allow remote Access) and tell it to only 'Allow connections only from computers running Remote Desktop with Network Level Authentication'.

In the case of, say, not at all hypothetically, the bunch of RDS terminal servers running business critical software that everyone freaks out about if we patch too aggressively...well, if we shut of RDP we might as well just pull the power as well, for all the good they'll do in that configuration.

I was thinking more of the home user. If it wasn't for networked printers, your average home user wouldn't use any networking at all other than the internet.

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Patching in the enterprise is usually one of three states:1. Completely Off, or broken in a way to basically be off. Surprisingly common. Can be caused by a faulty WSUS setup; Bad windows update GPOs that are never fixed; 3rd party patching system that exceeds licensing and stops patching random workstations. Servers get forgotten about and reboots don't happen in a scheduled fashion anymore. I've seen servers failed to get patched for YEARS because of this.

2. Microsoft defaults on workstations, Servers on a delayed patch cycle (1-2 weeks at most) with test servers being patched immediately. I believe this is a good sign of a healthy company in terms of patching.

3. Patch cycle on all machines on some sort of staggered roll out due to some perceived need to test the snot out of all patches. I hate this one, because often it's done due to some knucklehead believing that all changes are going to break stuff, including user workstations. This is the one that caused Microsoft to start making all patches cumulative instead of standalone, because it's this group that would never go back and re-approve fixed patches. I've usually seen this situation at a place that was not patching before, and is overly cautious about getting caught up on patching.

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Can we stop with this nonsense?

Systems aren't patched in a timely manner for a number of reasons. Sometimes it's because "the business" doesn't want any downtime during a sensitive part of the year. Other times a vendor contract means you have to wait for *them* to "certify" the patched configuration. Sometimes IT is risk averse due to "the business" shouting at them when a patch actually breaks something.

And at the same time people complain that they cannot disable updates..

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Can we stop with this nonsense?

Systems aren't patched in a timely manner for a number of reasons. Sometimes it's because "the business" doesn't want any downtime during a sensitive part of the year. Other times a vendor contract means you have to wait for *them* to "certify" the patched configuration. Sometimes IT is risk averse due to "the business" shouting at them when a patch actually breaks something.

I'm sure "the business" likes it just as much when not patching something causes it to break, or get broken by an adversary.

"The business" should not be making IT security decisions.

Absolutely, but reality is somewhat different in some organizations. Anyhow, the point was to highlight that "IT can't be bothered" is a lazy, and often inaccurate, simplification of what goes on in the real world.

We should be ok then we are still stuck on wfw 3.11 using novell clients no TCP/IP drivers to keep support of some old software, our internet works via a Novell 4.11 server running Intranetware IPX/IP gateway.

Another unintended consequence of our, "I need it now" mentality. There is no legitimate reason to need remote access to a PC (personal, as individual, computer) 24/7/365. Sure one can be created and rationalized, but really, does one wake in the middle of the night and have to read that file?

It must be nice to work in an 8x5 world where you leave work at work at the end of the day.

I, OTOH, have been on call 24x7 since I had my first.job (which is going on 40 years). Not just because some business run 24 hours a day (and e.g. hotel guests really don't like it when their checkout is delayed) but also because patients appreciate it when their doctors can provide informed, timely care in the ER.

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Can we stop with this nonsense?

Systems aren't patched in a timely manner for a number of reasons. Sometimes it's because "the business" doesn't want any downtime during a sensitive part of the year. Other times a vendor contract means you have to wait for *them* to "certify" the patched configuration. Sometimes IT is risk averse due to "the business" shouting at them when a patch actually breaks something.

I worked as an engineer for a specific enterprise PBX vendor (3rd party, vendor did not really offer support). The platform required at least 1 Windows Server. If you ran Windows patches, there was 90% chance you'd break the PBX. Patches had to be certified by the vendor and they would release a new build for each patch.

So, to run Windows updates, you would also have to run PBX updates, which would also require rebooting every other device in the platform - Call control, T1 and every single phone, which would flash the firmware. Customers got 1 free upgrade per year, meaning the vast majority of our customers servers were patched annually.

Ironically, we had network security vendors as customers. They REALLY hated not being able to run patches.

make it possible to for unauthenticated attackers to execute malicious code by sending a specially crafted message when a protection known as Network Level Authentication is turned off, as many administrators in large organizations often do.

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Can we stop with this nonsense?

Systems aren't patched in a timely manner for a number of reasons. Sometimes it's because "the business" doesn't want any downtime during a sensitive part of the year. Other times a vendor contract means you have to wait for *them* to "certify" the patched configuration. Sometimes IT is risk averse due to "the business" shouting at them when a patch actually breaks something.

The frequency the scenario you developed is so rare that in my entire career I haven't seen it happen, in 20+ years in security as a consultant and vendor including as the vendor selling Nessus. The certification process you are referring to that I have had to audit and overturn in countless engagements to get a sustainable RACI implemented as part of the VM patching routine is often because the contractor makes a lot of money running what is often a pointless regression test and often when investigated to its depth, is found to be little more than a few workstations test patched once a month.

Lets get off the "I need to regression test the OS as if it was completely rewritten" train. Finding customers with 3-6 month patching cycles that results in an intrusion may be very profitable for me but I'm rather tired of that type of engagement. I'd rather it be something less stupid so I can teach the customer security practices relevant to this decade.

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Can we stop with this nonsense?

Systems aren't patched in a timely manner for a number of reasons. Sometimes it's because "the business" doesn't want any downtime during a sensitive part of the year. Other times a vendor contract means you have to wait for *them* to "certify" the patched configuration. Sometimes IT is risk averse due to "the business" shouting at them when a patch actually breaks something.

The frequency the scenario you developed is so rare that in my entire career I haven't seen it happen, in 20+ years in security as a consultant and vendor including as the vendor selling Nessus. The certification process you are referring to that I have had to audit and overturn in countless engagements to get a sustainable RACI implemented as part of the VM patching routine is often because the contractor makes a lot of money running what is often a pointless regression test and often when investigated to its depth, is found to be little more than a few workstations test patched once a month.

Lets get off the "I need to regression test the OS as if it was completely rewritten" train. Finding customers with 3-6 month patching cycles that results in an intrusion may be very profitable for me but I'm rather tired of that type of engagement. I'd rather it be something less stupid so I can teach the customer security practices relevant to this decade.

I mean, you only have to look a few posts above yours for an example. But for the record, I was not referring to Nessus.

Again, the point is that claiming "IT can't be bothered" is not reflective of what goes on in the real world.

Clients don't have to be domain joined nor do servers for it to work. I routinely connect from Linux / BSD and Windows 10 boxes to Windows Servers requiring NLA that are both domain joined and not as well as to Windows 10 desktops with RDP enabled that are also domain joined and not. Works everytime.

make it possible to for unauthenticated attackers to execute malicious code by sending a specially crafted message when a protection known as Network Level Authentication is turned off, as many administrators in large organizations often do.

Dammit, and most PCs at my work have Windows 10 updates completely disabled through registry, because people find them to be too annoying. I won't be safe even if I'm patched myself, right? Dunno how to protect myself in such case.

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Can we stop with this nonsense?

Systems aren't patched in a timely manner for a number of reasons. Sometimes it's because "the business" doesn't want any downtime during a sensitive part of the year. Other times a vendor contract means you have to wait for *them* to "certify" the patched configuration. Sometimes IT is risk averse due to "the business" shouting at them when a patch actually breaks something.

I worked as an engineer for a specific enterprise PBX vendor (3rd party, vendor did not really offer support). The platform required at least 1 Windows Server. If you ran Windows patches, there was 90% chance you'd break the PBX. Patches had to be certified by the vendor and they would release a new build for each patch.

So, to run Windows updates, you would also have to run PBX updates, which would also require rebooting every other device in the platform - Call control, T1 and every single phone, which would flash the firmware. Customers got 1 free upgrade per year, meaning the vast majority of our customers servers were patched annually.

Ironically, we had network security vendors as customers. They REALLY hated not being able to run patches.

Yeap, also dealt with supporting a SIP phone system that would not support you if you had installed a Windows patch they hadn't certified yet. To be fair, they were on the ball about it and usually had stuff certified within a week or 2 of it being released or sometimes sooner, but it's most definitely a thing and the closer you get to "human life" issues (ie: medical gear or "controls" of some sort) the more likely you'll find that requirement.

Now, personally, I don't know why anyone would use a OS like Windows for that level of critical gear when you could use a Linux or BSD and strip it down to absolutely minimal configurations and tailor it to your exact needs, but that's a different discussion.

Dammit, and most PCs at my work have Windows 10 updates completely disabled through registry, because people find them to be too annoying. I won't be safe even if I'm patched myself, right? Dunno how to protect myself in such case.

Your individual machine will be safe from this specific issue, but if your network gets compromised somewhere else then all bets are off.

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Can we stop with this nonsense?

Systems aren't patched in a timely manner for a number of reasons. Sometimes it's because "the business" doesn't want any downtime during a sensitive part of the year. Other times a vendor contract means you have to wait for *them* to "certify" the patched configuration. Sometimes IT is risk averse due to "the business" shouting at them when a patch actually breaks something.

I'm sure "the business" likes it just as much when not patching something causes it to break, or get broken by an adversary.

"The business" should not be making IT security decisions.

"The business" is the part of *the business* that makes the revenue happen to pay the IT dept. So if "The business" has *the business* interrupted because the IT dept updated systems without testing first and nuked some badly supported third party app that's critical to *the business*'s revenue flow, you bet "The business" is going to be a tad cranky about *its* IT dept making any decisions in the future. And I'm sure that no windows update has ever broken anything...

Wait, why are people turning off Network Level Authentication in the first place?

To someone who isn't a professional Windows admin, turning off something with authentication in the name only to find out you're now less secure sounds... well duh?

The big issue I've found is that you can't reset your password if it expired or even if "require password change on next login" is checked for your account if NLA is on and you're connecting via RDP. So, if what you're connecting to hasn't come around with a workaround for that issue then often times they disable NLA on a few boxes to allow people to change passwords. That's the big one. Also, if you have older client software it doesn't always support NLA.

Another unintended consequence of our, "I need it now" mentality. There is no legitimate reason to need remote access to a PC (personal, as individual, computer) 24/7/365. Sure one can be created and rationalized, but really, does one wake in the middle of the night and have to read that file?

Not sure what type of work you've done in the past but you seem to be very unaware of the numerous and varied use cases. From IT support to access from home or field to business and 3rd party applications that are only enabled or licenced to run on that machine. Many workers do not have the benefit of being able to only work in the office during set times and RA is a solution for many of them that need to work remotely during the day or from home.As for not needing it on all the time, that isn't a realistic thing as you don't always know ahead of time when you will need to connect and even if you did, having it on only part of the time does nothing for you because the virus would hit it the second you turn it on if it is active on the network.

Another unintended consequence of our, "I need it now" mentality. There is no legitimate reason to need remote access to a PC (personal, as individual, computer) 24/7/365. Sure one can be created and rationalized, but really, does one wake in the middle of the night and have to read that file?

It must be nice to work in an 8x5 world where you leave work at work at the end of the day.

I, OTOH, have been on call 24x7 since I had my first.job (which is going on 40 years). Not just because some business run 24 hours a day (and e.g. hotel guests really don't like it when their checkout is delayed) but also because patients appreciate it when their doctors can provide informed, timely care in the ER.

Anyone in IT that is not about to become out of date and losing their job, works more than M-F/9-5.

If a solution in your environment eludes you, spend some time in security forums (using anonymous email) asking other admins how they solved this problem and you will eventually find one that fits you budget, skill set, and tech prejudices. I'm truly empathetic to the many people in IT that suffer jobs that are underpaid, under budgeted, over worked, and lack sensible security priorities. Just remember that you are always preparing to be ready for your next job and find ways do what you know will best secure your company, no matter how much you do not like that company.

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Can we stop with this nonsense?

Systems aren't patched in a timely manner for a number of reasons. Sometimes it's because "the business" doesn't want any downtime during a sensitive part of the year. Other times a vendor contract means you have to wait for *them* to "certify" the patched configuration. Sometimes IT is risk averse due to "the business" shouting at them when a patch actually breaks something.

I worked as an engineer for a specific enterprise PBX vendor (3rd party, vendor did not really offer support). The platform required at least 1 Windows Server. If you ran Windows patches, there was 90% chance you'd break the PBX. Patches had to be certified by the vendor and they would release a new build for each patch.

So, to run Windows updates, you would also have to run PBX updates, which would also require rebooting every other device in the platform - Call control, T1 and every single phone, which would flash the firmware. Customers got 1 free upgrade per year, meaning the vast majority of our customers servers were patched annually.

Ironically, we had network security vendors as customers. They REALLY hated not being able to run patches.

Yeap, also dealt with supporting a SIP phone system that would not support you if you had installed a Windows patch they hadn't certified yet. To be fair, they were on the ball about it and usually had stuff certified within a week or 2 of it being released or sometimes sooner, but it's most definitely a thing and the closer you get to "human life" issues (ie: medical gear or "controls" of some sort) the more likely you'll find that requirement.

Now, personally, I don't know why anyone would use a OS like Windows for that level of critical gear when you could use a Linux or BSD and strip it down to absolutely minimal configurations and tailor it to your exact needs, but that's a different discussion.

Understand your point, but that begs the question whether the Linux/bsd updates are tailored as well - or are you saying they don't need updates?

1) If I have RDS disabled will it still be patched? Presumably the code is still there even if nobody but MS is allowed to use it. (Yes, I fully expect that even if RDS is disabled in setttings MS can override that if it wants to.)

2) What about Linux? How do I ensure that RDS or its equivalent is missing from Mint 19?

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

Can we stop with this nonsense?

Systems aren't patched in a timely manner for a number of reasons. Sometimes it's because "the business" doesn't want any downtime during a sensitive part of the year. Other times a vendor contract means you have to wait for *them* to "certify" the patched configuration. Sometimes IT is risk averse due to "the business" shouting at them when a patch actually breaks something.

I worked as an engineer for a specific enterprise PBX vendor (3rd party, vendor did not really offer support). The platform required at least 1 Windows Server. If you ran Windows patches, there was 90% chance you'd break the PBX. Patches had to be certified by the vendor and they would release a new build for each patch.

So, to run Windows updates, you would also have to run PBX updates, which would also require rebooting every other device in the platform - Call control, T1 and every single phone, which would flash the firmware. Customers got 1 free upgrade per year, meaning the vast majority of our customers servers were patched annually.

Ironically, we had network security vendors as customers. They REALLY hated not being able to run patches.

Yeap, also dealt with supporting a SIP phone system that would not support you if you had installed a Windows patch they hadn't certified yet. To be fair, they were on the ball about it and usually had stuff certified within a week or 2 of it being released or sometimes sooner, but it's most definitely a thing and the closer you get to "human life" issues (ie: medical gear or "controls" of some sort) the more likely you'll find that requirement.

Now, personally, I don't know why anyone would use a OS like Windows for that level of critical gear when you could use a Linux or BSD and strip it down to absolutely minimal configurations and tailor it to your exact needs, but that's a different discussion.

There is actually a reason why it was built on Windows - TAPI. Before WebRTC was a thing, the best way to get call-control to an end users desktop would be via TAPI. Granted, that limited fully functional clients to Windows only. Once webRTC became standard, the client was platform independent.

But the PBX vendor was bought out by Mitel a few years ago (and I got before that) so for all I know that's no longer the case.

IT departments: We'll get to it in six months, maybe, if we feel like it. We have to test it against mission critical software from 1998 that could break even though it hasn't yet in 21 years.

I await the stories of networks taken over because IT can't be bothered to update in a timely manner.

With how regularly Microsoft breaks even basic functionality in Windows with patches these days, I can't blame people for testing. Microsoft's QA is basically non-existent these days.

Also, I just ran out and clicked "Check for Updates" (my Win10 1903 machine doesn't use a WSUS server), and it doesn't have anything available for me (yet). MS's crazy "staggered rollout" system (which is part of what passes for their QA now) is annoying when you know there's a security fix you want.

(Yes, I know I can go manually download it from Windows Catalog, but the fact remains that I shouldn't have to jump through that particular hoop.)

And at the same time people complain that they cannot disable updates..

To be fair, it's only Home that can't disable updates (easily without registry hacks). Pro and Enterprise can easily do it via Group Policy. I have my machines set to Notify.

And that's the way it should be. It's the Home user demographic that are the least skilled and least aware of these things. I mean, you and I are on Ars reading and commenting about a potential Worm threat via remote desktop access. Most people have no real idea what that even means. I have no problem with Home enforcing updates.