UDP reflection amplification attack

[Alchiadus]

SoftEther is vulnerable to a UDP reflection amplification attack and can be abused to take on the role of the reflector.

We discovered the issue in production and were able to stop the attack at the firewall level by blocking all UDP traffic to SoftEther's listening ports, since we only support TCP at the moment.

Description

The attacker spoofs the IP address of the victim and uses it to send a UDP packet containing P_CONTROL_HARD_RESET_CLIENT_V2 to the server. SoftEther will respond to the victim with P_CONTROL_HARD_RESET_SERVER_V2. Since the victim will not reply with a P_ACK_V1, SoftEther assumes the packet got lost in transmission and will retransmit P_CONTROL_HARD_RESET_SERVER_V2 every OPENVPN_CONTROL_PACKET_RESEND_INTERVAL milliseconds (default 0.5 seconds) until the socket times out (default 30 seconds), resulting in an amplification factor of 60.

The attack is described in detail here: http://13.58.107.157/archives/8190.

Reproduction

I included a Python script that demonstrates the amplification attack (see udp_1194_amplification.py) and an example capture that shows the result (see udp_1194_amplification.pcapng).

udp_1194_amplification.zip

Mitigations

The attack could be mitigated by implementing an exponential backoff strategy similar to how OpenVPN does it (as shown on the page that describes the attack in detail), which would result in an amplification factor of 5 rather than 60.

Ideally, SoftEther would rate limit IPs, thus preventing the creation of a new session if that IP's limit has been reached.

[paulmenzel]

Thank you for the analysis. Our instance was used for this kind of attack already.

[dnobori]

Alchiadus,

Thank you for discovering it. It is OpenVPN original protocol's vulnerability.

I have an idea to address this protocol vulnerability.
In the processing of OPENVPN_P_CONTROL_HARD_RESET_CLIENT_V2, it is easy to disable the re-transmission mechanism completely. In this case, the packet loss of OPENVPN_P_CONTROL_HARD_RESET_CLIENT_V2 will be a connection problem. However, we can assume that the VPN client will re-send the P_CONTROL_HARD_RESET_CLIENT_V2 request packet soon, and the problem will solved.

How you you think about this idea?

[paulmenzel]

@dnobori, yes, that sounds reasonable.

[dnobori]

Good, good, I am willing to implement the above solution.

[Alchiadus]

I think that would work. I tried to test what would happen if SoftEther were not to send the P_CONTROL_HARD_RESET_SERVER_V2 to simulate packet loss and the OpenVPN client indeed seems to retransmit the P_CONTROL_HARD_RESET_CLIENT_V2 about 3 times until a TLS timeout occurs after 10 seconds.

With the proposed change, SoftEther will still continue to transmit one P_CONTROL_HARD_RESET_SERVER_V2 for every P_CONTROL_HARD_RESET_CLIENT_V2 it receives (even if the same IP address sends it many times per second), so I still believe rate limiting would be a nice feature to have in SoftEther, but not retransmitting the P_CONTROL_HARD_RESET_SERVER_V2 will drastically reduce the impact of this particular attack.

[dnobori]

SoftEther will still continue to transmit one P_CONTROL_HARD_RESET_SERVER_V2 for every P_CONTROL_HARD_RESET_CLIENT_V2 it receives (even if the same IP address sends it many times per second)

I suppose that the above behavior is not a problem. It doesn't behave as amplifier.

[davidebeatrici]

Fixed in #1014.

[Alchiadus]

Thank you for the quick response and fix.

[dnobori]

Please kindly test it.

[Alchiadus]

I can confirm the fix addresses the amplification issue: after sending a P_CONTROL_HARD_RESET_CLIENT_V2 I get at most one P_CONTROL_HARD_RESET_SERVER_V2 back.