Remote Access Woes: Microsoft Windows Remote Desktop Protocol (RDP)

The Trouble with Remote Access

Remote access protocols are certainly one of the long-standing topics discussed when it comes to information security. Most security practitioners have had to deal with the threats and risks posed by the wide range of protocols used to remotely manage and access systems, including Telnet, SSH, RDP and even third-party providers such as GoToMyPC. Convenience is heavily weighed against security, as users and administrators require access to the systems, yet security in the forms of authentication and encryption seemingly "get in the way." This debate has come up in my career more times than I care to remember. When I first set out to help make systems more secure, one of the first actions I proposed was to remove Telnet from all of my UNIX (Solaris and Linux at the time) systems. Turns out it was a valuable lesson for me as I learned that while technically not so challenging, convincing 25 or more developers that they had to use an SSH client rather than the built-in Telnet utility was the most challenging aspect of that project.

The same debate occurred later in my career when I was tasked with helping the newly-created Windows systems administrators group secure their brand-new Windows domain environment. I had a similar conversation about Microsoft Terminal Services, which uses the RDP (Remote Desktop Protocol). At the time, in the default configuration, an attacker could perform MiTM attacks to obtain the username and password, in addition to logging the keystrokes sent to the systems being managed. Again, technically there was an easy fix (change some settings on the servers, and use a compatible client on the management systems). However, the real challenge was persuading the administrators to make the switch, as they had always just used the default configuration and, by their own account, "nothing bad ever happened." In this case, I had to use a demo and perform an attack, with permission, of course, against an administrator. Once they saw it, the progression to a properly-configured and more secure RDP implementation was underway immediately.

That Was Just the Beginning

The security shortcomings of RDP in the story above were dealing with a MiTM attack, not a software vulnerability per se, but vulnerabilities that can be overcome with proper configuration. As most are likely aware at this time, there have been two Microsoft bulletins in 2012 that deal with remote code execution vulnerabilities in the code that implements RDP:

• MS12-020
• MS12-036

In both cases, Microsoft states: "…vulnerabilities could allow remote code execution if an attacker sends a sequence of specially crafted RDP packets to an affected system." While there are no known exploits resulting in remote code execution, there are several exploits available to cause denial of service conditions. And while you may breathe a sigh of relief to hear that the vulnerabilities are merely DoS related, the original disclosure of MS12-020 came from TippingPoint’s ZDI, which lists it as “allows remote attackers to execute arbitrary code." This likely means that non-public exploit code exists for MS12-020. Independent of exploitability, Tenable's research team has released plugins to reliably detect both MS12-020 and MS12-036:

• 58332 MS12-020: Vulnerabilities in Remote Desktop Could Allow Remote Code Execution (2671387) (credentialed check)
• 58435 MS12-020: Vulnerabilities in Remote Desktop Could Allow Remote Code Execution (2671387) (uncredentialed check)
• 59454 MS12-036: Vulnerability in Remote Desktop Could Allow Remote Code Execution (2685939) (credentialed check)

(Tenable's research team is, of course, working on a reliable, non-destructive way to remotely check if a system is vulnerable to MS12-036. Customers can check the Nessus Plugins page for more information.)

Below is an example of the plugin output from 58435, an uncredentialed check for MS12-020:

Out With the Old, In With the Old?

If I had to guess, I would say the debate over management protocols carries on today. Instead of guessing, I wanted to find out just how prevalent the problem could be amongst the security community. My curiosity got the better of me and I began wondering which plugins were the most popular. Since there is no way to track which plugins are firing in users’ Nessus scans, I turned to the Nessus plugins website. I found out that the most frequently-visited Nessus plugins page was plugin ID 18405 Microsoft Windows Remote Desktop Protocol Server Man-in-the-Middle Weakness. While this is an older plugin, it came out right after the MiTM vulnerability was published, was the very same vulnerability I had to deal with several years ago, and is kept up-to-date by Tenable's research team as recently as March of this year.

Below is an example of the output:

Threats, Risk, & Remediation

You will have to apply the following scenarios to your environment and come to your own conclusions on how to deploy (or not deploy) RDP as the remote access solution for your systems:

• Attackers able to perform a MiTM attack will steal credentials and have the ability to log keystrokes
• Attackers able to send packets to the RDP port (3389) can execute denial of service attacks
• If attackers already have, or develop, a working exploit, it would allow them to control the target system
• Exposed services, depending on configuration, are vulnerable to brute-force password attacks

The following defensive recommendations exist to combat the above attacks:

• Apply patches - Sounds easy, however, if you are using RDP to manage all of your critical servers, it could mean that all of them need to be reboot, at some point.
• Force the use of SSL as a transport layer for this service (if supported) – This option represents the “middle of the road” in terms of security, merely applying SSL encryption to the connection.
• Enable 'Allow connections only from computers running Remote Desktop with Network Level Authentication' setting (if available) - This is the most secure option for running RDP as it implements more advanced forms of authentication and encryption.

Network Level Authentication is the best option as it will use encryption for all RDP sessions. For example, if you were to configure this on a Window 7 desktop, the "Remote Settings" would look as follows:

For a detailed description of the encryption used, and how to configure the above setting across your entire Windows domain, see the article titled Configuring Network Level Authentication for RDP.

Conclusion

Recent vulnerabilities and common misconfiguration has painted a giant target on the RDP protocol. If you’re using it in your environment, it’s something that certainly warrants attention. Tenable's tools, such as Nessus, SecurityCenter, and PVS, can help you identify the weaknesses in your environment (see Resources section for examples). After that, gauging the risk and securing it properly is something you should do in conjunction with your users and systems administrators.

Resources

• Tracking SSH, SSL, Terminal Service and VNC Activity Passively (Dashboard)
• RDP Server Vulnerabilities Report Template
• MS12-020 Vulnerability Tracking Report Template