Opened 19 months ago
Last modified 18 months ago
#1340 new Bug / Defect
UDP reflection amplification attack
Reported by: | mtaggart | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Generic / unclassified | Version: | |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: | Steffan Karger, tct |
Description
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:
- 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
Change History (5)
comment:2 Changed 19 months ago by
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.
comment:3 Changed 19 months ago by
Cc: | Steffan Karger added |
---|
comment:4 Changed 19 months ago by
Cc: | tct added |
---|
comment:5 Changed 18 months ago by
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).
The server operators need to use
tls-auth
ortls-crypt
.Both will make the server stop responding to unauthenticated packets.