M0dEx / quincy

QUIC-based VPN
MIT License
114 stars 11 forks source link

Handle CVE-2024-3661 (TunnelVision) #69

Open M0dEx opened 6 months ago

M0dEx commented 6 months ago

A new decloaking technique for nearly all VPN implementations has been found, which allows attackers to inject entries into the routing tables of unsuspecting victims using DHCP option 121. This allows attackers to redirect traffic, which is supposed to be sent encrypted over the VPN, through the physical interface handling DHCP for the network the victim's computer is connected to, effectively bypassing any and all confidentiality provided by the VPN.

This attack vector can be partly mitigated in different ways on different systems, such as Network Namespaces on Linux. However, apart from disabling DHCP option 121 on all DHCP clients, this attack vector is very difficult to completely mitigate.

More information about this attack can be found on the Leviathan Security blog.

This issue is meant for tracking any and all possible mitigations on Quincy's side, to provide at least some protection against this attack vector, as malicious (and state) actors might use it (or already are using it) as a major decloaking attack vector.

M0dEx commented 6 months ago

Documented in a security advisory: https://github.com/M0dEx/quincy/security/advisories/GHSA-hqmp-g7ph-x543

M0dEx commented 6 months ago

The workarounds for this will likely have to be platform-specific, as different platforms allow different mitigations of this attack.

On Linux, Network Namespaces might be a good way to work around this issue, if supported by most distributions. On MacOS, it might be a good idea to monitor routes and identify malicious ones, which are attempting to redirect traffic from Quincy. On Windows, it might be possible to monitor routes as well.