5

An up-to-date Windows 10 client is connecting to a Windows 10 RDP host which is stuck at 1511 (host can't be updated and 1511 is out of support for receiving patches such as the CVE-2018-0886 mitigation).

What exactly is the exposure going over public internet? Is there another way to mitigate the exposure other than installing a software patch?

Specifically: my understanding is that CVE-2018-0886 requires a man-in-the-middle setup to initiate an attack. If the client and host are both connected to trusted providers, does it still leave an opportunity for a MITM (intermediate nodes between the providers)?

Also: when initiating an RDP connection, there is often a prompt to accept a certificate (as shown in this question), and it seems to re-appear from time to time between the same pair of client and host. This suggests to me that the RDP host is generating and periodically re-generating a self-signed certificate, which seems to me to be the point at which a MITM can insert itself. Is there any procedure by which the host can generate a long-lived certificate (even if self-signed) which can be transferred to a client (by secure connection) so that the trust relationship is maintained (no prompt to trust a self-signed cert over a questionable connection)? And, in doing this, does it not mitigate the CVE-2018-0886 vulnerability without having to do any patching?

Zenilogix
  • 171
  • 3
  • Some interesting links: 1. Blog with [short video](https://blog.preempt.com/security-advisory-credssp). 2. More [detailed blog](https://blog.preempt.com/how-we-exploited-the-authentication-in-ms-rdp). 3. [16 page white paper](https://www.preempt.com/wp-content/uploads/White_paper_CredSSP.pdf). 4. [41min long video from BH Asia 2018](https://www.youtube.com/watch?v=R9W-8oKHheI). – StackzOfZtuff Jun 19 '18 at 10:58
  • NAA, but you could try a service like this: https://0patch.com/ – Conor Mancone Aug 13 '19 at 21:11
  • This seems like an XY problem. You're asking "how do I fix the fact that my server is unsafe, without patching it", but the question that you actually need to have answered is "how do I fix the fact that I can't patch my server". – Joseph Sible-Reinstate Monica Aug 14 '19 at 00:36

2 Answers2

1

Require the client to log into a VPN before connecting to the server. Expose the RDP port only to hosts connected through the VPN.

This will protect you not only from CVE-2018-0886 but also from other RDP vulnerabilities, such as CVE-2019-0708 (BlueKeep) and those that will continue appearing in the future, if no malicious actor is able to get into the VPN.

Please note this is a big if. Even the computer from which the most trusted user might get compromised, you should really require a VPN and patch the vulnerabilities. But missing the later one, at least you should implement the former.

Ángel
  • 17,578
  • 3
  • 25
  • 60
0

Certs aren't going to save you. The only mitigation I'm aware of are the patches.

Allow me to quote from the folks who discovered this CVE: https://blog.preempt.com/how-we-exploited-the-authentication-in-ms-rdp

Exploiting the NTLM relay vulnerability was possible because of the way RDP is implemented. Let's take a look at the process:

  1. Negotiation over capabilities (Usually CredSSP is chosen)
  2. TLS is established
  3. Network Layer Authentication (NLA) is carried out using CredSSP
  4. The client verifies the certificate, displaying warning if needed

Credentials are sent in step 3 listed above, and the cert is verified in step 4. Ouch. This means that a certificate-based enforcement is too late - by the time you realize the cert is wrong, you have already sent credentials.

Not sure what's going on with the certificate re-prompt.

Daniel Bungert
  • 361
  • 2
  • 4