Hacker News new | past | comments | ask | show | jobs | submit login

Pretty sure the attacker has to control your DHCP server, which in ex. a home environment is usually the router.



No, the attacker just has to be on the network. When on the network the attacker can deploy various techniques to become the DHCP server. Since it's (relatively) easy to become a DHCP server on a network, it's considered a big deal when the DHCP server can trick you into doing something like in this case decloaking your VPN traffic.


What is the fix for this vulnerability? Is it the router that needs to get a software update, the VPN client, the OS, or some/all of the above?


The OS needs an extra feature, and then clients need to make use of that feature. There's other workarounds listed in the "Mitigations" section of the post. But the problem is basically that everything is working as intended, for example if you disable the "Option 121" feature then under certain circumstances you might not have internet connection. Apparently Android devices don't support Option 121 at all, and it makes them unaffected by this vulnerability, but also causes to sometimes not be able to connect to networks.


This is mostly correct, in our POC video we showcase a lab where we go from being an adjacent host on the network to being the DHCP server.

We did this by DHCP starving the true DHCP server and hoarding all the leases. Then we serve our own and do not have to compete with the true DHCP.

There’s network protections against this such as guest network isolation or switches with DHCP snooping protections. However, those are usually on enterprises and relying on those being in place kind of removes the point of “securing an untrusted network” like many VPN providers claim.


You should play with IPv6, you can bypass IPv6 RA Guard on some switches (including Cisco) https://blog.champtar.fr/VLAN0_LLC_SNAP/, allowing attacks in 'trusted' networks


Many networking switches/systems (e.g. UniFi from Ubiquiti) let you enable DHCP Snooping which drops Layer 2 traffic from rogue DHCP servers to prevent this:

https://en.wikipedia.org/wiki/DHCP_snooping


I invite you to not trust blindly L2 security features, anything that use denylist approach can miss some corner cases, have a good read :) https://blog.champtar.fr/VLAN0_LLC_SNAP/


Interesting write up! I typically use multiple-WLANs as well as guest-isolation on the "guest" network which further reduces the attack surface. All of the network infra also runs on a separate management VLAN and (by default) switch ports are on the guest network so if someone randomly plugs in to a ethernet jack, they're not getting on the MGMT lan. Maybe not perfect, but certainly better than your average Comcast/Verizon/Orange/SFR setup!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: