s straight Last week, there was published an article from NETSCOUT Microsoft Remote Desktop Protocol (RDP) Reflection/Amplification DDoS Attack Mitigation Recommendations – January 2021 | NETSCOUT that publicly available RDP servers were used to do amplified DDoS attacks.
From the article “When enabled on UDP/3389, the Microsoft Windows RDP service may be abused to launch UDP reflection/amplification attacks with an amplification ratio of 85.9:1. The amplified attack traffic consists of non-fragmented UDP packets sourced from UDP/3389 and directed towards the destination IP address(es) and UDP port(s) of the attacker’s choice. In contrast to legitimate RDP session traffic, the amplified attack packets are consistently 1,260 bytes in length and are padded with long strings of zeroes. Approximately 33,000 abusable Windows RDP servers have been identified, to date.”
So how is this possible? Before Christmas we saw a similar amplification attack from Citrix NetScaler because of a weakness in how they implemented the DTLS protocol (as I’ve written more about here –> Citrix NetScaler DDoS and deep dive DTLS protocol | Marius Sandbu (msandbu.org)
NOTE: There is still a problem with DTLS implementation in the RDP stack, but the issue that is seeing now with RDP is based upon pure UDP connection, creating a forged packet for existing connections on UDP to do the amplification attack.
In essence there are issues with datagram protocol (DLTS) and that is that they are extremely susceptible to a variety of DoS attacks.
1: An attacker can trigger an amplified DDoS attack by
transmitting a series of handshake initiation requests, causing
the server to allocate state and potentially to perform
2. An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source of the
victim. The server then sends its next message (in DTLS, a
Certificate message, which can be quite large) to a victim
Now both these types of attacks can be mitigated, using a DTLS cookie. So, when the When the client sends its ClientHello message to the server, the server can respond with a HelloVerifyRequest message (which is defined as optional as part of the rfc)
(How it should be implemented)
How it is implemented in the Microsoft RDP protocol stack, without the ClientHelloVerify and goes straight to the setup of the DTLS connection.
However, both Citrix and Microsoft have not implemented the HelloVerifyRequest cookie as part of their remoting protocol. It should be noted that Microsoft has two ways to setup an RDP session. They can either do TCP/UDP combination for lossless connections, or using DTLS protocol (lossless connection) also known as UDP-L.
By default, it uses the UDP-R. However as notified from NETSCOUT
So as of now it means that RDP publicly available servers should have UDP disabled. This is not the same for RDP setups where you have Gateway which supports UDP since the UDP stack is not active before the client is connected. Secondly it does not affect WVD since it uses a reverse TCP socket.