I read this article today (in German, need to translate to English via Chrome):
There seems to be an issue with DHCP protocol, allowing to set routes via DHCP, which would compromise any VPN on the router, because it would bypass the VPN gw.
Here an English article about it:
I would ask Glinet support to look into the issue, and work out a fix for this issue. Glinet mobile routers are advertised to use in open WLAN like hotels, and have VPN protection. This issue would bypass the VPN if there is a compromised open WLAN with DHCP server.
From my point of view, this should not affect routers at all.
Even if the DHCP is compromised, this wouldn’t stop the VPN encryption. So, the traffic might flow through other routes on WAN side - but since you never know about WAN side anyway, this won’t change security.
It would affect devices behind your own router, however, because here somebody can create a new route and sniff your unencrypted traffic before it reaches the router itself. But this would be possible while running Wireshark as well (depends on the network, but mostly yes).
So I am not really aware what’s the deal with this CVE at all.
From my point of view, it’s only dangerous for devices running local VPN solutions with a 0.0.0.0/0 route. So not about routers.
I dont think that is true. Did you watch the video above or read the article?
As I understand it works like this:
Glinet mobile router for example a GL-MT300N-V2 logs into an open WLAN, for example a hotel or cafe, which has a malicious open wlan. The Glinet mobile router gets a IP via DHCP including the malicious DHCP setting setting routes through a prepared man in the middle server. The route bypasses any route set by the VPN tunnel.
I am not convinced that OpenWrt would accept a route set by DHCP, but this needs to be tested.
And I think it’s different with OpenWrt anyway because it’s not only about routes but interfaces as well.
As you can see, option 121 is valid and broadcasted. (Content of the route itself doesn’t matter)
Testing
I connected my SFT1200 (LAN) to my XE3000 (WAN) to simulate a connection with a travel router to a tempered network. The SFT1200 got an IP address from the specific range.
I would say that OpenWrt routers are not vulnerable in that case. Because sending the traffic to the new route is fine - even if it’s an evil device.
Maybe I missed something during testing, please let me know.
Again, not true! the VPN encryption would be de-cloaked by this attacking vector! If you use encrypted protocols such as HTTPS/SSH then you would be safe. Refer to Requirements for decloaking VPN traffic on the blog.
It’s in fact an interesting vulnerability as it involves: rogue DHCP server plus using Option 121 to decloak VPN packets through a physical interface!
Incorrect! It affects any *nix-based system connected to a VPN. The routes you referred to are part of the exploitation process!
Correct!
It does! refer to the researcher’s blog and test it against your GL device.
Your lab and testing are not correct! You need to understand the blog and watch the video first.
Please read carefully the blog details before executing it in your lab. By the way, there is an OVA image which you can download to replicate the attack. This helps you to understand the inner details before testing it on a GL device.
Thanks, I understand the technique. But the most important part is:
Our technique is to run a DHCP server on the same network as a targeted VPN user and to also set our DHCP configuration to use itself as a gateway.
If you only connect by your router, not by the evil router, it’s fine as long as nobody tempers your network. But as soon as you let other people use your travel routers network, they can sniff the traffic already.
I just shake my head at this whole issue. Why does it even have a CVE? This is a rogue DHCP server sending out legitimate DHCP options. They are using it wrong, that is all. There is nothing new to this, rogue DHCP servers have been an issue for a long time. All your data in your VPN will remain private.Traffic that was supposed to be routed over your VPN may end up on the public internet side instead of within your VPN. But this will likely be TCP SYN packets which should not get to their destination if not traversing the VPN. An attacker might get some additional information about your network architecture, ip addresses, dns names, but not access to your traffic.
If you are using software clients on your device, and it is sitting behind a NAT device (travel router like gl has), you have little to worry about. If that traffic is directed to a malicious server it is still encrypted. If you are really concerned, set up a firewall rule on your client prohibiting all external outbound and inbound traffic on any interface except your VPN connection andmore importantly quit using public wifi.
Only devices with software clients, connected directly to a tampered network, are in danger. But they are anyway because - well - they connect to a public network.
Not sure about that. Depends on how Windows(/or the client) handles routes. If the 0.0.0.0/1 route is higher than the software route created by the VPN client, it might be possible that the plain traffic will be sent to the evil route instead of the VPN.
But won’t happen behind NAT.
We use DHCP option 121 to set a route on the VPN user’s routing table. The route we set is arbitrary and we can also set multiple routes if needed. By pushing routes that are more specific than a /0 CIDR range that most VPNs use, we can make routing rules that have a higher priority than the routes for the virtual interface the VPN creates. We can set multiple /1 routes to recreate the 0.0.0.0/0 all traffic rule set by most VPNs.
Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface. This is intended functionality that isn’t clearly stated in the RFC. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.
From the first glance I had thought the same! But after reading the blog it does go deeper into other issues! This is not a classic old-school rogue DHCP server attack!
This CVE involves utilizing DHCP Option 121 to add a static router that is not clearly defined by the relevant RFC! Not only this, a strange behavior occurs: where a phy interface that receives the DHCP 121 packet sends begins to send the VPN traffic that is SUPPOSED to be encrypted and sent through a VPN virtual tunnel using the phy interface in CLEAR-TEXT!
You data that should be going through the VPN will not be acked by the VPN endpoint. You will not be able to complete that connection with an ACK back from the destination host. No session, no data. If your traffic is UDP, the network protocol itself doesn’t have an session, but most applications using UDP protocols do sessioning within the app to track packets. Again, there may be some UDP traffic exposed, if it is in plaintext and the application does not have a method to authenticate (wireguard) or track sessions. But I am not sure what applications with sensitive or critical data that might include. Any other traffic that is encrypted (https, smtps, ssh) would be visible to the attacker, but still encrypted anyway.
The tldr (how did you get this far without reading lol?) is that if you are using the VPN to protect your data, carry one. If you are using the VPN to mask your IP, this might be a concern. Take other precautions, which should have been in place even without this if your life depended on privacy.
But that’s because the interface and the package do not know about encryption at all. So it will be sent to the right interface with the correct routing rules. So it’s not like really by-passing - more like doing what networking is made of.
The security flaw could be easily corrected by omitting dhcp option 121. Never seen this anyway, tbh.
I think you are wrong here: The package will be redirected from application layer to the attackers’ server - without even knowing about the existence of VPN. So there is no ACK problem at all. And it mostly will be TCP because the application will try to talk to the Internet just like usual.
I use Option 121 internally. It is fine to use and has legitimate purposes. Setting the incorrect route metrics can do this as well. You don’t need anything to test this specific to DHCP. Create static routes on your laptop running the VPN and you can do the same thing. It is how split tunneling works by design really. This is a way that could create a split tunnel where it is not desired, but how are you going to connect to enterprise resources going out the regular internet connection instead of the VPN? You won’t. So what other than dns names or ip addresses are given up here? Plus your VPN is not working - that is a huge clue, right? If they are trying to discover your real IP, this is an issue as they could create a specific route to an external server not over your vpn that would give that away. It is an issue, but it will not lead to enterprise or home network compromise except in very narrow situations that may not even exist.
But the main conclusion is the same as before: Your router isn’t affected as long as you use routing mode and your device is only connected to your GL.iNet router.
That’s what I am saying: once the VPN traffic gets decloakd using this CVE, your all network traffic (including destinations IPs) are exposed - with the exception to the encrypted protocols such HTTPS/SSH…etc
