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).
What does this mean to me? 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!
How can I fix RDP in my Datacenter? Do i need to stop using RDP?
Can I prevent Man in the Middle Attacks?
|
Rob VandenBrink 578 Posts ISC Handler Oct 9th 2009 |
Thread locked Subscribe |
Oct 9th 2009 1 decade ago |
There doesn't seem to be any reasonable solution for people connecting to an XP machine to view the remote desktop. It uses the same protocol, but the server side doesn't allow for any certificates or authentication.
|
Eric 43 Posts |
Quote |
Oct 10th 2009 1 decade ago |
We have recently implemented Terminal Services Gateway. Which I think is pretty reasonable to control access to Terminal Services for desktops behind the perimeter firewall.
In the case of home users that want to use remote desktop, I suppose they could use something like stunnel + certificates for authentication. |
Algol 3 Posts |
Quote |
Oct 10th 2009 1 decade ago |
Something I've noticed when trying to packet sniff RDP sessions is the lack of parsers. Both Wireshark and Network Monitor 3 have only the most rudimentary parsers available for RDP. Microsoft document's the heck out of it (http://msdn.microsoft.com/en-us/library/cc216513(PROT.10).aspx), so I'm left wondering why no one else had tried to build the parsers for it.
The problem, it seems, is that the RDP protocol is actually X.224 and T.125. When Wireshark captures T.125 traffic, all the interesting RDP-specific bits are groups in a field called 'userData'. I've looked at creating a parser for this, but I am pretty worthless at writing anything that isn't Perl. |
Jasey 93 Posts |
Quote |
Oct 12th 2009 1 decade ago |
I wrote a parser of sorts awhile back, but it's mostly just good for getting keystrokes:
http://www.irongeek.com/i.php?page=security/cain-rdp-mitm-parser |
Jasey 1 Posts |
Quote |
Oct 21st 2009 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!