APR-RDP

APR-RDP enables the capture and the decryption of Remote Desktop Protocol
(RDP) traffic between hosts. RDP is the protocol used to connect to Windows
Terminal Services of a remote computer.

Microsoft's Windows Terminal Services (built into Windows 2000 Server
and Windows Server 2003) and Windows XP's Remote Desktop, provide an easy,
convenient way for administrators to implement thin computing within an
organization or for users to connect to their XP desktops from a remote
computer and run applications or access files.

A Windows 2000 terminal server can be installed in one of two modes:
administrative or application server. In administrative mode, only users
with administrative accounts can access the terminal server .... this
is why these sessions are so interesting.

By default, data that travels between the terminal server and the terminal
services client is protected by encryption. The protocol uses the RC4
symmetric encryption algorithm

at one of the following three levels:

High: encrypts
both the data sent from client to server and the data sent from server
to client using a 128-bit key.

Medium: encrypts
both the data sent from client to server and the data sent from server
to client using a 56-bit key if the client is a Windows 2000 or above
client, or a 40-bit key if the client is an earlier version.

Low: encrypts
only the data sent from client to server, using either a 56-bit or 40-bit
key, depending on the client version.

RC4 encryption keys are generated after an initial key exchange in which
RSA asymmetric encryption is used.

"... During extensive investigation
of the Remote Desktop Protocol (RDP), the protocol used to connect to
Windows Terminal Services, we have found that although the information
sent over the network is encrypted, there is no verification of the identity
of the server when setting up the encryption keys for the session. This
means RDP is vulnerable to Man In The Middle attacks (from here on referred
to as MITM attacks). The attack works as follows:

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.

The vulnerability
occurs because the clients by no means try to verify the public key of
the server, sent in step 2 above. In other protocols, such as the Secure
Shell protocol, most client implementations solve this for example by
letting the user answer a question whether a specific serverkey fingerprint
is valid. ..."

Microsoft confirmed the above problem and fixed the new versions of
Remote Desktop Clients. Recent clients (mstsc.exe), including the one
of version XPSP2 5.1.2600.2180, now check the Terminal Server identity
verifying its public key. They solved the problem ? No, man-in-the-middle
attacks are still possible and can be really invisible for users.

During the initial key-exchange phase, the terminal server sends to
the client a server certificate created at the start up of Terminal Server
services. This certificate is stored in the registry of the server under
the following key:

It contains an RSA public key and its digital signature as illustrated
below:

The public key modulus (n) is the same as the one present in the RSA2
key stored in the LSA Secret "L$HYDRAENCKEY" (you can use the
Cain's LSA Secret Dumper to check
it) of the server; the signature is the information used by the client
to verify the server identity.

From a man-in-the-middle attacker's point of view, the public key signature
must be modified on the fly to trick the client into verifying the new
Mitm public key that will be replaced into the network packet directed
to the client. But … what is used to produce this signature ?

Well, a digital signature is noting more nothing less than a hash of
something (in this case a server public key) encrypted using a private
key and an asymmetric encryption algorithm. This is exactly what is done
by the terminal server. At the client-side, this signature is decrypted
using a public key and the result is compared with a new hash of the received
server public key calculated by the client; if the two hashes match the
identity of the server is proven.

Microsoft use another RSA private key
to sign the Terminal Server public key and this private key is public
! It could sound strange but this is only the truth, the private
key used for the signature creation is hard-coded into mstlsapi.dll and
it is dynamically created, used and de-allocated into a subroutine of
the "TLSInit" API. Every Windows user has this file ... is this
a new kind of public-private key (PPK) ?!?

The knowledge of the PPK key lets the attacker calculate a valid signature
for the mitm public key generated on the fly during the mitm attack; the
client will verify the mitm signature correctly and it will accept the
session without informing the users that the server key is changed from
the usual one.

The signature is calculated encrypting, with the private part of the
PPK key, the MD5 hash of the server public key for a total of 108 bytes
hashed.

How it works

0) The network packet from the server is hijacked and captured by mean
of APR (ARP Poison Routing).

1) The server random and the real server public key are extracted from
the packet and stored for future usage.

2) The server public key is replaced in the network packet with a new
one generated by Cain (the mitm machine) during the key exchange phase.

3) The MD5 hash of the new mitm public key is calculated.

4) The hash is signed by Cain (encrypted using the private key) using
the super secret Microsoft PPK illustrated above.

5) The mitm sign is replaced into the network packet.

6) The packet is routed by APR to the client.

7) The network packet from the client is hijacked and captured by mean
of APR (ARP Poison Routing).

8) The client encrypted random is decrypted using the mitm private key.

9) The client random is encrypted using the real server public key and
replaced into the network packet for the server.

10) The packet is routed by APR to the server.

11) RC4 symmetric encryption keys are calculated.

12) The key entropy is reduced accordingly with the encryption level
used in the session.

13) Packets are decrypted and saved locally to text files.

Authentication

Cain also try to recognize the keyboard activity at the client-side.
This provide some kind of password interception.

Prerequisites

This feature needs APR to be enabled and
a Man-in-the-Middle condition between
the Terminal Server and the victim host.