Man-in-the-Middle Attack on Microsoft Terminal Services

ReportedApril 2, 2003, by Erik Forsberg.

VERSIONS AFFECTED

DESCRIPTION

Microsoft’sRDP implementation of Terminal Services doesn't verify theserver's identity when setting up the encryption keys for the RDP session. Thisvulnerability can result in a potential man-in-the-middle (MITM) attack.

DEMONSTRATION

The discoverer posted the following steps as proof of concept:

1)The client connects to the server, however by some method (DNS

   spoofing, arp poisioning, etc.) we've fooled it toconnect to the

   MITM instead. The MITM sends the request further to theserver.

2)The server sends it's public key and a random salt, in cleartext,

   again through the MITM. The MITM sends the packetfurther to the

   client, but exchanges the public key to another one forwhich it

   knows the private part.

3)The client sends a random salt, encrypted with the server public

   key, to the MITM.

4)The MITM deencrypts the clients random salt with it's private key,

   encrypts it with the real servers public key and sendsit to the

   server.

5)The MITM now know both the server and the client salt, which is

   enough information to construct the session keys usedfor further

   packets sent between the client and the server. Allinformation

   sent between the parts can now be read in cleartext.

VENDOR RESPONSE

Microsoftwas notified about this vulnerability on March 13, 2003, but hasn't yetresponded.

CREDIT          

Discoveredby Erik Forsberg.

ReportedApril 2, 2003, by Erik Forsberg.

VERSIONS AFFECTED

DESCRIPTION

Microsoft’sRDP implementation of Terminal Services doesn't verify theserver's identity when setting up the encryption keys for the RDP session. Thisvulnerability can result in a potential man-in-the-middle (MITM) attack.

DEMONSTRATION

The discoverer posted the following steps as proof of concept:

1)The client connects to the server, however by some method (DNS

   spoofing, arp poisioning, etc.) we've fooled it toconnect to the

   MITM instead. The MITM sends the request further to theserver.

2)The server sends it's public key and a random salt, in cleartext,

   again through the MITM. The MITM sends the packetfurther to the

   client, but exchanges the public key to another one forwhich it

   knows the private part.

3)The client sends a random salt, encrypted with the server public

   key, to the MITM.

4)The MITM deencrypts the clients random salt with it's private key,

   encrypts it with the real servers public key and sendsit to the

   server.

5)The MITM now know both the server and the client salt, which is

   enough information to construct the session keys usedfor further

   packets sent between the client and the server. Allinformation

   sent between the parts can now be read in cleartext.

VENDOR RESPONSE

Microsoftwas notified about this vulnerability on March 13, 2003, but hasn't yetresponded.

CREDIT          

Discoveredby Erik Forsberg.