A few days ago it was released an attack technique (CVE-2019-14899), which Allows you to replace, change or substitute packets on TCP connections forwarded through VPN tunnels. The problem It affects Linux, FreeBSD, OpenBSD, Android, macOS, iOS, and other Unix-like systems.
The method allows packet substitution at the level of TCP connections that pass inside the encrypted tunnel, but it does not allow connection in connections using additional layers of encryption (for example, TLS, HTTPS, SSH). The encryption algorithms used in VPNs do not matter, as the bogus packets come from the external interface, but the kernel processes them as packets from the VPN interface.
The most likely target of the attack is to interfere with unencrypted HTTP connections, but the use of the attack to manipulate DNS responses is not excluded.
Successful package replacement has been proven for tunnels created with OpenVPN, WireGuard and IKEv2 / IPSec.Tor. It is not affected by the problem as it uses SOCKS to forward traffic and joins the loopback interface.
For IPv4, an attack is possible if rp_filter is put into Loose mode. The rp_filter mechanism is used to additionally verify packet routes to avoid spoofing the source address.
- When set to 0, the source address is not verified and any packets can be redirected between network interfaces without restrictions.
- Mode 1 "Strict" includes verifying that each packet arriving from outside complies with the routing table, and if the network interface through which the packet was received is not connected to the optimal response delivery path, the packet is discarded.
- Mode 2 "Loose" smooths the test to allow operation when using load balancers or asymmetric routing, where the response path may not go through the network interface over which the incoming packet arrived.
In "Loose" mode, it is checked that the incoming packet complies with the routing table, but it is considered valid if the source address can be accessed through any available network interface.
To carry out an attack:
First the gateway through which the user enters must be controlled to the network (for example, through the MITM organization, when the victim connects to a wireless access point controlled by the attacker or via a hacked router).
By controlling the door link through which the user is connected to the network, the attacker can send dummy packets They will be perceived in the context of the VPN network interface, but the responses will be sent through the tunnel.
When generating a dummy packet stream in which the IP address of the VPN interface is replaced, an attempt is made to influence the connection established by the cliente, but the influence of these packets can only be observed through passive analysis of the encrypted traffic flow associated with the operation of the tunnel.
To carry out an attack, you need to find out the IP address of the tunnel network interface assigned by the VPN server and also determine that the connection to a specific host is currently active through the tunnel.
To determine the IP of the VPN interface of the virtual network, packets are sent to the SYN-ACK packets of the victim's system, sequentially ordering the entire range of virtual addresses.
Similarly, the presence of a connection to a specific site is determined and the port number on the client side: ordering the port numbers to the user, a SYN packet is sent as the source address in which the site IP is substituted, and the destination address is virtual VPN IP.
Server port can be predicted (80 for HTTP), and the port number on the client side can be calculated by brute force, analyzing for different numbers the change in the intensity of the ACK responses in combination with the absence of a packet with the RST flag.
At this stage, the attacker knows the four elements of the connection (source IP address / port and destination IP address / port), but to generate a dummy packet that the victim system will accept, the attacker must determine the sequence and recognition numbers (seq and ack) TCP -connections.
Solution.
Finally for protection when using tunnels with IPv4 addresses, it is enough to establish rp_filter in "Strict" mode
sysctl net.ipv4.conf.all.rp_filter = 1
On the VPN side, the method of determining the sequence number can be blocked by adding extra padding to the encrypted packets, making the size of all the packets the same.
Excellent security contribution, especially in these times when security attacks have increased. Thanks and regards.