Microsoft developed the remote desktop protocol in order to allow remote GUI- based access to hosts. It is easy to pick on Microsoft and I do respect what they have accomplished, however, it may not come as a surprise that they did it all wrong with RDP in terms of security.
By default, out-of-the-box, a server or desktop supports RDP with RC4 encryption. Most recent servers and clients support 128-bits encryption. Sounds secure, right? Well, it isn't unfortunately. There are two major security weaknesses that affect the remote desktop protocol.
- Keystroke vulnerability
The original , RDP version 4.0, is based on the T.128 protocol. Input events, such as keystrokes, are sent to the server with a unique timestamp as specified in the T.128 standard. This means that each message containing an input event is unique and so will be the checksum generated from this input event data. In other words: if two RDP messages contain the same data, they will still be unique because of the timestamp. Microsoft did it right in RDP version 4.0, but there was one drawback: the timestamp generated overhead, making RDP messages relatively large.
So in RDP version 5.0, Microsoft decided to drop the timestamp. Thus, if two RDP messages contain the same data, their checksum will be identical. So if the same key is pressed twice, the two packets that are generated will contain different encrypted data segments but the checksums will be identical. Although it is not clear which key is pressed, if a larger data set is analyzed, patterns can be discovered and an accurate guess can be made to wich keys are pressed.
In a nuttshell an attacker that has access to the data stream of an RDP session will be able to decode keystrokes and thus be able to:
-
obtain your username and password, allowing access to the system!
-
read what you type.
Please visit the following location as it provides a more detailed explanation of this vulnerability:
http://www.xatrix.org/article.php?s=1943
- Man-in-the-middle-attack
At first, back in 2003, RDP-clients did not verify the identity of the RDP server. So an attacker can easily spoof an identity and perform a man-in-the- middle-attack. Microsoft attempted to fix this vulnerability but did not succeed. Although more recent RDP-clients do verify the identify of the server, it is still possible to spoof this identity. Microsoft uses a fixed hard-coded key to identify the server with. This key resided in a system DLL that is available to the general public. An attacker can easily obtain this key, create a fake identity and still prove to be legitimate since the identity is signed with a trusted key.
More detailed information:
http://www.oxid.it/downloads/rdp-gbu.pdf
Conclusion
Given these vulnerabilities, RDP is, in its default configuration, virtually as insecure as plain old telnet. Think about that the next time you logon with administrator credentials using RDP.
Tool that implements the attacks
The well-known hack-tool Cain & Abel has a build-in RDP man-in-the-midlle implementation. It automatically decrypts (parts of) RDP data packets and reveals the key strokes that are send to a server. So if you don't believe this story and just want to see for yourself how easy such an attack really is, download this tool and test it for yourself.
To defend against the attacks
To protect against this attack, it is strongly advised to implement RDP based on TLS/SSL encryption. Ofcourse, you'll have to install a server-side SSL- certificate and it may be necessary to obtain an official (as in not self-) signed certificate.
So please understand the risks of using RDP, especially over the Internet. If TLS is for some reason not an option, use an encrypted VPN-connection to tunnel the RDP-session in, as an added layer of protection. Never use RDP in its default configuration over the interne without additional protection.
EDIT: IN RDP version 6.0 the man-in-the-middle-attack is no longer possible!
EDIT2: Configure your terminal server to use FIPS compliant encryption. It will use Triple DES encryption even if TLS is not enabled.
After you enable this setting on a Windows Server 2003-based computer, the following is true:
The RDP channel is encrypted by using the 3DES algorithm in Cipher Block Chaining (CBC) mode with a 168-bit key length.
The SHA-1 algorithm is used to create message digests.
Clients must use the RDP 5.2 client program or a later version to connect.
So you don't need to use TLS if you want to use a more secure algorithm than RC4.
4e86-ac9b-29fd6146977b1033.mspx?mfr=true
Comments