SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   OS (Microsoft)  >   Windows Remote Desktop Protocol (RDP) Vendors:   Microsoft
Microsoft Remote Desktop Protocol (RDP) Design Flaw May Disclose Information About the Unencrypted Data to Remote Users and May Let Data Be Modified During Transmission
SecurityTracker Alert ID:  1005246
SecurityTracker URL:  http://securitytracker.com/id/1005246
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Sep 18 2002
Impact:   Disclosure of system information, Modification of system information

Version(s): RDP 4.0, RDP 5.0
Description:   An access control and authentication vulnerability was reported in Microsoft's Remote Desktop Protocol (RDP), used by various Windows applications. A remote user with access to the encrypted data stream may determine information about the unencrypted data and can modify the stream without detection.

It is reported that RDP leaks information about the contents of encrypted packets due to a weakness in computing the checksums, as packets with the same plaintext have matching checksums. All versions of Windows using encrypted RDP are apparently affected.

In RDP 5.0, some common commands, including user input events, can reportedly be sent via special packets where only the key code and key event type (press, repeat, or release) is transmitted. In this case, a timestamp is not sent. As a result, the packet checksum is the same for each key event type for the same key. A remote user monitoring the encrypted packet stream can therefore determine when the same key has been pressed, even though the key itself is not disclosed. By monitoring a large amount of session data and performing an analysis of key patterns and frequencies within the session, a remote user could determine the actual keys pressed by the victim. This could be used to capture passwords.

Also, it is reported that RDP version 5.0 allows a remote user with access to the encrypted data stream to manipulate keystrokes sent via the network.

According to the report, if the victim presses "A" and the remote user wants to modify this to be a "B" key press, the remote user can obtain the desired cyphertext by XORing the "A" press plaintext and then XORing the "B" press plaintext. The packets can be substituted by switching the "A" press checksum with the "B" press checksum and replacing the cyphertext.

The vendor has reportedly been notified.

Impact:   A remote user that can monitor the encrypted RDP packet stream may be able to determine information about the unencrypted data. The user may also be able to modify keystrokes sent via the network.
Solution:   No solution was available at the time of this entry.

The author of the report recommends as a partial workaround using the Microsoft Terminal Services Client version 4.0, rather than a more recent version of the Terminal Services Client or the Advanced Terminal Services Client.

Vendor URL:  www.microsoft.com/technet/security/ (Links to External Site)
Cause:   Access control error, Authentication error, Randomization error
Underlying OS:  Windows (Any)
Underlying OS Comments:  .NET Server is also affected

Message History:   This archive entry has one or more follow-up message(s) listed below.
(Microsoft Issues Fix) Microsoft Remote Desktop Protocol (RDP) Design Flaw May Disclose Information About the Unencrypted Data to Remote Users and May Let Data Be Modified During Transmission
The vendor has released a fix.



 Source Message Contents

Subject:  Microsoft Windows Remote Desktop Protocol checksum and keystroke


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
ben.cohen@skygate.co.uk

Pete Chown
Chief Security Consultant
pete.chown@skygate.co.uk

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

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, SecurityGlobal.net LLC