Reported April 2, 2003, by Erik Forsberg.

 

 

VERSIONS AFFECTED

 

  • Microsoft Terminal Services

 

DESCRIPTION

 

Microsoft’s RDP implementation of Terminal Services doesn't verify the server's identity when setting up the encryption keys for the RDP session. This vulnerability 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 to connect to the

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

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

   again through the MITM. The MITM sends the packet further to the

   client, but exchanges the public key to another one for which 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 sends it to the

   server.

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

   enough information to construct the session keys used for further

   packets sent between the client and the server. All information

   sent between the parts can now be read in cleartext.

 

VENDOR RESPONSE

 

Microsoft was notified about this vulnerability on March 13, 2003, but hasn't yet responded.

 

CREDIT          

Discovered by Erik Forsberg.

Reported April 2, 2003, by Erik Forsberg.

 

 

VERSIONS AFFECTED

 

  • Microsoft Terminal Services

 

DESCRIPTION

 

Microsoft’s RDP implementation of Terminal Services doesn't verify the server's identity when setting up the encryption keys for the RDP session. This vulnerability 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 to connect to the

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

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

   again through the MITM. The MITM sends the packet further to the

   client, but exchanges the public key to another one for which 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 sends it to the

   server.

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

   enough information to construct the session keys used for further

   packets sent between the client and the server. All information

   sent between the parts can now be read in cleartext.

 

VENDOR RESPONSE

 

Microsoft was notified about this vulnerability on March 13, 2003, but hasn't yet responded.

 

CREDIT          

Discovered by Erik Forsberg.