Using an obscure DHCP feature to abuse your VPN connection

[Viktor Jaep]

Trying to wrap my head around this one... even if they could still create a way to re-route your VPN connection traffic, they would still need to get through some serious encryption.

Why Your VPN May Not Be As Secure As It Claims – Krebs on Security

 

[Tech9]

The way it is described - the attacker has to have access to your LAN first. VPN tunnel encryption doesn't come into play because the client traffic is re-routed around it. This thing needs knowledge about the network, time to plan plus extra hardware/software to execute. In a corporate environment it will be caught as suspicious activity perhaps immediately. The idea looks similar to common IPv6 leaks happening "automatically" on home routers, but done in a more sophisticated way using single protocol.

 

[Viktor Jaep]

The way it is described - the attacker has to have access to your LAN first. VPN tunnel encryption doesn't come into play because the client traffic is re-routed around it. This thing needs knowledge about the network, time to plan plus extra hardware/software to execute. In a corporate environment it will be caught as suspicious activity perhaps immediately. The idea looks similar to common IPv6 leaks happening "automatically" on home routers, but done in a more sophisticated way using single protocol.

Which is why setting up a rogue DHCP server at a Starbucks would make this threat a reality. I'm just really curious how they're able to prevent encryption of traffic between your network interface and the VPN provider through the means of routing in order to snoop. Need to read up more on this. Ugh.

 

[Tech9]

Need to read up more on this.

Bill Woodcock has an SNB Forums account. Perhaps he can give you some details and jumpstart your HACKMON v1.0.1 project.

 

[Viktor Jaep]

Bill Woodcock has an SNB Forums account. Perhaps he can give you some details and jumpstart your HACKMON v1.0.1 project.

This is actually a good explainer... https://www.leviathansecurity.com/blog/tunnelvision

 

[sfx2000]

This is actually a good explainer... https://www.leviathansecurity.com/blog/tunnelvision

This has always been a consideration with OpenVPN especially, as the jump from kernel to userspace has always been problematic... the fact that OpenVPN is portable as an application puts it at risk of the host OS...

Same would go with many of the SSL-VPN approaches - GlobalConnect, etc...

L2TP-IPsec and WG work at a network interface level at Layer 2. I'm not seeing an issue there directly, however, going into a public VPN provider is always a risk.

 

[Viktor Jaep]

I wonder if there's a way to catch something like this in the act... it should be highly usual for DHCP to change your routes. Just need to something to catch it in the act, deny it, and keep existing routes in place.

 

[sfx2000]

I wonder if there's a way to catch something like this in the act... it should be highly usual for DHCP to change your routes. Just need to something to catch it in the act, deny it, and keep existing routes in place.

It's always been there at a carrier level...

Content Optimization is one thing, but it's also CSAM (kiddie porn) - not saying that carriers are curating content, and CALEA also comes into play if warranted...

Thing is - VPN's at Layer 3 were NEVER private - whether it was Citrix or Sandvine - that was their reason for being...

Think items like the GreatFirewall of China - same stuff happens outside of the PRC...

 

[PR3MIUM]

The most effective fixes are to run the VPN inside of a virtual machine whose network adapter isn’t in bridged mode or to connect the VPN to the Internet through the Wi-Fi network of a cellular device.

https://petsymposium.org/popets/2015/popets-2015-0006.pdf

 

[Twiglets]

https://petsymposium.org/popets/2015/popets-2015-0006.pdf

If I understand the original issue and the above referenced .pdf.

It would appear that a possible solution would be to access 'your' dns resolver through the vpn connection *only* & block any other access to dns outside of the vpn connection.
Any attempt to use an 'outside' dns resolver should/would get no reply ..... for maximum safety the vpn client, on detecting the 'outside' dns resolution attempt/reply, would drop and remake the vpn connection to establish a 'clean' connection setup.

This of course means that the vpn client needs to be changed to monitor dns traffic & the routes taken.