Feel free to comment on this diary entry - we’re interested in issues or resolutions you may have had involving the RDP protocol, Terminal Services client and server applications, as well as any questions you may have regarding this diary entry.  You can use the comment button at the bottom of this article.

Microsoft's RDP (Remote Desktop Protocol) and it's associated "terminal service" client and server apps have been widely used since Windows 2000 days for Windows server administration.  RDP gives delivers the server's complete remote desktop to a client.  RDP has been improved over time, and is now pretty much the de facto standard for remote administration in most datacenters.  

In more recent times, VDI (Virtual Desktop Interface) implementations often use RDP to deliver the desktop from a VM to thin clients or PC's, in an effort to centralize control and minimize administration requirements for client desktops.  This has resulted in more widespread use, as well as improvements to the protocol especially around the delivery of graphics and performance in high-latency situations.

The perception has always been that RDP offers a secure delivery of information, as Microsoft publishes detailed information of it’s encryption settings.  The default setting is now “high”, which means 128bit encryption (using RC4)

However, there’s a problem with RDP – by default the certificate used for encryption is signed by an RSA private key, which is then stored statically in the file mstlsapi.dll, which every Windows client and server has in it’s base install!  This was originally discovered by Erik Forsberg in 2003 (http://www.securityfocus.com/archive/1/317244 ), and documented further at http://www.oxid.it/downloads/rdp-gbu.pdf (amongst other places).

This means that in a default installation, a Man-in-the-Middle (MITM) attack can intercept the exchange of RDP encryption information, substitute it’s own (correctly signed) SSL information to both the client and the server, and decrypt the entire session, all without the “encryption alert” message showing up at the client!

Even if that were not the case, the default installation for Terminal Services client on XP does not notify you if the server certificate does not "match".  Check for yourself  - open the terminal services client, choose the "Advanced" tab, then check the "verification policy" value - youi'll see that it's set to "Connect and don't warn me"

What does this mean to me?

What this means is that if the default Windows installation is taken, and no further protections around encryption are implemented, that RDP is easily compromised.  This is normally done by capturing an RDP login exchange, usually using a Man-in-the-Middle attack, then decrypting the captured packets to arrive at the password.  CAIN (www.oxid.it) does a great job at this task.  Describing an attack in theory is great, but I find that people don’t often take it seriously until the SEE it work in their environment.  For this reason, we’ve attached a short video of such an attack, with a brief description of how MITM attacks.  This attack works even if you change the “Server Authentication Verification” discussed above.

 
When I discuss this with people, they often don’t realize just how large a security risk this is – until they see it for real that is.  This video shows just how easy it is==> http://isc.sans.org/diaryimages/rdp-mitm-mpg.html .

There's a brief explanation of how Man in the Middle via ARP cache poisoning works, but the emphasis is on the RDP stuff, and on how to use CAIN to get the goods – in an internal security assessment for instance.  Just be sure that if you try this at home, that your laptop has enough horsepower to “keep up”.  If your laptop chokes during the attack, remember that you’ve poisoned the ARP cache of 2 or more hosts (your DC is one of them maybe), and the default ARP cache timer is 4 hours!

In a larger sense, what this should mean to us is that the default installation of most things (including Windows) is almost never the right choice for security.   Products ship so that people can install them with limited training and be still successful.  This is true of Windows, most Linux distributions, OSX, pretty much everything.  After installing an operating system for business (or personal) use, it’s always a good thing to reference that vendor’s security best practices.  Googling the vendor name plus “hardening guide” is often a good start.  Other references that may be helpful are sites like the “SANS Top 20” ( http://www.sans.org/top20/ ) or the benchmarks at the Center for Internet Security ( http://www.cisecurity.org/ ).

How can I fix RDP in my Datacenter?  Do i need to stop using RDP?

The good news is that the RDP protocol, as well as Microsoft’s Terminal Services client and server applications are very well constructed, and can be secured using industry-standard methods, methods that you are probably already using for your corporate website or wireless infrastructures.  Microsoft has really good documentation on using a PKI (Public Key Infrastructure) to use trusted authorities to secure RDP using TLS (Transport Layer Security).  You can find one such document (which references other docs) here ==> http://technet.microsoft.com/en-us/library/cc782610%28WS.10%29.aspx

In Windows Server 2008, a new feature called NLA (Network Level Authentication) offers much stronger protections against key spoofing by providing real authentication of the session.  It does not protect against layer 2 MITM (arp poisoning) - but with the added authentication and encryption protections, the traffic secured.  NLA requires client versions of 6 or higher on the client desktops to work. Browse here for more NLA details ==> http://blogs.technet.com/askperf/archive/2008/02/16/ws2008-network-level-authentication-and-encryption.aspx
 

Can I prevent Man in the Middle Attacks?

You can certainly make them more difficult by configuring you switches correctly – look for an isc diary on Layer 2 protections coming soon.