Terminal Services vulnerable to man-in-the-middle attacks

This write-up was released through Bugtraq and I believe that every IT shop should at least be aware of it. The write-up details how Terminal Server sessions are built and how they are exploited. The author confirms that they have code to make the exploit happen but they are not releasing it at this time. I can guarantee that code will surface for this exploit as many IT shops use Terminal Services for remote administration.

Read on.....

During extensive investigation of the Remote Desktop Protocol (RDP), the protocol used to connect to Windows Terminal Services, we (Cendio
Systems) have found that although the information sent over the network is encrypted, there is no verification of the identity of the server when setting up the encryption keys for the session.

This means RDP is vulnerable to Man In The Middle attacks (from here on referred to as MITM attacks). The attack works as follows:

1) The client connects to the server, however by some method (DNS
spoofing, arp poisioning, etc.) we've fooled it to connect to the
MITM instead. The MITM sends the request further to the server.
2) The server sends it's public key and a random salt, in cleartext,
again through the MITM. The MITM sends the packet further to the
client, but exchanges the public key to another one for which it
knows the private part.
3) The client sends a random salt, encrypted with the server public
key, to the MITM.
4) The MITM deencrypts the clients random salt with it's private key,
encrypts it with the real servers public key and sends it to the
server.
5) The MITM now know both the server and the client salt, which is
enough information to construct the session keys used for further
packets sent between the client and the server. All information
sent between the parts can now be read in cleartext.

The vulnerability occurs because the clients by no means try to verify the public key of the server, sent in step 2 above. In other protocols, such as the Secure Shell protocol, most client implementations solve this for example by letting the user answer a question whether a specific serverkey fingerprint is valid.

The clients we've seen so far for RDP have no way to preinsert a known server key. There is also no interaction with the user in order to verify a key the first time a connection is made to a new server.

We have communicated with Microsoft in this matter, and they
confirmed 2003-03-19 that the problem do exist in their current implementation. They are currently "investigating the feasability in adding this functionality". They also point out that they do not claim RDP having the functionality of providing server authentication.

We feel that Microsoft is not taking this seriously enough. We know there are sites using Terminal Services to transfer sensitive data, and we feel that they need to be informed about this vulnerability in order to be able protect their networks. This is why we publish this information at this moment.

We've tested this vulnerability against Windows 2000 Terminal Server, Windows 2000 Advanced Server and the upcoming Windows Server 2003 using both the clients delivered with Windows 2000 and the latest downloadable RDP client from Microsoft. We have reason to believe that the vulnerability exists when running both RDP version 4 and 5, and regardless of terminal server mode.

We have developed software that can be used to exploit this vulnerability, but we choose not to release it.

\EF
--
Erik Forsberg Telephone: +46-13-21 46 00
Cendio Systems Web: http://www.thinlinc.com

Hope this helps!
:p

This vulnerability is quite easily overcome if you provide Terminal Services access to clients across the internet. We use a PPTP VPN to the firewall as an initial connection. The firewall then provides the client with a local, (read private), IP address through the tunnel. The request for the terminal server is then made across the private addresses through the tunnel itself. This adds an additional level of security for only a small amount of inconvenience to the client and means that we do not need the additional port 3389 access allowed through the firewall.

I believe that most users of Terminal Server will not mind this too much. Terminal server is more commonly used on trusted networks, i.e. by admins for managing servers, and for multiuser environments.

Like Tiger Shark says, if you are running over a VPN it is not a problem.

It's interesting to note that an attacker doesn't actually need to carry out the technically complex Man-in-the-middle attack to exploit this problem- he can simply create a fake server instead and grab the passwords (feigning an error message to explain why the user cannot log on)

You guys are correct. I posted this for those who run TS connections across the internet or other untrusted networks. I don't have to tell either of you how many people still do this kind of thing ;)

Regards

--TH13

What has surprised me in the past is the very small number of scans done for port 3389 that is publicly available. Less than one a month definitely.

I wonder if they've carried this testing out with the Citrix version? I am pretty sure that TS is basic Citrix technology that rolled back to M$ a couple years back due to a licensing issue.

Interesting! Worth looking into I would think - but to find the time....

Yeah, I believe there are a lot of people who run this "in the raw" - but I can't see this as being something that the average script kiddie would be after.

I'm a firm believer in putting either TS or Citrix behind a VPN connection whenever possible, preferably with strong authentication of some form or another.

Thanks for the info.

I believe that Citrix uses an SSL connection via their secure gateway product though I haven't personally seen it in action.

You can configure nFuse to use an SSL connection. nFuse is a gateway product for Citrix. However, I have seen it used with a general HTTP connection as well, so SSL is not a requirement.

Additionally, I've seen some people with publicly-accessible Citrix servers sitting on DMZ's with holes for the full client connection. Again, their client software supports encryption.

I'm wondering if there is the same MITM potential with the traditional Citrix Client/Citrix Server configuration.