A group of researchers from Canadian and American universities has developed the Port Shadow attack technique, which allows for the manipulation of address translation tables on the VPN server side to send responses to requests from another user connected to the same VPN server. This method can be used for intercepting or redirecting encrypted traffic, conducting port scans, and de-anonymizing VPN users. An example is provided showing how this method can be used to redirect a user's DNS queries to the attacker's host, using a VPN server to which the attacker can connect as a client.
To carry out the attack, the attacker needs to be able to connect to the same VPN-server as the victim, which is possible, for example, when using standard VPN providers and public VPN services that offer access to anyone. The vulnerability affects VPN servers that use address translation (NAT) to manage client access to external resources, provided that the same IP address is used for receiving traffic from clients and sending requests to external websites. server The same IP address must be used.
The attack is based on the fact that by sending specially crafted requests, the attacker, connected to the same VPN server and using shared NAT, can distort the content of the address translation tables, leading to packets intended for one user being sent to another user. In the address translation tables, information about which internal IP address is associated with the sent request is determined based on the number of the originating network port used to send the request. By sending certain SYN and ACK packets and simultaneously manipulating both the client connection to the VPN server and the controlled external attacker's server, the attacker can create a collision in the NAT table and add a record with the same originating port number, but associated with their local address, resulting in responses to someone else's request being returned to the attacker's address.
During the study, address translation systems of Linux and FreeBSD were tested in conjunction with OpenVPN, OpenConnect, and WireGuard VPNs. The FreeBSD platform proved resistant to request redirection attack methods from other users connected to the same VPN. NAT substitution was only possible during the ATIP (Adjacent-to-In-Path) attack, where the attacker can intercept traffic between the user and the VPN server (for example, when the user connects to a Wi-Fi network controlled by the attacker) or between the VPN server and the target site. Additionally, NAT FreeBSD was affected by the attack that can confirm if a user is connected to a specific site (Connection Inference).
In the case of Linux, the Netfilter subsystem was vulnerable to attacks that allow entry in the address translation table, redirecting incoming packets to another user, sending packets outside the encrypted VPN channel (Decapsulation), or determining open network ports on the client side.
As measures to block the attack, VPN providers are recommended to use adequate methods for randomizing source port numbers in NAT, limit the number of simultaneous connections to the VPN server from a single user, and block the client's ability to choose the network port that accepts requests on the VPN server side.
According to a representative from Proton AG, the attack does not affect VPN services that use separate IPs for incoming and outgoing requests. Additionally, there are doubts about the attack's applicability to real VPN services, as a successful attack has only been demonstrated in laboratory tests and requires specific conditions on the VPN server and targeted client side. Furthermore, the attack may only be useful for manipulating unencrypted requests, such as DNS queries, while the use of TLS and HTTPS at the application level renders traffic redirection ineffective.
Address translation table manipulation attacks are applicable not only to VPNs, but also to wireless networks where NAT is used for connecting users to external resources at the access point. Last month, results were published from a study on the possibility of conducting a similar attack to intercept TCP connections of other users on a wireless network. The attack method proved effective on 24 out of 33 tested wireless access points.
The proposed Wi-Fi attack turned out to be significantly easier than the aforementioned method for VPNs, as many access points do not check the sequence numbers in TCP packets due to optimizations. As a result, it was sufficient to send a spoofed RST packet to clear the entry in the address translation table and then direct the response to the attacker's host to determine the necessary sequence (SEQ) and acknowledgment (ACK) numbers for intercepting the TCP connection.
Source: opennet.ru
