Microsoft Terminal Services vulnerable to MITM-attacks
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 ...
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.
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.
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
Quote:Ds3Circuit, are you part of this Cendio Systems? If so, good job... it is good things like this are pointed out to MS if you ask me by folks like yourselves!
Unfortunately I cannot take the credit. My employer is educational, in every sense of the word. I am impressed with this discovery though, since I know quite a few that use Terminal Services without a VPN.
I was sharing something that was spotted in a newsgroup.
Even though ICA and RDP are 2 different protocols for moving terminal service "data", I am sure they share the same principles and who knows, maybe Citrix ICA may have a similar flaw.
Unfortunately I cannot take the credit. My employer is educational, in every sense of the word. I am impressed with this discovery though, since I know quite a few that use Terminal Services without a VPN.
I was sharing something that was spotted in a newsgroup.
Even though ICA and RDP are 2 different protocols for moving terminal service "data", I am sure they share the same principles and who knows, maybe Citrix ICA may have a similar flaw.
Originally posted by DS3Circuit:
Quote:During extensive investigation of the Remote Desktop Protocol (RDP), the protocol used to connect to Windows Terminal Services, we (CendioSystems) 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
.............
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.
Apparently Microsoft is now taking this threat seriously. Windows Server 2003 SP1 will include SSL-based Server Authentication for Terminal Servers. The new terminal services (remote desktop) client software that is required for SSL will work with Windows 2000, 2003, and XP. The MSI for the new software is, of course, included.
I hope they release a new version of the web client. It is SO much easier to deploy on a large scale.
Windows Server 2003 SP1 is now in "Release Candidate" mode, but the MSDN article I found references Beta 1. So this solution has been available (albeit in beta) for a little while now.
See the following URL for more information: http://support.microsoft.com/default.aspx?scid=kb;en-us;555188
Quote:During extensive investigation of the Remote Desktop Protocol (RDP), the protocol used to connect to Windows Terminal Services, we (CendioSystems) 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
.............
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.
Apparently Microsoft is now taking this threat seriously. Windows Server 2003 SP1 will include SSL-based Server Authentication for Terminal Servers. The new terminal services (remote desktop) client software that is required for SSL will work with Windows 2000, 2003, and XP. The MSI for the new software is, of course, included.
I hope they release a new version of the web client. It is SO much easier to deploy on a large scale.
Windows Server 2003 SP1 is now in "Release Candidate" mode, but the MSDN article I found references Beta 1. So this solution has been available (albeit in beta) for a little while now.
See the following URL for more information: http://support.microsoft.com/default.aspx?scid=kb;en-us;555188
