UDP reflection amplification attack

[mtaggart]

I run a server that was subject to a DDoS attack today that appears to be a UDP reflection amplification attack coming from openvpn. I have searched the bug tracker, forums, CVEs, source, etc and could not find any mention of such a vulnerability, so I am asking here. Apologies if this is already solved or not an issue, but I was unable to determine so maybe at least it would help to document things.

What I am seeing is floods of P_CONTROL_HARD_RESET_SERVER_V2 packets coming from port 1194 on hundreds of source IPs. I searched around and found some things that might be related:

• Maybe the original vulnerability description ​https://www.freebuf.com/vuls/215171.html
• Maybe related articles:
  • ​https://www.netscout.com/sites/default/files/2020-02/SECR_001_EN-2001_Web.pdf
  • ​https://govcyberhub.com/2020/03/26/new-vectors-new-techniques-the-evolution-of-ddos-attacks/
  • ​https://nsfocusglobal.com/what-you-should-know-about-openvpn-reflection-attacks/
• Bug in SoftEtherVPN (maybe based on openvpn? source looks different) with a good description and a python script POC ​https://github.com/SoftEtherVPN/SoftEtherVPN/issues/1001

I plan to contact the network admins of the IPs used in the attack and I would like to include information on what course of action they should take.

Thanks

[Gert Döring]

The server operators need to use tls-auth or tls-crypt.

Both will make the server stop responding to unauthenticated packets.

[Gert Döring]

There are two patches floating around that rate-limit responses to P_CONTROL_HARD_RESET_SERVER_V2 on servers that do not use either, but these have not been merged to the official repos yet, so it's not "patch the server and all is good" easy.

OTOH, tls-auth has other security benefits for the openvpn deployment, so it's a good idea for multiple reasons.

[Steffan Karger]

The reflection part is somewhat inherent to UDP, though indeed tls-auth, tls-crypt and tls-crypt-v2 can restrict such attack to attackers actually holding valid key. This helps, but is of limited use for e.g. VPN providers.

We might be able to do something about the amplification though. The OpenVPN three-way handshake consists of a HARD_RESET_CLIENT_V2 (or V3), HARD_RESET_SERVER_V2 and ACK_V1 packet. If a malicious client only sends a HARD_RESET_CLIENT_V2, and doesn't reply to the HARD_RESET_SERVER_V2, the server will retry sending its reply four times. If the server would not retry this specific packet, we would get rid of most of the amplification.

A small amplification remains: a HARD_RESET_CLIENT_V2 packet has 14 bytes UDP payload (58 bytes packet), the HARD_RESET_SERVER_V2 reply has 26 bytes UDP payload (70 bytes packet).

[Gert Döring]

Intermediate update: as of 2.6.0, an OpenVPN Server will only send a single reply packet to an incoming HARD_RESET_CLIENT* packet, ever (and not keep state, so it couldn't resend the HARD_RESET_SERVER* even if it wanted to). So while reflection attacks are still possible, the amplification factor has been taken care of.

What we still want to add is per-source rate limiting to make sure that OpenVPN is made sufficiently uninteresting as a reflection point. @plaisthos is working on this.

That all said, server operators still should use tls-auth or tls-crypt* :-)

[Gert Döring]

Update again. The "initial packet rate-limit" patch has landed, so with 2.6.0 and up, the default is "100 initial packets per 10 seconds will be replied to" (and connections that succeed their 3way-handshake are not counted in that number).

In our tests this does not impair "large servers starting up with lots of new clients connecting" very strongly (because successfull connections do not count), and it makes OpenVPN fairly uninteresting for reflection attacks.

commit b520c68c67b6e52cd71b16675f1c436abf18d4dc (master)
commit 93d8d92319816a36f53ef8772bd6705f6abc2df9 (release/2.6)
Author: Arne Schwabe
Date: Tue Jan 10 02:59:01 2023 +0100

Add connect-freq-initial option to limit initial connection responses

... this is still not exactly what we wanted (do this on a per-ip/per-subnet basis), but that turned out to be more complex and 2.6.0 release is very close.

So, bumping the milestone to 2.7 for the "really nice" rate-limiter.