RDP-based SSL man-in-the-middle attack

This article demonstrates how a user ignores certificate warnings for SSL-based RDP connections by demonstrating the key-sending information hijacked during the RDP Session, which may cause man-in-the-middle (MiTM) attacks, I also summarized some suggestions on how to avoid being the victim of such attacks.

RDP connection type

Before getting started, we will first clarify the three types of RDP connections, including:

-RDP Security Layer-SSL (TLS 1.0)-CredSSP (SSL with NLA)

This document describes the intermediate type, SSL (TLS 1.0 ). On the terminal server, SSL is generally configured as follows (any NLA check box is not selected ):

RDP Configuration

If the server is set to "Negotiate", some connections may be vulnerable to attacks because the security layer may use SSL.

SSL certificate warning

If a user does not pay attention to the following warning prompts during each connection, this article is intended for these users:

Frequently overlooked SSL warnings

Attack Overview

At a high level, attacks are similar to other SSL man-in-the-middle attacks:

1. Find a way to connect the victim to the PoC tool (rdp-ssl-mitm.py) on our system, rather than the RDP server it wants to connect.

2. The tool uses the RDP protocol and uses SSL during interaction through negotiation.

3. Once the connection is negotiated to use SSL, our tool will negotiate an SSL connection with the RDP client using its own (untrusted) SSL certificate. In this way, the spoofing tool has the opportunity to access the plaintext information sent by the RDP client.

4. The tool also needs to create an SSL connection with the normal RDP server to send data from the RDP client to the server.

The only drawback of this attack is that before creating the required SSL connection, our spoofing tool must have a brief interaction with the client through the RDP protocol.

1. Connect the victim to us

In the real attack process, we need to connect the RDP client to our system, rather than the target server. Therefore, ARP spoofing, DNS spoofing, or some other methods are used. For the sake of simplicity, this article will not describe these details, assuming that the RDP client of the victim has been successfully spoofed to connect it to the attacker's system.

On our attack system (192.168.190.170), start the PoC tool and tell it to connect to the normal RDP server 192.168.2.96:

$ ./rdp-ssl-mitm.py -r192.168.2.96:3389[+] Listening forconnections on 0.0.0.0:3389

Here we only need to simply enter the IP address of the Attack System to the RDP client (the client is connected from 192.168.190.1 ):

Directly enter the attacker's IP address and skip ARP spoofing steps

2. Negotiate with the RDP client to use SSL

SSL negotiation is very short in RDP:

Message #1: Client >MiTM > Server03 00 00 13 0e e0 00 00 00 00 00 01 00 0800 *03*00 00 00

This message remains static. Our spoofing tool directly transmits it to the server without modification. * 03 * indicates that the client supports the RDP security layer, SSL, and CredSSP.

Message #2: Server >MiTM > Client03 00 00 13 0e d0 00 00 12 34 00 02 00 0800 *01*00 00 00

The following message indicates the Protocol selected by the server. * 01 * indicates that the server has selected SSL (* 02 * Indicates CredSSP ). We also pass this message to the client without modification.

Note: If the server selects CredSSP (* 02 *), this demonstration will fail because it only attacks SSL, not CredSSP.

3. Create an SSL connection with the RDP Client

Message #3: Client >MiTM

The third message is used to start creating an SSL connection. Here, the SSL client message starts from * 16 0301*(03 01 indicates the version used for SSL: SSL 3.1AKA TLS 1.0)

*16 03 01* 00 5a 01 00 00 56 03 01 52 21 acbe 6320 ce de 4b a5 90 18 f0 66 97 ee 9d 54 14e3 1c... snip ...

The spoofing tool does not directly send the data to the server, but directly sends a connection creation request to the server and establishes an SSL connection with the client.

Here, the SSL certificate we use will be considered illegal by the RDP client, and an SSL warning will be displayed to the user in mstsc:

Security Warning caused by the certificate used by the PoC Tool

If you check the certificate carefully, you will find that the SSL certificate used here is different from the normal certificate. To improve the attack quality, we need to constantly improve the certificate so that it is infinitely close to the real certificate, but we will never get the same signature as the normal certificate, so there will always be some difference.

4. Create an SSL connection with the RDP Server

At the same time, our tool also initiates a connection creation message to the RDP server and creates a second SSL connection with it.

Display button Information

To some extent, our spoofing tool can display all the key operations sent by the RDP client to the server in plain text. It is easy to determine which type of message is sent. The following two 4-byte messages are sent by pressing the 'p' key.

44 04 00 19 44 04 01 19

The third byte indicates the direction of the key (00 indicates that the key is pressed, and 01 indicates that the key pops up ). The fourth byte is the scancode Of the key. Through the query, we can find that 0 × 19 corresponds to the letter "p.

Generally, the scan code corresponding to the character depends on the keyboard used. The PoC tool I used has implemented the ing of the QWERTY keyboard. Therefore, if the reader uses the UK/US keyboard, this tool can directly convert most scan codes into corresponding characters. Note that we cannot know whether the characters are in uppercase or lowercase. It must be determined based on the status of the CAPSLock and SHIFT keys.

Let's not talk much about it. Let's look at the example directly. The following are some outputs of the PoC tool, displaying the record keys, and logging the logon username as Administrator and Password as Password:

$ ./rdp-ssl-mitm.py -r 192.168.2.96:3389[+] Listening for connections on0.0.0.0:3389[+] Incoming connection from192.168.190.1:60370[+] New outgoing request to192.168.2.96:3389 (SSL: 0)[+] Connected[+] Detected incoming SSL connection.Turning self into SSL socket[+] Incoming connection from192.168.190.1:60374[+] New outgoing request to192.168.2.96:3389 (SSL: 0)[+] Connected[+] Detected incoming SSL connection.Turning self into SSL socket<LShift-down>A<LShift-up>DMINISTRATOR<Tab><LShift-down>P<LShift-up>ASSWORD<Enter>

Summary

The habit of ignoring SSL authentication warnings in RDP connections may cause the same consequences as ignoring HTTPS website certificates: users can be easily attacked by man-in-the-middle. This attack can intercept user names, passwords, key information, and other sensitive information.

Normally, no warning is prompted when you use an SSL certificate that is trusted on the RDP client and signed by the certification authority. Therefore, we strongly recommend that you pay attention to this issue.

If the server authorizes NLA, this attack will also become invalid, So we strongly recommend that you use NLA.

However, you need to know that this is not a vulnerability in the RDP client or server software, and this exploitation method is not newly discovered. This is only a weakness in RDP usage. It may occur when users ignore security warnings. It is only a common SSL man-in-the-middle attack at the technical level.

An interesting extension of this attack is the ability to record screen images and attack any drive mapped to the RDP client. For more details, see Attacking the RDP Clients. however, such attacks require a certain encoding basis.

[Via portcullis]