Never Connect to RDP Servers Over Untrusted Networks

In this article, we will demonstrate why connecting using the Remote Desktop Protocol (RDP) must be avoided on untrusted networks like in hotels, conferences, or public Wi-Fi. Protecting the connection with a VPN or a Remote Desktop Gateway is the only safe alternative.

We have been working on and studying RDP for a long time. We develop and maintain a comprehensive RDP attack and interception toolkit called PyRDP. By pushing our exploration of the protocol with PyRDP we have come to realize that it is dangerous and irresponsible to use RDP on untrusted networks and we realize that this risk is badly documented on the Web.

RDP Trust Primer

RDP’s remote host authentication model can be compared with HTTPS or SSH. With HTTPS we rely on the browsers to distribute the trust anchors required to validate the individual target sites we visit. The trust anchors, certificate authorities in this case, signed the target sites and so the cryptography is sound. It’s a public key infrastructure or PKI for short.

SSH operates under a “Trust on First Use” model or TOFU where you are presented with the fingerprint of the host the first time you connect to it. You accept that fingerprint and it is saved in your client. If, when connecting later, the server’s host key fingerprint has changed you would be presented with a scary message saying you are at risk.

RDP from the end-user’s perspective exposes an HTTPS-like behavior with certificate warnings. Microsoft would like people to use and rely on PKI but that is not done by default and is too complex for most organizations. Instead, it presents certificate warnings by default because most of the time the server’s certificate is untrusted. Then there is the option “Don’t ask me again for connections to this computer” which, one would think would act like an optional and unclear “Trust when I clicked don’t ask me again” analogous to SSH but that’s not quite that as you will see later.

The Problem

We knew it was possible to capture the Net-NTLMv2 hashes of RDP users for a while. In fact, Responder was the first tool to support it. We implemented the same attack in PyRDP last year. You can read about the technical details in a previous blog post about the attack.

PyRDP Stealing the Net-NTLMv2 Hash of a Victim

Since then, we discovered that the hashed credentials can be stolen before any certificate warnings or errors are displayed. This is even the case if the “Don’t ask me again […]” was clicked on the certificate error.

We reported the problem to Microsoft (case id: 71482), and this is what they told us:

Hello,

 

Engineering has completed their assessment of your case and have ranked it as

 

severity=none, impact=not a vulnerability, resolution=by design

 

Their explanation states the NTLMv2 hash is sent during CredSSP authentication which must occur before any certificate warnings can be displayed

 

As a result, I will be closing this case.

Microsoft basically acknowledges that this is a protocol design mistake and that its engineering is not willing to fix the problem. Note that no alternate secure authentication mechanism was offered. The good old “Won’t fix, as designed” treatment.

Demonstration

Here is a video demo demonstrating the attack:

What Does This Imply?

A hash of your password can be captured by any adversary on the network path to the server. These types of hashes are called NetNTLMv2 hashes and are potentially recoverable by an attacker depending on the password complexity, its presence in public password databases like RockYou2021 (that holds 8 billion passwords) and the resources of the attacker. Given the risks and the fact that this happens in an undetectable fashion (prior to certificate errors) we advise that RDP must not be used on any untrusted networks like public Wi-Fi or over the Internet without additional transport security like a VPN. In some contexts, multi-factor authentication can mitigate that risk if the original password is strong enough.

Closing Thoughts

We are a bit disappointed by Microsoft’s response to the vulnerability report. We realize that preventing the attack is complex. This is a design mistake in a publicly documented protocol with 3rd party implementations. The worst kind of mistake to fix. We are compassionate with their position, but we feel they are sweeping the problems under the rug. Their documentation does not mention any client-side level risks and we are unaware of any public roadmap that would enable later protocol versions to get rid of these problems. This blog post aims to document this RDP flaw in simple language and with a demonstration of the impact.

In an upcoming blog post, we will look at RDP’s certificate verification and how easy it is to trick.