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:
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.
http://technet2.microsoft.com/windowsserver/en/library/a92d8eb9-f53d-4e86-ac9b-29fd6146977b1033.mspx?mfr=true
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
