Update: The “wormable” Win XP/Win7 RDP security hole, BlueKeep, still hasn’t been cracked

Topic

New Reply

Forgive me for joining the Chicken Little crowd a couple of weeks ago and recommending that all of you folks running Windows XP (including Embedded) W
[See the full post at: Update: The “wormable” Win XP/Win7 RDP security hole, BlueKeep, still hasn’t been cracked]

4 users thanked author for this post.

Lori, SueW, jburk07, Elly

Reply | Quote

Replies

I have RDP enabled, and I do RDP to my machines over the internet…. through an SSH tunnel, of course.

I think this will ultimately be another one of those FUD scenarios. Could it be bad? Sure, any exploit/vulnerability is. 99% of people, home, soho, or business, do not have RDP open and accessible from the outside world in their router/NAT/firewall.

In all my years of IT-dom, RDP has been used exclusively on the LAN side. Anything requiring remote access from the WAN side is generally done over VPN, or a 3rd party product (ie LogMeIn).

1 user thanked author for this post.

safir

Reply | Quote

For zero2dash

 

I have RDP enabled and I do RDP tunnel SSH FUD scenarios have RDP IT-Sun RDP

 

MENUDA JERGA DE PALABROS …… .. It’s hard for us to learn instead of abbreviations to put what they mean.

Reply | Quote

In a case like this I believe better safe than sorry. For all we knew an active zero-day exploit might have already been circulating – and I don’t know about you but my schedule could not afford another Wanna-Cry this summer. (I want my vacation!)

On the tin foil hat side of the conversation: people that know are very likely under NDA for a while longer.

~ Group "Weekend" ~

4 users thanked author for this post.

jburk07, woody, Demeter, geekdom

Reply | Quote

Microsoft can avoid even more Wanna-Cry Redux action after 2020 by allowing consumers with old PC/laptop  hardware that will never work properly under windows 10 the option to purchase extended windows 7 security updates until 2023. If Microsoft is already providing that option(Purchase Extended Win 7 security updates until 2023) for the enterprise and volume licensing clients then consumers with old PC/Laptop hardware that are having too many issues moving to windows 10 need that option offered as well.

I will be running windows 7 on any of My laptops that can not be made to work under Linux, WiFi hardware included, as it all must work under Linux or the laptop will stay on Windows 7 even after 2020.

My newest laptop(Not really new as it’s Ivy Bridge generation core i7 based) came factory downgraded to Windows 7 Pro from Windows 8 Pro(Business class laptop that has a windows 8 pro license sticker with OS downgrade rights). So that Laptop is getting  windows 8 and an in place upgrade to windows 8.1 and some third party UI/Shell software that gets that whole TIFKAM nonsense out of my face. So I’m good until 2023 on the Business class laptop.

But I’ll have to use windows 7 after 2020 if any of my other laptops can not fully function under a Linux OS Distro(Linux Mint most likely), internet worms or not, Ill just remove any personal information from any laptop and never use that laptop for any important business, just web surfing with no logging in for any of my laptops that run 7 after its EOL.

Windows 7 is, in fact, the new XP!

3 users thanked author for this post.

TaskForce141, Elly, wdburt1

Reply | Quote

On the flip side, speaking of ancient hardware, on something like a bet between one of my subcontractors and myself . . .

We just installed Windows 10_1903 on a 15 year old tower (after upgrading the drive to a SSD) with zero problems. The install went very well. And the machine feels snappy and is running great for basic use like browsing, email etc. Not sure I would want to install AutoCAD on it though . . . 😀

The SATA interface is revision 2, not 3, which limits the SSD speed cap a bit, but hey — it works!

Previous OS was Vista on this machine.

~ Group "Weekend" ~

4 users thanked author for this post.

TaskForce141, SueW, jburk07, Kirsty

Reply | Quote

Also don’t forget that for this specific RDP vulnerability Microsoft broke their “rule” about support for expired operating systems. They released emergency patches for XP and Server 2003 a few weeks ago. Yes, you have to go get them and manually install them – the Automatic Windows Update backbone for those systems was retired years ago. But they are available.

In case you need them
https://support.microsoft.com/en-us/help/4500705/customer-guidance-for-cve-2019-0708

I have a feeling that if this type of vulnerability is discovered again after the deadline on Jan 14, 2020 – Microsoft might well break their rule again for Windows 7. No promises from them of course, but they have set a precedence not once, but twice to my memory now.

~ Group "Weekend" ~

Reply | Quote

Hey Woody!

I just noticed that a patch for the RDP vuln has been released for Vista/Server 2008 sometime recently. Had not noticed this before – it was added after the initial release for XP/2003/Windows 7. Nor have I seen it reported explicitly recently. (See link in my post above to the KB article and support downloads.)

~ Group "Weekend" ~

3 users thanked author for this post.

TaskForce141, woody, Pim

Reply | Quote

Thank you for posting this. I downloaded the x86 file and found that it still is the original release from May 11th. I compared hash files and saw that the file has not changed. Microsoft has just added that it can also be used for Vista.

3 users thanked author for this post.

TaskForce141, NetDef, woody

Reply | Quote

If ‘experts’ can’t answer your simple question, don’t call them experts. They aren’t. If listeners are disabled or ports are closed, there’s no further mitigation required to combat network vulnerabilities. Or does anyone believe the jukebox will play the favorite song when the fuse has been removed?

Reply | Quote

Well, OK, so I should take the advice of an anonymous poster?

Here’s the rub. It isn’t clear if RDP has to be accessible to the port, in order to get infected. Microsoft worded their advisory carefully.

This vulnerability is pre-authentication and requires no user interaction…

The update addresses the vulnerability by correcting how Remote Desktop Services handles connection requests.

That leaves oceans of wiggle room.

There are two official workarounds – enabling NLA (which doesn’t actually prevent infection, but puts an extra validation step into the sequence), and disabling port 3389 “at the enterprise perimeter firewall.” Disabling the port won’t stop the attack if it gets inside the enterprise perimeter firewall — and many people don’t have enterprise perimeter firewalls anyway.

Reply | Quote

To exploit this vulnerability, an attacker would need to send a specially crafted request to the target systems Remote Desktop Service via RDP.

Says it all. No? Then tell me how the RDP service should take the request if the service port is closed (firewalled)?

Reply | Quote

Nobody is saying anything about how this worm works. If it were my computer, I would patch.

On permanent hiatus {with backup and coffee}
offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender
offline▸ Acer TravelMate P215-52 RAM8GB Win11Pro 22H2.22621.1265 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
online▸ Win11Pro 22H2.22621.1992 x64 i5-9400 RAM16GB HDD Firefox116.0b3 MicrosoftDefender

Reply | Quote

woody wrote:

The update addresses the vulnerability by correcting how Remote Desktop Services handles connection requests.

This seems to indicate that RDP must “handle” a request. Can a service handle connection requests if it’s disabled and the port it uses is blocked? Seems unlikely. If disabled services are still able to function, it trivializes the act of disabling services at all, would it not?

2 users thanked author for this post.

TaskForce141, Cybertooth

Reply | Quote

[Bob99]

Perhaps a few folks on the Windows team (or what passes for the Windows team these days) who are well versed in the security aspect of the OS may have thought it trivial for an exploit to be developed, (in conjunction with this wormable exploit), that would check the status of RDP, and if it found the service disabled would be able to change its startup type to Automatic or Automatic (Delayed start) and then immediately restart the service just like an administrator, thereby nullifying the administrator’s efforts at a mitigation.

If such an exploit is indeed trivial to produce, maybe that’s why nobody who works in cybersecurity (or for Microsoft for that matter) is currently publicly recommending disabling RDP as a mitigation measure.

 

• This reply was modified 5 years, 11 months ago by Bob99.

1 user thanked author for this post.

TaskForce141

Reply | Quote

In order for a request to be handled, the request must be received by the process hosting the listening socket on your computer (eg. Remote Desktop Server, or whatever it is called)

If the service is stopped and disabled, it won’t be handling any requests until someone (or perhaps an update?) reenables it. That being said, RDP is useful do outright disabling it is not desired for many.

Firewall rules can be set to block requests, but unless you’re planning to block all network interfaces (not just the internet), there is still a risk of an attack from one of the “trusted” networks. If you are going to block all the networks, you might as well free up some RAM and CPU by disabling the service.

I haven’t been following this issue, but if the patch to fix the vulnerability had been released (it sounds like it has), then you can expect the vulnerability is now known and will be exploited.

In summary, I recommend patching.

Reply | Quote

…incoming RDP connections is disabled by default in XP SP3.
Move along, nothing to see with XP.

…and regarding the other articles about “one million unpatched computers”.
Meh. I have 15 XP’s here alone. Their assumed figure is way way way too low for my liking.

XP the world.

1 user thanked author for this post.

TaskForce141

Reply | Quote

anonymous wrote:

“one million unpatched computers”.

Windows 7 has still 33.78% of Windows share. That’s ~500 Million PCs. Only 1 Million are vulnerable/unpatched ? Not likely.
Even XP has 1.67% that’s ~15 Million probably most unpatched.

Reply | Quote

RDP host is not included with any Home versions of Windows XP/Vista/7 and is not enabled by default on Pro/Ent/Edu versions.

Reply | Quote

Microsoft is confident that an exploit exists for this vulnerability, and if recent reports are accurate, nearly one million computers connected directly to the internet are still vulnerable to CVE-2019-0708. Many more within corporate networks may also be vulnerable. It only takes one vulnerable computer connected to the internet to provide a potential gateway into these corporate networks, where advanced malware could spread, infecting computers across the enterprise. This scenario could be even worse for those who have not kept their internal systems updated with the latest fixes, as any future malware may also attempt further exploitation of vulnerabilities that have already been fixed.

It’s been only two weeks since the fix was released and there has been no sign of a worm yet. This does not mean that we’re out of the woods. If we look at the events leading up to the start of the WannaCry attacks, they serve to inform the risks of not applying fixes for this vulnerability in a timely manner.

Our recommendation remains the same. We strongly advise that all affected systems should be updated as soon as possible.

It is possible that we won’t see this vulnerability incorporated into malware.

But that’s not the way to bet.

 

EternalBlue Timeline

Almost two months passed between the release of fixes for the EternalBlue vulnerability and when ransomware attacks began. Despite having nearly 60 days to patch their systems, many customers had not.

A significant number of these customers were infected by the ransomware.

 

A Reminder to Update Your Systems to Prevent a Worm
MSRC Team
May 30, 2019

 

2 users thanked author for this post.

woody, NetDef

Reply | Quote

[NetDef]

I hesitate to post this, because I am especially concerned about Microsoft’s statement that this bug is pre-authentication. That’s a wide open statement that could mean anything.

But for those that really don’t want to patch (and I still think everyone should patch this) here are some high level hints.

Disclaimer: there are no guarantees that taking the below mitigation steps will actually protect you.

Windows 7 out of the box, NOT joined to a domain.

1) No RDP Firewall rule exists out of the box until you turn RDP on the first time.

2) If you turned on RDP at any point, you will need to manually find and remove the Windows Firewall rule allowing the RDP protocol, or change it to actively block RDP.

3) Open “Services” and find the following and STOP and DISABLE them: (some of these may not exist, don’t sweat it.)

– “Remote Desktop Configuration”
– “Remote Desktop Services”
– “Remote Desktop Services UserMode Port Redirector”
– (Recommended also) “Remote Registry”

And reboot your system.

~ Group "Weekend" ~

• This reply was modified 5 years, 11 months ago by NetDef.

1 user thanked author for this post.

TaskForce141

Reply | Quote

I’ve deliberately kept the steps above as succinct as possible. If you read it, and don’t understand where to go and what to do – then you are not the intended audience. You should patch immediately.

I’m sorry if that comes across as snobbish or tech-elitist . . honestly not intended that way at all. But the truth is that unless you totally understand where these settings live already, you should not be changing them for this specific purpose.

Patch. The last time a worm-able vulnerability was discovered we did not see the actual threats for almost two months. It’s only been two weeks so far, we are not in the clear.

~ Group "Weekend" ~

3 users thanked author for this post.

woody, SueW, geekdom

Reply | Quote

The problem – as you know well – is that the folks “in the know” haven’t verified absolutely, positively, that this approach will work.

It SHOULD work. But the folks who know aren’t saying anything.

I completely agree – PATCH. Now.

Reply | Quote

A cursory search would have proven this to be false.  At the time of this post, multiple companies had already completed proof of concept and announced it.  I really hope nobody actually paid attention to the advice not to patch.

Reply | Quote

Where was there advice not to patch? 🤔

1 user thanked author for this post.

woody

Reply | Quote

I don’t think I’ve seen ANY advice not to patch.

I’ve been jumping up and down like a madman, encouraging Win XP, Vista and 7 users to get the patch applied. The only question – which is still an open question – is whether turning off RDP in the GUI is sufficient.

At the time of THIS post there is no functioning exploit. Not even a bluescreen exploit that works reliably. On the other hand, there are dozens (if not hundreds) of “really, truly, yes we’ve got it” proof of concept posts on Github. People are actually paying for some of them. None of them works reliably.

The minute there’s a functioning exploit, @Gossithedog (Kevin Beaumont) will be all over it, on Twitter. And the minute I see that, I’ll sound the klaxon here on AskWoody.

1 user thanked author for this post.

Elly

Reply | Quote

https://www.securitynewspaper.com/2019/06/05/new-vulnerability-in-windows-rdp-bluekeep-patch-is-not-working/

As I have not seen any mention of this even though it was back in June. Three questions.

First look at the last line of the Three set process:

• The target user connects to a Windows 10 or Server system via RDP
• The user blocks their session and leaves the device unattended
• The attacker with access to the device can interrupt the user’s connection and access the RDP session without having to authenticate.

In other words to exploit this vulnerability, the attacker must have physical access to the device (computer) . Then the computer will be compromised. As most know if one has physical access to a computer, it can be hacked and not patch or security program on the computer will stop it. So the remote part requires being at the computer in question. Have you read or heard anything about that?

next this:

The later versions of Windows 10 1803 and Windows Server 2019 are those that present this vulnerability, because with the most recent update it changed the handling of the NLA-based Windows RDP sessions so that an unexpected performance can be generated in the session lock, mentions the web application security test specialist.

Notice this vulnerability was caused by an update. If the computer in question was not fully updated, that this vulnerability would not be possible. Right?

Last this part

The company was notified since last April 9th, but responded to the flaw report by mentioning that “this behavior does not meet the criteria established by the Microsoft Security Center for Windows”, so the failure will not be corrected, at least not now.

So did Ms patch this or just say they did. What was the real reason for all the doomsday hype?

 

Reply | Quote

Steve S wrote:

The attacker with access to the device can interrupt the user’s connection and access the RDP session without having to authenticate.

In other words to exploit this vulnerability, the attacker must have physical access to the device (computer) . Then the computer will be compromised.

Access to the device doesn’t need to be physical, it can be remote, i.e. Remote Desktop Protocol access… which has been part of this thread from Woody’s initial blogpost, and the reason for such concern about it.

Sorry if I have misunderstood your assertion that access must be physical – if this was not your intention, please clarify.

1 user thanked author for this post.

NetDef

Reply | Quote

I think you are conflating two distinctly separate and unrelated issues.

One is BlueKeep, which is a remote access vulnerability.

The other is a local attack involving access to the logged in users profile by manipulating network access while attempting to take an existing user session via RDP.

~ Group "Weekend" ~

1 user thanked author for this post.

Kirsty

Reply | Quote

[b]

Steve S wrote:

So did Ms patch this or just say they did.

Microsoft patched Windows XP/Vista/7 for BlueKeep, but this “vulnerability” on Windows 10 is not BlueKeep.

The only common factor is that NLA was recommended as a mitigation for BlueKeep (on XP/Vista/7), and NLA here on Windows 10 provides a lock screen bypass if the network connection can be interrupted due to physical access.

Steve S wrote:

What was the real reason for all the doomsday hype?

BlueKeep on XP/Vista/7 can be exploited remotely. NLA on Windows 10 cannot be exploited remotely (and this “exploit” requires a carelessly screen-locked RDP session and an abandoned workstation).

EDIT: The proper documentation of the latter issue makes no mention of BlueKeep and provides three alternative workarounds (disable automatic reconnection, lock local screen not remote, disconnect unused RDP sessions):
Microsoft Windows RDP can bypass the Windows lock screen

• This reply was modified 5 years, 9 months ago by b.

1 user thanked author for this post.

Kirsty

Reply | Quote

NDA lifted:

https://www.us-cert.gov/ncas/alerts/AA19-168A

Working remote execution proof on Win 2000 (mum about later editions).

I’m going to leak something – more of a reminder really.  When this agency releases information like this, it’s already old news.

~ Group "Weekend" ~

Reply | Quote