Microsoft Windows Remote Desktop Protocol checksum and keystroke vulnerabilities

Vulnerable

All versions of Microsoft Windows using encrypted RDP are vulnerable to
the checksum vulnerability. The following versions are also vulnerable to
the keystroke vulnerability:

Microsoft Windows XP Professional
Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server
Microsoft Windows .NET Standard Server Beta 3

Background

A design mistake in Microsoft's Remote Desktop Protocol (RDP) leaks
information about the contents of encrypted packets through their
checksums, since packets with the same plaintext have matching checksums.

A form of input packet used in version 5.0 of the protocol allows an
attacker to watch the network traffic from an encrypted session and work
out what keystrokes a user makes. Further, it is then possible for the
attacker to manipulate subsequent keystrokes sent across the network.

Checksum vulnerability

When RDP has encryption enabled, packets are first encrypted using RC4,
then an 8 byte HMAC checksum of the plaintext is prepended to the
cyphertext. The encryption key for RC4 is refreshed every 4096 packets,
but the HMAC key is apparently not changed during the session. Note that
the checksum relies only on the packet length, the packet contents and the
HMAC key; if a packet with identical contents is sent twice, the two
checksums will be the same, potentially leaking information if the same
packet is sent repeatedly. This is known as encrypt-then-authenticate,
and it is clearly a general design flaw in RDP. (This problem is further
discussed in Hugo Krawczyk's paper.)

This leakage can be observed in the RDP 5.0 style of input packets (which
leads to the keystroke vulnerability below). Other examples include the
same rendering operation being sent multiple times, for example to make a
cursor flash; and Terminal Services Client's device redirection, such as
identical data repeatedly transmitted from the serial port. Plugins using
Microsoft's Terminal Services Virtual Channels are also vulnerable.

Keystroke vulnerability

In RDP 4.0, input events are sent with a unique timestamp as specified in
the T.128 standard; this packet is then framed using lower level protocols
T.125 and T.123 and transmitted using TCP. (T.125 is used by Microsoft's
RDP Virtual Channel API to multiplex other data such as audio and printing
across the same connection.) With this many protocol layers, a single key
press requires a packet 56 bytes long to be transmitted over TCP, which is
inefficient.

In RDP 5.0 Microsoft added an abbreviated way to specify common commands
including input events. These packets start 0x84 (and other values)
rather than 0x03 which is used to start T.123. Encryption is done in the
same way, but only the key code and key event type (press, repeat or
release) is sent – there is no timestamp – so the packets are now only
12 bytes long.

Therefore the checksum is the same for each key event type for the same
key. This only fails when the client concatenates input events into a
single packet but this is uncommon. This reasoning does not apply to RDP
4.0 input packets because a timestamp is sent so the packet contents and
therefore the checksum will change.

Here is an example taken from a real session:

Client to server:
84 0c c5 db ec cd 6c 7e 31 6c 47 a2

Client to server:
84 0c ef 6a bb 01 21 b0 c3 c6 f6 e5

…

Client to server:
84 0c c5 db ec cd 6c 7e 31 6c c1 0a

Client to server:
84 0c ef 6a bb 01 21 b0 c3 c6 fe bd

…

Client to server:
84 0c c5 db ec cd 6c 7e 31 6c 8e 41

Client to server:
84 0c ef 6a bb 01 21 b0 c3 c6 22 f8

The first byte (0x84) shows that these are RDP 5.0 style packets, not
T.123. The second shows the length (i.e., the packets are 0x0c bytes
long). The next 8 bytes are the HMAC checksum, and the last two are the
encrypted packet contents for the input event.

Since the two pairs of checksums match, the same thing was being sent in
each case. Indeed, the same key had been pressed several times, although
it isn't possible to tell which key it was from the data given above.
Given a larger dump of session data it would be possible to make a good
guess for which key each checksum corresponds to by looking at the
frequencies and ordering of the different checksums; this is simply a
mono-alphabetic substitution cipher on the scan code plus key event type.
This knowledge could then be used to work out what the user types, and the
attacker might then be able to capture the user's passwords.

(Data from packets which do not start "84 0c" are a different type or
length so can be ignored. Apparently the only packets of that length sent
by the client are key events.)

Pete Chown pointed out that this is also subject to a substitution attack
since the attacker now knows enough to be able to change a key input event
to another one. Suppose the user presses "A" and the attacker wants a "B"
key press to be sent instead. The attacker knows that the checksum and
the plaintext for each of these two events. Since the cypher is RC4 and
the plaintext for the events are the same, the desired cyphertext is
obtained from XORing the "A" press plaintext and then XORing the "B" press
plaintext. So the substitution is made simply by swapping the "A" press
checksum with the "B" press checksum, and replacing the cyphertext.

Workaround

Use the Microsoft Terminal Services Client version 4.0, rather than later
versions of Terminal Services Client or the Advanced Terminal Services
Client. This only cures the keystroke vulnerability and does not address
the problem for multiple packets with the same contents.

References

The Order of Encryption and Authentication for Protecting Communications
(or: How Secure is SSL?), Hugo Krawczyk,
http://link.springer.de/link/service/series/0558/bibs/2139/21390310.htm

Section 8.18 from T.128 Multipoint application sharing, Series T:
Terminals for telematic services, ITU-T.

T.125 Multipoint communication service protocol specification, Series T:
Terminals for telematic services, ITU-T.

T.123 Network-specific data protocol stacks for multimedia conferencing,
Series T: Terminals for telematic services, ITU-T (also RFCs 905 and 1006)

Using Terminal Services Virtual Channels, MSDN Platform SDK: Terminal
Services,
http://msdn.microsoft.com/library/en-us/termserv/termserv/
using_terminal_services_virtual_channels.asp

HMAC: Keyed-Hashing for Message Authentication, RFC 2104,
http://www.ietf.org/rfc/rfc2104.txt

Microsoft was notified on 16 April 2002.

Credits

Ben Cohen
Software Developer
[email protected]

Pete Chown
Chief Security Consultant
[email protected]

Skygate Technology Ltd.
http://www.skygate.co.uk/
+44 (0)20 8542 7856