Skip to main content
Topic: Inferring and hijacking VPN-tunneled TCP connections (Read 208 times) previous topic - next topic

Inferring and hijacking VPN-tunneled TCP connections

Has anyone else been following this bulletin that was published on seclists earlier this December?

https://seclists.org/oss-sec/2019/q4/122

So far, it seems like this vuln might not be the end of the world, but I was just wondering what perspective the posters here might have regarding this?

Re: Inferring and hijacking VPN-tunneled TCP connections

Reply #1
https://www.reddit.com/r/netsec/comments/e6keg1/cve201914899_inferring_and_hijacking_vpntunneled/

Pretty sure its something that needs patched in Linux kernel, not necessarily a fault in OpenVPN or WireGuard.

https://www.reddit.com/r/PFSENSE/comments/e6wynw/cve201914899_inferring_and_hijacking_vpntunneled/

Quote
It seems like this attack requires the attacker to be in control of an upstream device within the same subnet, like an access point, and using it to try to open a TCP connection to every possible address in the private address space, hoping that the Linux device will respond to one of the packets with a RST packet, even though that is the wrong interface for that IP address. Linux devices implementing a weak IP model may allow responding to packets destined for a different IP than what is on that interface as long as the IP is on some interface. I believe that pf implements a strong IP model requiring IP packets to come in on the correct interface, so that might defeat this, but I'm not sure. It seems like the most vulnerable target would be someone running a recent version of Linux on their laptop, who is also using a VPN to protect themselves while using a sketchy/untrusted WiFi network. To attack a pfSense router, the packets would need to come from inside your ISP's subnet, but I think that most ISPs would not forward RFC1918 packets from one subscriber to another, so the packets would probably have to be coming from your ISP itself. I guess the equivalent to the create_ap component would be the CPE. pfSense blocks RFC1918 traffic by default, although you can change this in your settings. However, I'd say that if your ISP is injecting bogus traffic to try to hack your pfSense VPN via the provided cable modem, maybe you have bigger problems, and should consider ending your contract with them. File this issue under "meh."

Seems like it would be a difficult attack to pull off too, I don't think its as detrimental as some people are acting...Hopefully a kernel patch or something can fix it and put the whole thing to rest,