While Remote Desktop Protocol (RDP) is a convenient and efficient way to access remote systems, if it is not properly administered, it can be vulnerable to some attacks such as Man-In-The-Middle (MITM) attacks caused by using the Trust on First Use (TOFU) model. In this blog post, we’ll discuss why RDP TOFU is a bad security model and why organizations should use SSL certificates instead.
The Trust on First Use (TOFU) model is a security model that is used in some protocols, including RDP. In the TOFU model, the user accepts the identity of the remote system (usually a self-signed certificate) the first time they connect to it. After the first connection, the user’s system caches the identity of the remote system, and the user doesn’t need to manually verify the identity of the remote system again in subsequent connections.
The RDP TOFU model has several security flaws that make it a bad choice for secure remote access. The first and most critical flaw is that the user has no way of verifying the identity of the remote system the first time they connect to it. This leaves the user vulnerable to man-in-the-middle attacks. In an MITM attack, an attacker intercepts the connection between the user’s system and the remote system by impersonating the remote server, tricking the user into accepting the attacker’s identity as the remote system’s identity.
These types of attacks are generally used to get the user’s identity (steal their passwords, or even existing tokens), or to steal sensitive information that the user uploads to the endpoint thinking that it is the real endpoint. In addition, the attacker can install a backdoor malware on the user’s system, allowing the attacker to access the user’s system at any time in the future.
Also, let’s be honest: no one actually reads the TOFU warning, we all blindly click accept. (For example, did you notice that in the image above the certificate DNS name, did not match the IP address we were connecting to?). The ease and commonality of glossing over the TOFU warning is the other critical flaw of the TOFU model.
RDP has been around for over 25 years, so why is this becoming a bigger problem instead of going away? There are two overarching reasons:
1) Back when it first came around, most RDP was done under the same network that was protected by a strong firewall, making it very hard for an attacker to perform a Man-In-The-Middle attack since they would physically have to be in the same network as the victim.
2) The second reason is Microsoft’s “solution” to the problem. The way Microsoft solved this problem was by enabling organizations to push RDP certificates to domain joined machines through Group Policy Object (GPOs), making it easy to require all domain joined machines to have trusted certificates for their RDP connections; however, with the move to the cloud, many organizations are moving to a domainless architecture, meaning that we must find a new way to issue certificates for these domainless machines.
As with many other cybersecurity problems, the solution is simple: PKI. Unfortunately, as aforementioned, it gets more complicated when the devices are not domain joined. To solve this problem, there are two possible solutions:
1) Using win-acme to create Remote Desktop Services (RDS) certificates. If you are using ADCS, your CA doesn’t support the ACME protocol; however, you can use EZCA’s ACME for ADCS connector or create your own EZCA CA with ACME support.
2) If you do not want to host your own ACME server, you can do it fully serverless using EZCA’s Certificate client, an open-source command line tool that enables automatic certificate rotation by using scheduled tasks and EZCA’s APIs.
If you would like to learn more or talk to a PKI expert about automating your SSL distribution in Azure, you can schedule a call with an ex-Microsoft PKI expert for FREE! We are here to help you on your passwordless journey, and ensure that your PKI is set up properly and securely.
