6 ms·

Let's walk through this step by step because there's a lot of confusion on your end. * Step one - You connect your computer to a network - yes you'll get a DHC

Let's walk through this step by step because there's a lot of confusion on your end. * Step one - You connect your computer to a network - yes you'll get a DHCP lease, and you'll get an ip address, and a default gateway. This default route will be added to your routing table. * Step two - If the TunnelVision exploit (DHCP option 121) is at play you'll also get a few MORE SPECIFIC routes than the default gateway. These also get added to your routing table * Step three - You connect your VPN. The VPN will bring up a firewall. It will also bring up `128/1` and `0/1` routes that point at the VPN tunnel. The VPN tunnel now takes over the default route. This firewall will block all traffic that's not on the tun device (the VPN interface). Further, it will whitelist the VPN endpoint IP and create a route for it (it can do this since it already received the default gateway from the DHCP server) * Step four - Your host starts sending traffic - either this traffic will go through the VPN tunnel (the default route) OR it will attempt to go through the more specific option 121 pushed malicious routes added by the compromised DHCP server (depending on the destination ip of the outbound packets). * Step five - All traffic that would go down the malicious option 121 routes are BLOCKED by the firewall rule. Hence nullifying the TunnelVision exploit. That's all. Done. Where's the complexity in that? As i said before i've done this dozens of times. I'm talking from experience. I know this works. Further you say: > The point I'm making here is that you can't just configure a firewall rule and have it work properly. What actually needs to happen is that the VPN client software is using one routing table - let's call it "host routing" - and everything else on the system is using a second routing table - let's call that "VPN routing". You are aware we're talking about consumer VPNs right? The majority of users are on Windows and Mac. Neither of those OSes support multiple routing tables. Only Linux supports multiple routing tables. You're also just plain wrong - as i demonstrated above - you CAN just configure a firewall rule and it WILL just work properly. Again, i'm talking from experience.

Borealid 2y ago
I think you missed a step in your progression. Step one, you connect to the network and get routes. Step two, you connect your VPN. Step three, your host starts sending traffic. At this point, your firewall rules are now active and dropping any traffic you've told them to. Step four, you renew your DHCP lease and get new routes via option 121. Those routes might be malicious, or they might not. One of three things is true at step four. Either: A. Your firewall rules will block all traffic over the new routes B. Your firewal rules will not block any traffic over the new routes C. Your firewall rules will block some subset of traffic over the new routes If A is true, then your VPN tunnel goes down (undesirable), as the VPN server can no longer be contacted. If B is true, then you are vulnerable to the TunnelVision exploit. If C is true, and the subset of traffic blocked is exactly the subset intended to route over the VPN but maliciously diverted, then the VPN tunnel goes down because the firewall rules are blocking its traffic. If C is true, and somehow the firewall rule is rewriting the traffic that's pointed not-over-the-VPN to be instead routed over the VPN (by using NAT?), then the VPN tunnel stays up and there is no problem. I'd be interested in seeing the set of firewall rules that will let the VPN tunnel stay up, with management traffic going over the added-after-the-tunnel-was-brought-up next-hop, and tunneled traffic continuing to flow ignoring the new route. I haven't seen those rules in the past so if you have experience writing them, please show me. Personally I've only used Linux multiple routing tables to plug this leak. EDIT: formatting
- banister 2y ago
  No, you're wrong again. I just tested this (simulating routes added by a DHCP option 121) and it works exactly as I said. C is what happens. But it doesn't happen the way you say at all. Only the traffic heading to the new 121 routes are blocked - why is it blocked? because the routes are on the physical interface, and the firewall rules blocks all off-VPN traffic (except traffic to the VPN endpoint itself) The tunnel stays up because the tunnel connection is over the physical interface. The VPN endpoint has a physical route from the host to the VPN endpoint which is whitelisted in the firewall. So new physical routes (which option 121 would push) don't impact anything as VPN endpoint route is physical anyway. Also it's impossible for the DHCP server to push a route MORE specific than the endpoint route (which is a /32) that already exists, so it can't be overridden (and it wouldn't matter anyway since it would still be a physical route, which is what is desired here). Can you stop just talking and actually TRY it? it's all theoretical for you since you're not actually testing it and your theory is completely wrong. I am actually testing it, so i know I am correct.
  - Borealid 2y ago
    Could you please show me a rule so I can "try it"? I'd love it if this worked. Let's say: - the physical interface name is "wlan0" - the VPN virtual interface name is "tun0" - the VPN server is 10.1.1.1 on TCP port 8888 - the DHCP server on initial lease sends "0.0.0.0/0 via 10.8.8.8" - the DHCP server on renew sends the above rule and also "10.0.0.0/8 via 10.9.9.9" - Before the renew, traffic not routed via 10.8.8.8 is blocked - After the renew, traffic with a destination IP matching 10.0.0.0/8 not routed via 10.9.9.9 is blocked What should the firewall rule look like to let the VPN connection stay up both before and after the new rule, while also ensuring that traffic to 10.7.7.7 goes via the VPN and not via 10.9.9.9 or 10.8.8.8? EDIT: you keep saying "I'm wrong" but I'm just asking how this firewall rule can be structured to do what you say. It occurs to me that perhaps you're saying you can make traffic for 10.7.7.7 get blocked. But in the above, and before, what I'm asking for is how to make traffic for 10.7.7.7 continue to get sent over the VPN after the new rule addition, just like it was before - in other words, no dropped packets.
    - deleted 2y ago
pests 2y ago
In your step 4, what happens when the VPN traffic gets routed over option 121 pushed routes? Don't you block it - thus blocking your entire VPN? > OR it will attempt to go through the more specific option 121 pushed malicious routes added by the compromised DHCP server (depending on the destination ip of the outbound packets). This right here... we don't want our VPN-secued traffic going out over routes broadcast by the malicious DHCP server, so you block it... right? How does that traffic leave the local network and reach the VPN server?
- banister 2y ago
  Read my reply to the other poster, i answer exactly this. Actually test it yourself. Stop theorizing. I tested it. It works exactly as I said. I think i know where you're confused. There is a firewall whitelist on the VPN endpoint route. Also it's impossible for the DHCP server to push a route more specific than this since it's a /32 route, so it's unaffected (together with the firewall rule allowing it) by anything the DHCP server attempts to do.
  - Borealid 2y ago
    I think you might be saying to add rules like `iptables -A OUTPUT -d <vpnserver>/32 -j ACCEPT`, `iptables -A OUTPUT -o vpn0 -j ACCEPT`, and `iptables -A OUTPUT -j DROP`. I'm a bit confused though because you only mentioned one rule and that's three. But also, I think using that combination of rules would result in dropping all traffic that someone attempts this attack against - in other words, turning it into a denial-of-service attack instead of a loss-of-confidentiality one. But there's no technical need to drop the maliciously-routed traffic, is there?
    - banister 2y ago
      Yes exactly. It becomes a "denial of service" against the option 121 pushed subnet routes. That's already discussed in the paper, i assumed you knew that already. There's nothing else you can do in this situation other than detecting and then removing those routes, which is possible. In lieu of deleting the routes the best and most secure option is to block that subnet. A DoS is infinitely better than a LEAK. There are SOME things you could do (other than just removing the routes) to prevent the DoS i guess if you REALLY wanted - there is some package rewriting capabilties in the mac pf firewall and windows WFP would support this too (though it would require a 'callout' driver (kernel code) at the IP_OUTBOUND layer), and linux allows something like this too with fwmarks and multiple routing tables + a source NAT, but it's not really worth the effort in a rare case like this. Easiest just to let those packets be blocked. The network you're on is controlled by a bad actor with a malicious DHCP server. Best option for you is to GTFO.
Brian_K_White 2y ago
The only problem with this persons comments is saying "you're wrong" "you're confused" so much. The actual content is 100%. Get over the "you're wrong" tone and ingest the tech message. It's really a misnomer to call the firewall a kill switch since it isn't reacting, it's already in effect, already blocking the bad traffic before the bad traffic happens. No switch is thrown. Any vpns that DO work that way are silly and should not be used. If this is most popular commercial vpns today, oh well so be it. The articles going around saying "affects all vpns and nothing can stop it" are also just silly and wrong. But it is probably true that most convenient vpns are currently leaking.
- Borealid 2y ago
  I can see how you can write rules that block "bad traffic", but I can't see how you write them so they don't also block some "good traffic" when the network assigns a routing rule. I think the person here might be glossing over writing overzealous rules that cause the VPN connection to go down when an Option 121 route is assigned, when the ideal solution leaves the VPN functional (and causes tunneled traffic to ignore the route).
  - Brian_K_White 2y ago
    That has already been explained a couple times over.
    - Borealid 2y ago
      I don't understand your explanation because you just keep alluding to certain firewall rules but not actually showing them. If you've done this, could you paste an `iptables -L -v` for me? That would make clear exactly what you're talking about. If there is a problem, I could then point it out, and if there is not, I could then understand how to do what you're saying.

Borealid 2y ago

I think you missed a step in your progression. Step one, you connect to the network and get routes. Step two, you connect your VPN. Step three, your host starts sending traffic. At this point, your firewall rules are now active and dropping any traffic you've told them to. Step four, you renew your DHCP lease and get new routes via option 121. Those routes might be malicious, or they might not. One of three things is true at step four. Either: A. Your firewall rules will block all traffic over the new routes B. Your firewal rules will not block any traffic over the new routes C. Your firewall rules will block some subset of traffic over the new routes If A is true, then your VPN tunnel goes down (undesirable), as the VPN server can no longer be contacted. If B is true, then you are vulnerable to the TunnelVision exploit. If C is true, and the subset of traffic blocked is exactly the subset intended to route over the VPN but maliciously diverted, then the VPN tunnel goes down because the firewall rules are blocking its traffic. If C is true, and somehow the firewall rule is rewriting the traffic that's pointed not-over-the-VPN to be instead routed over the VPN (by using NAT?), then the VPN tunnel stays up and there is no problem. I'd be interested in seeing the set of firewall rules that will let the VPN tunnel stay up, with management traffic going over the added-after-the-tunnel-was-brought-up next-hop, and tunneled traffic continuing to flow ignoring the new route. I haven't seen those rules in the past so if you have experience writing them, please show me. Personally I've only used Linux multiple routing tables to plug this leak. EDIT: formatting

banister 2y ago
No, you're wrong again. I just tested this (simulating routes added by a DHCP option 121) and it works exactly as I said. C is what happens. But it doesn't happen the way you say at all. Only the traffic heading to the new 121 routes are blocked - why is it blocked? because the routes are on the physical interface, and the firewall rules blocks all off-VPN traffic (except traffic to the VPN endpoint itself) The tunnel stays up because the tunnel connection is over the physical interface. The VPN endpoint has a physical route from the host to the VPN endpoint which is whitelisted in the firewall. So new physical routes (which option 121 would push) don't impact anything as VPN endpoint route is physical anyway. Also it's impossible for the DHCP server to push a route MORE specific than the endpoint route (which is a /32) that already exists, so it can't be overridden (and it wouldn't matter anyway since it would still be a physical route, which is what is desired here). Can you stop just talking and actually TRY it? it's all theoretical for you since you're not actually testing it and your theory is completely wrong. I am actually testing it, so i know I am correct.
- Borealid 2y ago
  Could you please show me a rule so I can "try it"? I'd love it if this worked. Let's say: - the physical interface name is "wlan0" - the VPN virtual interface name is "tun0" - the VPN server is 10.1.1.1 on TCP port 8888 - the DHCP server on initial lease sends "0.0.0.0/0 via 10.8.8.8" - the DHCP server on renew sends the above rule and also "10.0.0.0/8 via 10.9.9.9" - Before the renew, traffic not routed via 10.8.8.8 is blocked - After the renew, traffic with a destination IP matching 10.0.0.0/8 not routed via 10.9.9.9 is blocked What should the firewall rule look like to let the VPN connection stay up both before and after the new rule, while also ensuring that traffic to 10.7.7.7 goes via the VPN and not via 10.9.9.9 or 10.8.8.8? EDIT: you keep saying "I'm wrong" but I'm just asking how this firewall rule can be structured to do what you say. It occurs to me that perhaps you're saying you can make traffic for 10.7.7.7 get blocked. But in the above, and before, what I'm asking for is how to make traffic for 10.7.7.7 continue to get sent over the VPN after the new rule addition, just like it was before - in other words, no dropped packets.
  - deleted 2y ago

pests 2y ago

In your step 4, what happens when the VPN traffic gets routed over option 121 pushed routes? Don't you block it - thus blocking your entire VPN? > OR it will attempt to go through the more specific option 121 pushed malicious routes added by the compromised DHCP server (depending on the destination ip of the outbound packets). This right here... we don't want our VPN-secued traffic going out over routes broadcast by the malicious DHCP server, so you block it... right? How does that traffic leave the local network and reach the VPN server?

banister 2y ago
Read my reply to the other poster, i answer exactly this. Actually test it yourself. Stop theorizing. I tested it. It works exactly as I said. I think i know where you're confused. There is a firewall whitelist on the VPN endpoint route. Also it's impossible for the DHCP server to push a route more specific than this since it's a /32 route, so it's unaffected (together with the firewall rule allowing it) by anything the DHCP server attempts to do.
- Borealid 2y ago
  I think you might be saying to add rules like `iptables -A OUTPUT -d <vpnserver>/32 -j ACCEPT`, `iptables -A OUTPUT -o vpn0 -j ACCEPT`, and `iptables -A OUTPUT -j DROP`. I'm a bit confused though because you only mentioned one rule and that's three. But also, I think using that combination of rules would result in dropping all traffic that someone attempts this attack against - in other words, turning it into a denial-of-service attack instead of a loss-of-confidentiality one. But there's no technical need to drop the maliciously-routed traffic, is there?
  - banister 2y ago
    Yes exactly. It becomes a "denial of service" against the option 121 pushed subnet routes. That's already discussed in the paper, i assumed you knew that already. There's nothing else you can do in this situation other than detecting and then removing those routes, which is possible. In lieu of deleting the routes the best and most secure option is to block that subnet. A DoS is infinitely better than a LEAK. There are SOME things you could do (other than just removing the routes) to prevent the DoS i guess if you REALLY wanted - there is some package rewriting capabilties in the mac pf firewall and windows WFP would support this too (though it would require a 'callout' driver (kernel code) at the IP_OUTBOUND layer), and linux allows something like this too with fwmarks and multiple routing tables + a source NAT, but it's not really worth the effort in a rare case like this. Easiest just to let those packets be blocked. The network you're on is controlled by a bad actor with a malicious DHCP server. Best option for you is to GTFO.

Brian_K_White 2y ago

The only problem with this persons comments is saying "you're wrong" "you're confused" so much. The actual content is 100%. Get over the "you're wrong" tone and ingest the tech message. It's really a misnomer to call the firewall a kill switch since it isn't reacting, it's already in effect, already blocking the bad traffic before the bad traffic happens. No switch is thrown. Any vpns that DO work that way are silly and should not be used. If this is most popular commercial vpns today, oh well so be it. The articles going around saying "affects all vpns and nothing can stop it" are also just silly and wrong. But it is probably true that most convenient vpns are currently leaking.

Borealid 2y ago
I can see how you can write rules that block "bad traffic", but I can't see how you write them so they don't also block some "good traffic" when the network assigns a routing rule. I think the person here might be glossing over writing overzealous rules that cause the VPN connection to go down when an Option 121 route is assigned, when the ideal solution leaves the VPN functional (and causes tunneled traffic to ignore the route).
- Brian_K_White 2y ago
  That has already been explained a couple times over.
  - Borealid 2y ago
    I don't understand your explanation because you just keep alluding to certain firewall rules but not actually showing them. If you've done this, could you paste an `iptables -L -v` for me? That would make clear exactly what you're talking about. If there is a problem, I could then point it out, and if there is not, I could then understand how to do what you're saying.