A few days ago the news was presented aboute a new method of attacking connections used by VPNs, which was developed jointly by researchers from Canadian and American universities.
Baptized under the name of "Port Shadow" this attack method allows, by manipulating the address translation tables on the VPN server, send responses to requests directed to another user connected to the same server. The attack can be used to intercept or redirect encrypted traffic, perform port scans, and anonymize VPN users. For example, a user's DNS traffic can be redirected to an attacking host.
How does a “Port Shadow” attack work?
Port Shadow It is based on that:
By sending specifically crafted requests, an attacker connected to the same VPN server and using shared NAT can alter the address translation tables. This causes packets addressed to one user to be sent to another. The information in the NAT tables about which internal IP address is associated with a request is based on the source port number.
An attacker can cause a NAT table collision through crafted packets and simultaneous changes to the client's connection to the VPN server and to the attacker's external server, creating an entry with the same source port number, but associated with its own local address, causing responses to be sent to the attacker's address.
To execute the attack, The attacker must be connected to the same VPN server as the victim, which is feasible in public VPN services that allow general access (OpenVPN, WireGuard, OpenConnect). The vulnerability affects VPN servers that use address translation (NAT) to manage client access to external resources, and where the server uses the same IP to receive traffic from clients and send requests to external sites.
Vulnerable VPN systems and services
En the study is mentioned which Evaluated address translation systems on Linux and FreeBSD along with public VPN services, such as OpenVPN, OpenConnect and WireGuard. The study revealed that FreeBSD showed no vulnerability to redirect attacks of requests made by other users on the same VPN, but more serious attacks are still possible.
Manipulation of NAT tables was only possible during an ATIP attack (Adjacent-to-In-Path), where an attacker can intercept traffic between a user and a VPN server (for example, by connecting to a Wi-Fi network controlled by the attacker) or between the VPN server and the destination. Additionally, NAT on FreeBSD was also vulnerable to an attack that allows determining whether a user is accessing a specific site (Connection Inference).
On Linux, the Netfilter subsystem proved susceptible to attacks replacement of address translation tables, allowing you to redirect incoming packets to another user, send packets outside the encrypted VPN channel, or detect open network ports on the client side.
Mitigation
The researchers mention that to mitigate the attack, VPN providers are recommended to implement techniques to randomize numbers of source port in NAT, limit the number of simultaneous connections allowed to the VPN server per user, and restrict the ability of the client to select the port that receives requests on the VPN server.
A Proton AG representative commented that:
The attack does not affect VPN services that use different IP addresses for incoming and outgoing requests. Furthermore, there are doubts about the feasibility of the attack on real VPN services, as it has so far only been successfully demonstrated in laboratory tests, requiring specific conditions on both the VPN server and the attacked client. The attack is also less effective against encrypted traffic, such as TLS and HTTPS, since its main use is in manipulating unencrypted requests, such as DNS queries.
Additionally, attacks that manipulate address translation tables affect not only VPNs, but also wireless networks that use NAT on the access point to connect users to external resources. Last month, a study revealed that a similar attack could intercept TCP connections from other users on wireless networks, being effective in 24 of the 33 wireless access points tested.
The proposed attack for Wi-Fi networks turned out to be much simpler than the method for VPN. This is because many access points, when employing optimizations, do not check the accuracy of sequence numbers in TCP packets.
Finally, if you are interested in knowing more about it, you can check the details in the following link