Windows Remote Desktop Protocol contains a login backdoor Microsoft refuses to fix

[yannus]

There were multiple editions of Windows NT 4.0 and the release of RDP was not associated with the first editions of NT. The author only claimed that it came out during the NT 4.0 era, not that NT was released in 1998. It was its own operating system named Windows NT 4.0 Terminal Server Edition, and that came out in 1998: https://en.wikipedia.org/wiki/Remote_Desktop_Services

I get your point but the way it's said is still wrong. The text says "an early 32-bit operating system released in 1998." Not RDP was released in 1998.

 

[Au Contraire]

"According to Microsoft, the behavior is a design decision meant to "ensure that at least one user account always has the ability to log in no matter how long a system has been offline.""

The GOD Machine (Graphic Omniscient Device) used a similar design flaw in a 1972 book "When HARLIE Was One", author David Gerrold. If you haven't read it, you should.

Then we had the Terminator movies beginning in 1984, followed by 2008's "Terminator: The Sarah Connor Chronicles", where SkyNet came into being. Funny, that; I distinctly remember the name "SkyNet" being used in the early '80s when the Chaos Computer Club had its' first meeting.

It's strange but not unexpected that this deliberately-designed-into-Windows tool is still unpatched. Just think, every Windows machine everywhere is just a node on a huge network.

Who does that benefit?

 

[jam4t]

If it breaks backward compat then why not allow the customer to choose that with a newer version of RDP. This way the user can choose to use either the old non-secure way or the new secure way. They understand what will happen if a machine loses sync access with the new way and for them it might be a better solution. This is far better than keeping a single method available to everyone that is insecure.

Also on my Windows 10 machine I can turn off the RDP service using Settings->System->Remote Desktop Access->Enable Remote Desktop->Off, which is obviously only a solution for machine that dont require RDP, but if you dont RDP to your own machine, then better to disable.

 

[Ben Myers]

While I do understand your comment here, this is not a good article to make this comment on. RDP is leaps and bounds ahead of any alternative solution in terms of it just generally working no matter how good or bad a network connection may be.

Linux users still relying on xorg and x11 is like driving a Ford Model T on the autobahn and wondering why people aren't taking them seriously. Couple that with the fact that xrdp is unstable on non-ideal network connections and you have even more reason to appreciate just how good RDP truly is.

Yes, but. There are free secure alternatives to provide remote acess.

 

[Ben Myers]

What a shocker. Microsoft being lazy about security and not following established standards of operating procedure. Incompetent gomers.

Insecure RDP does follow a pattern, doesn't it? Hey, app and OS security is hard and unglamorous work. It's much more fun for Microsoft to develop ever-changing user interfaces with every Windows release, just to keep us on our toes and let us know who is in charge.

 

[Ben Myers]

Just remember MS stands for Marketing Stuff not More Security.
They have always and will always be an insecure OS/ecosystem. They are great at marketing... That's all they are. Reroll software every few years by moving menu items around and changing the numbers on the version. Marketing 101.
I don't understand how people would think a monopoly would provide good security.

So we are all screwed until there is a paradigm shift to lure people away from Windows.

 

[LimyG]

Glad I've never used it. Have it blocked at Group Policy level and firewall and settings. Same goes for Remote Assistance. Even Peer sharing I block at Group Policy level as well as settings.

Never did trust MS Remote. Many patches are for Remote - something I noticed years ago which was why I effectively got rid of it.

But this I didn't know about. It's almost so bad that it's hard to believe. Seriously WTF is wrong with you M.S.?

 

[LimyG]

If it breaks backward compat then why not allow the customer to choose that with a newer version of RDP. This way the user can choose to use either the old non-secure way or the new secure way. They understand what will happen if a machine loses sync access with the new way and for them it might be a better solution. This is far better than keeping a single method available to everyone that is insecure.

Also on my Windows 10 machine I can turn off the RDP service using Settings->System->Remote Desktop Access->Enable Remote Desktop->Off, which is obviously only a solution for machine that dont require RDP, but if you dont RDP to your own machine, then better to disable.

I mean't to quote your post in mine above. Just to say to be really sure (or paranoid, but this is MS) Disabling it in settings as you have done should certainly be enough. But I don't trust anything this company does, so switching it off in Group Policy leaves the whole section in the control panel showing the same as you with it disabled W10, except it's greyed out and cannot be changed.

 

[Raytrace3D]

Another reason to call Microsoft on their PR stunt BS about prioritizing security first.


Maybe for a local setup this isn't much of an issue. What about cloud environments? Shared workstations? I can see the headline now: "Fired employee caused data breach even after their password was revoked - company tells the court that Microsoft should be liable". After that happens I'm sure Microsoft would change their tune.

On the bright side, this hasn't happened yet (to my knowledge), so maybe the risk is overstated a bit much. But it isn't good practice by Microsoft. Sometimes breaking compatibility is the best thing to do. But, half of Microsoft's fortune is built on being compatible with legacy apps, otherwise it's unlikely Windows, Office, and related applications would have had such penetration into the enterprise market for so long.

I see what you're saying here, but if you revoke someone's password, surely you would also remove their VPN tunnel access and/or IP from the firewall/WAF? I guess it's possible that could be overlooked if you're dealing with sketchy IT people and poor documentation. I'm just use to working on PCI compliant equipment and documentation trails that involve frequent auditing.

 

[onebignerd]

How many of those things can you pull out of Windows without breaking other things? MS long ago laid off its competent developers and filled the positions with cheap 18 month contractors. They cant even change the 15 character limit for PC names without breaking domain functions.

They are uninstalled through "Turn Windows features on or off" in control panel or disabled, none of them are required for Windows 10/11 to run. Many of the features I listed are uninstalled by default in "Turn Windows features on or off", PowerShell has been a separate program from Windows 10/11 since 2016 with the introduction of PowerCore. PowerShell 5 is still integrated by default into Windows 11.

If I was on a domain I may run into some network compatibility problems with my configuration. "Simple TCP\IP services" and "Telnet Client" go back to Unix and the early days of the Internet, long before Windows or Linux. Learning what can safely be disabled or uninstalled is a simple Google search, not any great mystery or rocket science.

 

[human7]

This is actually by design, the default behaviour is to cache windows credentials onto the client pc whom you are taking remote access from.
My IT admins know about this default behaviour and they usually have 2 options 1) if they control the client end via domain server, enforce disabling credentials caching on the client pc, that means Domain server will always be able to dictate to the client to never store RDP credentials for any machine 2) if the server is being exposed to clients/endpoints which are outside the domain server control then force always require password login from server side remote access GPO policy

This explains why my company has the same policy in place. I remember setting up a registry edit on the task scheduler so that I could save RDP passwords. When I first login for the day, their group policy was in place and I had to enter my creds, but if I waited long enough for my regedit schedule to happen (since we had only temporary admin capabilities that was logged on our PCs, so I didn't do it on demand), then I could login with my saved password.

Though, the old credentials never worked after a password change, so maybe password changes are different from revocations. In any case, they changed how they deploy their policies and my regedit stopped working, I didn't bother to chase it since I figure the convenience wasn't worth breaking policy over.

 

[human7]

I see what you're saying here, but if you revoke someone's password, surely you would also remove their VPN tunnel access and/or IP from the firewall/WAF? I guess it's possible that could be overlooked if you're dealing with sketchy IT people and poor documentation. I'm just use to working on PCI compliant equipment and documentation trails that involve frequent auditing.

Sure, but I could think of environments where the RDP isn't behind a VPN tunnel, maybe a small business configuration. Not best practice, but the point is that one shouldn't have to rely on network policies for password policies to work. I guess that's why we have defense in depth.

 

[Raytrace3D]

Sure, but I could think of environments where the RDP isn't behind a VPN tunnel, maybe a small business configuration. Not best practice, but the point is that one shouldn't have to rely on network policies for password policies to work. I guess that's why we have defense in depth.

That's very true. Good point.