Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Windows :: win5699.htm

Microsoft Windows Remote Desktop Protocol multiple vulnerabilities



18th Sep 2002 [SBWID-5699]
COMMAND

		Microsoft Windows Remote Desktop Protocol multiple vulnerabilities

	

	

SYSTEMS AFFECTED

		 Microsoft Windows XP Professional

		 Microsoft Windows 2000 Server

		 Microsoft Windows 2000 Advanced Server

		 Microsoft Windows .NET Standard Server Beta 3

	

	

PROBLEM

		Thanks to Ben  Cohen  [ben.cohen@skygate.co.uk]  of  Skygate  Technology

		Ltd. [http://www.skygate.co.uk/] analysis :

		

		--snipp--

		

		

		 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.

		

		At the start of the protocol  there  is  a  negotiation  of  client  and

		server graphics capabilities, in a packet called PDU Confirm  Active.  A

		block of 32 bytes in this  packet  allows  the  client  to  disable  the

		drawing commands that it does not support.

		

		 Exploit

		 =======

		

		Shown below is the unencrypted packet contents for the  problematic  PDU

		Confirm Active packet. The only change is from 01  to  00  on  the  line

		indicated.

		

		c4 01 13 00 f0 03 ea 03 01 00 ea 03 06 00 ae 01

		4d 53 54 53 43 00 11 00 00 00 01 00 18 00 01 00

		03 00 00 02 00 00 00 00 05 04 00 00 00 00 00 00

		00 00 02 00 1c 00 08 00 01 00 01 00 01 00 00 05

		00 04 00 00 01 00 01 00 00 00 01 00 00 00 03 00

		58 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

		00 00 00 00 00 00 01 00 14 00 00 00 01 00 00 00

		2a 00 01 00 01 01 01 00 00 01 01 01 00 01 00 00  <- was "2a 00 01 01"

		00 01 01 01 01 01 01 01 01 00 01 01 01 00 00 00

		00 00 a1 06 00 00 00 00 00 00 00 84 03 00 00 00

		00 00 e4 04 00 00 13 00 28 00 01 00 00 03 78 00

		00 00 78 00 00 00 f3 09 00 80 00 00 00 00 00 00

		00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 00

		08 00 06 00 00 00 07 00 0c 00 00 00 00 00 00 00

		00 00 05 00 0c 00 00 00 00 00 02 00 02 00 08 00

		0a 00 01 00 14 00 15 00 09 00 08 00 00 00 00 00

		0d 00 58 00 05 00 08 00 09 08 00 00 04 00 00 00

		00 00 00 00 0c 00 00 00 00 00 00 00 00 00 00 00

		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

		00 00 00 00 00 00 00 00 0c 00 08 00 01 00 00 00

		0e 00 08 00 01 00 00 00 10 00 34 00 fe 00 04 00

		fe 00 04 00 fe 00 08 00 fe 00 08 00 fe 00 10 00

		fe 00 20 00 fe 00 40 00 fe 00 80 00 fe 00 00 01

		40 00 00 08 00 01 00 01 03 00 00 00 0f 00 08 00

		01 00 00 00 11 00 0c 00 01 00 00 00 00 0a 64 00

		14 00 08 00 01 00 00 00 15 00 0c 00 01 00 00 00

		00 0a 00 01

		

		

		

		 Denial of service

		

		One of these apparently controls whether  the  Pattern  BLT  command  is

		sent. On Windows 2000 Server,  disabling  this  command  will  make  the

		server send bitmaps instead of Pattern BLT  commands.  However,  Windows

		XP Professional apparently reboots when it  tries  to  render  patterns;

		since this happens while the login screen is being drawn, this does  not

		require the client to have logged on or  authenticated  to  the  server.

		This applies to all versions of the protocol tested (RDP  4.0,  5.0  and

		5.1), and it is also reproducible  with  Windows  .NET  Standard  Server

		Beta 3.

		

		--snapp--

	

	

SOLUTION

	 Update (19 september 2002)

	 ======

	

	 The XP Pro Service Pack 1 patches this.

	 http://www.microsoft.com/technet/security/bulletin/MS02-051.asp

	

		 Workarounds

		 ===========

		

		Disable Remote Desktop  (from  Control  Panel,  System,  Remote,  Remote

		Desktop, deselect the option "Allow users to connect  remotely  to  this

		computer").

		

		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

		 ==========

		

		Section 8.2.5 from  T.128  Multipoint  application  sharing,  Series  T:

		Terminals for telematic services, ITU-T.

		

		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

		

	


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH