Novel attack against virtually all VPN apps neuters their entire purpose

Comments

• adam_y@lemmy.world ⁨6⁩ ⁨months⁩ ago

  “There are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android.”

  So there are ways.

  source

  • Rin@lemm.ee ⁨6⁩ ⁨months⁩ ago

    Common Linux w

    source

    • NeatNit@discuss.tchncs.de ⁨6⁩ ⁨months⁩ ago

      Not really, Linux is still vulnerable and there is a mitigation but it opens a side channel attack.

      source
  • sugar_in_your_tea@sh.itjust.works ⁨6⁩ ⁨months⁩ ago

    Android

    Except sometimes.

    source
  • FridaG@reddthat.com ⁨6⁩ ⁨months⁩ ago

    True, if you neg a linux dev online enough for two years, you can make your entire infrastructure vulnerable to attack

    source
  • pineapplelover@lemm.ee ⁨6⁩ ⁨months⁩ ago

    Wait so the vulnerability exists on macos and iphone even though those are based on bsd (right?)

    source

    • Natanael@slrpnk.net ⁨6⁩ ⁨months⁩ ago

      Hilariously enough, Windows users can use WSL to run a Linux VPN (but only applications running in WSL are safe if I understand the attack right)

      source
  • lurch@sh.itjust.works ⁨6⁩ ⁨months⁩ ago

    This is the way

    source
  • Railing5132@lemmy.world ⁨6⁩ ⁨months⁩ ago

    Hate to rain on the Linux parade here, but didn’t the article say: “There are no ways to prevent such attacks except when the user’s VPN runs on Android.” and that Linux was just as vulnerable as Windows?

    source

    • 0xD@infosec.pub ⁨6⁩ ⁨months⁩ ago

      It’s not as vulnerable but it still is.

      Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn’t implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.

      source

      • -> View More Comments
    • noodlejetski@lemm.ee ⁨6⁩ ⁨months⁩ ago

      you’re replying to a verbatim quote from the article.

      source

      • -> View More Comments
• dgmib@lemmy.world ⁨6⁩ ⁨months⁩ ago

  So for this attack to work, the attacker needs to be able to run a malicious DHCP server on the target machine’s network.

  Meaning they need to have already compromised your local network either physically in person or by compromising a device on that network. If you’ve gotten that far you can already do a lot of damage without this attack.

  For the average person this is yet another non-issue. But if you regularly use a VPN over untrusted networks like a hotel or coffee shop wifi then, in theory, an attacker could get your traffic to route outside the VPN tunnel.

  source

  • GamingChairModel@lemmy.world ⁨6⁩ ⁨months⁩ ago

    Put another way, this means that a malicious coffee shop or hotel can eavesdrop on all VPN traffic on their network. That’s a really big fucking deal.

    source

    • dgmib@lemmy.world ⁨6⁩ ⁨months⁩ ago

      Not all VPN traffic. Only traffic that would be routable without a VPN.

      This works by tricking the computer into routing traffic to the attacker’s gateway instead of the VPN’s gateway. It doesn’t give the attacker access to the VPN gateway.

      So traffic intended for a private network that is only accessible via VPN (like if you were connecting to a corporate network for example) wouldn’t be compromised. You simply wouldn’t be able to connect through the attacker’s gateway to the private network, and there wouldn’t be traffic to intercept.

      This attack doesn’t break TLS encryption either. Anything you access over https (which is the vast majority of the internet these days) would still be just as encrypted as if you weren’t using a VPN.

      For most people, in most scenarios, this amount to a small invasion of privacy. Our hypothetical malicious coffee shop could tell the ip addresses of websites you’re visiting, but probably not what you’re doing on those websites, unless it was an insecure website to begin with. Which is the case with or with VPN.

      For some people or some situations that is a MASSIVE concern. People who use VPNs to hide what they’re doing from state level actors come to mind.

      But for the average person who’s just using a VPN because they’re privacy conscious, or because they’re location spoofing. This is not going to represent a significant risk.

      source

      • -> View More Comments
  • wreleven@lemmy.ca ⁨6⁩ ⁨months⁩ ago

    This is the primary reason folks use VPNs - to protect themselves on public networks. I would say it’s definitely not a non-issue.

    source

    • EncryptKeeper@lemmy.world ⁨6⁩ ⁨months⁩ ago

      The thing is that in most cases you don’t need a VPN to protect yourself on a public network. The ubiquity of TLS on the internet already does a great job of that. Using a VPN on a public network for privacy and security reasons amounts to little more than the obfuscation of which sites you’re visiting, and some fallback protection against improperly configured websites. So while I agree it isn’t entirely a non-issue, it definitely isn’t as big of an issue as one might assume given the scary wording of the headline and article.

      source
  • bdonvr@thelemmy.club ⁨6⁩ ⁨months⁩ ago

    Not quite, this could be exploited by telecom providers when using mobile data. Also using a VPN for networks you DON’T control is one of the more popular uses of the things

    source
  • linearchaos@lemmy.world ⁨6⁩ ⁨months⁩ ago

    I think the real meat here would be the work from home crowd. If you can find a hole in there router, you can inject routing tables and defeat VPN.

    But the VPN client doesn’t have to be stupid. You could certainly detect rogue routes and shut down the network.

    source

    • dgmib@lemmy.world ⁨6⁩ ⁨months⁩ ago

      As I mentioned in my other comment, this wouldn’t let an attacker eavesdrop on traffic on a VPN to a private corporate network by itself. It has to be traffic that is routable without the VPN.

      source

      • -> View More Comments
• homesweethomeMrL@lemmy.world ⁨6⁩ ⁨months⁩ ago

  there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android.

  So . . . unix? Everything-but-Windows?

  source

  • freeman@sh.itjust.works ⁨6⁩ ⁨months⁩ ago

    Maybe it affects BSD and MacOS.

    It also can affect some Linux systems based on configuration. Android doesn’t implement the exploited standard at all and is always immune.

    source
  • abhibeckert@lemmy.world ⁨6⁩ ⁨months⁩ ago

    Everything-but-Windows?

    No. Any device that implements a certain DHCP feature is vulnerable. Linux doesn’t support it, because the feature is only useful for home computing/office workstations where Linux is rarely used. And Android doesn’t support it because it inherited the Linux network stack.

    source

    • gsfraley@lemmy.world ⁨6⁩ ⁨months⁩ ago

      most Linux systems don’t even use DHCP

      WTF are you smoking? WTF is wrong with you that you think such a dumb claim would go unscrutinized? I would play Russian roulette on the chances of a random Linux installation on a random network talking DHCP.

      source
    • ElderWendigo@sh.itjust.works ⁨6⁩ ⁨months⁩ ago

      because most Linux systems don’t even use DHCP

      This is the dumbest thing I’ve heard all day.

      source
    • gravitas_deficiency@sh.itjust.works ⁨6⁩ ⁨months⁩ ago

      As of this writing, 5 people who don’t know how DHCP works saw this comment

      source
• kinther@lemmy.world ⁨6⁩ ⁨months⁩ ago

  If your LAN is already compromised with a rogue DHCP server, you’ve got bigger problems than them intercepting just VPN traffic. They can man in the middle all of your non-encrypted traffic. While this is bad, it’s not a scenario most people will run into.

  source

  • doubletwist@lemmy.world ⁨6⁩ ⁨months⁩ ago

    The problem isn’t them being in you LAN. It’s about going to an untrusted network (eg Starbucks, hotel) and connecting to your VPN, boom, now your VPN connection is compromised.

    source

    • kinther@lemmy.world ⁨6⁩ ⁨months⁩ ago

      I woke up this morning and thought of this exact scenario, then found your comment lol

      Yes, this is bad for anyone who travels for work and can’t trust the network they connect to.

      source
  • sudneo@lemm.ee ⁨6⁩ ⁨months⁩ ago

    The other comment already covers the fact that VPN should be useful exactly when you are connected to untrusted LANs. I want to add that also the main point of your comment is anyway imprecise. You don’t need a compromise DHCP, you just need another machine who spoofs being a DHCP. Not all networks have proper measures in place for these attacks, especially when we are talking wireless (for example, block client-to-client traffic completely). In other words, there is quite a middle-ground between a compromised router (which does DHCP in most cases) and just having a malicious device connected to the network.

    source
  • rolling_resistance@lemmy.world ⁨6⁩ ⁨months⁩ ago

    I wonder if it applies to routers made by a company who likes collecting user data. Because this is a situation many people are in.

    source
• Nyfure@kbin.social ⁨6⁩ ⁨months⁩ ago

  To be fair, any proper VPN setup that only relies on the routing table like this is flawed to begin with.
  If the VPN program dies or the network interface disappears, the routes are removed aswell, allowing traffic to leave the machine without the VPN.
  So it is already a good practice to block traffic where it shouldnt go (or even better, only allowing it where it should).

  Many VPN-Programs by Providers already have settings to enable this to prevent "leaking".

  source

  • corsicanguppy@lemmy.ca ⁨6⁩ ⁨months⁩ ago

    aswell

    Not a word.

    source

    • paf0@lemmy.world ⁨6⁩ ⁨months⁩ ago

      You’re going to be ok.

      source
    • Nyfure@kbin.social ⁨6⁩ ⁨months⁩ ago

      Strong argument, anything else?

      source
    • Pulptastic@midwest.social ⁨6⁩ ⁨months⁩ ago

      A swell

      source

      • -> View More Comments
    • PlexSheep@infosec.pub ⁨6⁩ ⁨months⁩ ago

      It might aswell be one

      source
    • corsicanguppy@lemmy.ca ⁨6⁩ ⁨months⁩ ago

      Still not a word.

      source
• Postmortal_Pop@lemmy.world ⁨6⁩ ⁨months⁩ ago

  So I gave the article a glance and it’s a bit beyond me can someone give me an eli5?

  source

  • Bricriu@lemmy.world ⁨6⁩ ⁨months⁩ ago

    My understanding is that if you run a rogue discoverable DHCP server in a local network with a particular set of options set and hyper-specific routing rules, you can clobber the routing rules set by the VPN software on any non-Android device, and route all traffic from those devices through arbitrary midpoints that you control.

    But IANANE (I am not a network engineer) so please correct my misinterpretations.

    source

    • applepie@kbin.social ⁨6⁩ ⁨months⁩ ago

      this implies physical access or at least access within the network?

      source

      • -> View More Comments
  • vvv@programming.dev ⁨6⁩ ⁨months⁩ ago

    (obligatory I’m not a network surgeon this is likely not perfectly correct)

    The article mentions network interfaces, DHCP and gateways so real quick: a network interface usually represents a physical connection to a network, like an Ethernet port or a WiFi card. DHCP is a protocol that auto configured network routes and addresses once a physical connection is established, like when you jack in via an ethernet cable, it tells you the IP address you should go by, the range of IP address on the network you’ve connected to, where you can resolve domain names to IP addresses. It also tells you the address of a default gateway to route traffic to, if you’re trying to reach something outside of this network.

    You can have more than one set of this configuration. Your wired network might tell you that your an address is 10.0.0.34, anything that starts with 10.0.0. is local, and to talk to 10.0.0.254 if you’re trying to get to anything else. If at the same time you also connect to a wireless network, that might tell you that your address is 192.168.0.69, 192.168.0.* is your local network, and 192.168.0.254 is your gateway out. Now your computer wants to talk to 4.2.2.2. Should it use the wireless interface and go via 192.168.0.254? or the wired one and use 10.0.0.254? Your os has a routing table that includes both of those routes, and based on the precedence of the entries in it, it’ll pick one.

    VPN software usually works by creating a network interface on your computer, similar to an interface to a WiFi card, but virtual. It then asks the OS to route all network traffic, through the new interface it created. Except of course traffic from the VPN software, because that still needs to get out to the VPN provider (let’s say, at 1.3.3.7) via real Internet.

    So if you’re following along at time, your routing table at this point might look like this:

    • traffic to 1.3.3.7 should go to 10.0.0.254 via the wired interface
    • all traffic should go to the VPN interface
    • traffic to 10.0.0.* should go to the wired interface
    • all traffic should go to 10.0.0.254 via the wired interface
    • traffic to 192.168.0.* should go to the wireless interface
    • all traffic should go to 192.168.0.254 via the wireless interface

    whenever your os wants to send network packets, it’ll go down this list of rules until one applies. With that VPN turned on, most of the time, only those two first rules will ever apply.

    If I’m reading the article correctly, what this attack does, is run a DHCP server, that when handing out routing rules, will send one with a flag that causes, for example, the last two rules to be placed at the top of the list instead of the bottom. Your VPN will still be on, the configuration it’s requested the OS to make would still be in place, and yet all your traffic will be routed out to this insecure wireless network that’s somehow set itself as the priority route over anything else.

    source

    • mysticalone@lemmy.world ⁨6⁩ ⁨months⁩ ago

      Thank you network nurse

      source
    • Postmortal_Pop@lemmy.world ⁨6⁩ ⁨months⁩ ago

      That actually lays it out incredibly well for me. So in practice, what would I need to look out for as a wired desktop Ubuntu user with mullvad? It’s sounding like this is going to be an issue on public networks, is this something my isp can do to me at home?

      source

      • -> View More Comments
    • verity_kindle@sh.itjust.works ⁨6⁩ ⁨months⁩ ago

      Thank you, you are a surgeon of charity

      source
• yardy_sardley@lemmy.ca ⁨6⁩ ⁨months⁩ ago

  I think this is a good enough reason to actually put in some effort to phase out ipv4 and dhcp. There shouldn’t be a way for some random node on the network to tell my node what device to route traffic over. Stateless ipv6 for the win.

  source

  • 9point6@lemmy.world ⁨6⁩ ⁨months⁩ ago

    Efforts have been put in for several decades now

    I still remember all the hype around “IPv6” day about 12 years ago…

    Any day now…

    source

    • Scrollone@feddit.it ⁨6⁩ ⁨months⁩ ago

      Honestly I’m on a IPv6 provider (with CGNAT for IPv4-only services) and everything works fine.

      I think people are just lazy.

      source

      • -> View More Comments
• BorgDrone@lemmy.one ⁨6⁩ ⁨months⁩ ago

  (…) the entire purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and to cloak the user’s IP address.

  No. That is not the entire point of a VPN. That’s just what a few shady companies are claiming to scam uninformed users into paying for a useless service. The entire point of a VPN is to join a private network (i.e. a network that is not part of the Internet) over the public internet, such as connecting to your company network from home. Hence the name ‘virtual private network’.

  There are very little, if any, benefits to using a VPN service to browse the public internet.

  source

  • the_third@feddit.de ⁨6⁩ ⁨months⁩ ago

    Well, for one, using one of those VPN providers has kept DMCA takedown notices away from me or the hosting provider of my seed box. So that is useful.

    source
  • mako@lemmy.today ⁨6⁩ ⁨months⁩ ago

    There are very little, if any, benefits to using a VPN service to browse the public internet.

    This is why it’s often best to just avoid the comments completely

    source
  • desktop_user@lemmy.blahaj.zone ⁨6⁩ ⁨months⁩ ago

    There are very little, if any, benefits to using a VPN service to browse the public internet.

    accessing services that are blocked in your region.

    source

    • lurch@sh.itjust.works ⁨6⁩ ⁨months⁩ ago

      that works, but a regular SOCKS proxy should do. for HTTP even a HTTP proxy. many VPN providers offer them too, btw… may help with mitigating this attack vector.

      source
  • Passerby6497@lemmy.world ⁨6⁩ ⁨months⁩ ago

    There are very little, if any, benefits to using a VPN service to browse the public internet.

    I’ve run into issues multiple times where a site doesn’t load until I turn on my VPN with an endpoint in the EU

    source
  • vext01@lemmy.sdf.org ⁨6⁩ ⁨months⁩ ago

    Come to think of it, why do they even call this use case a VPN? I’d call that a proxy.

    source
• xenoclast@lemmy.world ⁨6⁩ ⁨months⁩ ago

  Step one, be in full control of DNS on the network. Not difficult, but not simple.

  source
• LordCrom@lemmy.world ⁨6⁩ ⁨months⁩ ago

  To execute this you need a DHCP server on the network… But any admin worth his salt has a config on the switch to limit DHCP traffic to a designated server.

  Seems extremely difficult to pull off in any corporate environment

  source

  • Benchamoneh@lemmy.dbzer0.com ⁨6⁩ ⁨months⁩ ago

    But makes coffee shop wifi inherently more risky

    source

    • LordCrom@lemmy.world ⁨6⁩ ⁨months⁩ ago

      For shits and giggles I used to sit on those wifis and run a mitm…I would replace all images with the troll face meme…then sit back and watch the confusion. So ya

      source

      • -> View More Comments
• RaoulDook@lemmy.world ⁨6⁩ ⁨months⁩ ago

  So if they are changing routes by using DHCP options, perhaps this could be exploited by telecom insiders when you are using mobile data, because your mobile data IP could be assigned by a DHCP server on the telecom network. If you’re at home on wifi, then you can control your own DHCP server to prevent that.

  source

  • rimu@piefed.social ⁨6⁩ ⁨months⁩ ago

    No - the VPN provider has another DHCP server for use 'inside' the VPN.

    source

    • SzethFriendOfNimi@lemmy.world ⁨6⁩ ⁨months⁩ ago

      Except this bypasses that I believe.

      source
    • ignirtoq@fedia.io ⁨6⁩ ⁨months⁩ ago

      The attack vector described in the article uses the VPN client machine's host network, i.e. the local network the device is attached to. They don't discuss the DHCP server of the VPN provider.

      source
    • mox@lemmy.sdf.org ⁨6⁩ ⁨months⁩ ago

      Read this part more carefully:

      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.

      Most traffic gets sent through a VPN only because of the default gateway (set by the VPN) in the client’s routing table. If the client’s ISP were to have their DHCP server set one or more specific routes that are broad enough to cover most of the address space, they would effectively override that default gateway. I believe that’s the scenario described in the article.

      source
    • Max_P@lemmy.max-p.me ⁨6⁩ ⁨months⁩ ago

      Most VPN providers don’t use DHCP. OpenVPN emulates and hooks DHCP requests client-side to hand the OS the IP it got over the OpenVPN protocol in a more standard way (unless you use Layer 2 tunnels which VPN providers don’t because it’s useless for that use case). WireGuard doesn’t support DHCP at all and it always comes from configuration.

      source
  • Max_P@lemmy.max-p.me ⁨6⁩ ⁨months⁩ ago

    The attack vector here seems to be public WiFi like coffee shops, airports, hotels and whatnot. The places you kinda do want to use a VPN.

    On those, if they’re not configured well such as coffee shops using consumer grade WiFi routers, an attacker on the same WiFi can respond to the DHCP request faster than the router or do an ARP spoof attack. The attacker can proxy the DHCP request to make sure you get a valid IP but add extra routes on top.

    source
• MonkderDritte@feddit.de ⁨6⁩ ⁨months⁩ ago

  If i get that right, that attack only works before the tunnel is initiated (i.e. traffic encrypted), if the hosts is compromoised, right?

  source

  • NeatNit@discuss.tchncs.de ⁨6⁩ ⁨months⁩ ago

    This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.

    Sounds to me like it totally works even after the tunnel has started.

    source

    • Natanael@slrpnk.net ⁨6⁩ ⁨months⁩ ago

      Yeah, it’s like a fake traffic cop basically, sending your (network) traffic down the wrong route

      source

      • -> View More Comments
  • DreamlandLividity@lemmy.world ⁨6⁩ ⁨months⁩ ago

    No, it works at any point and the local network needs to be compromised (untrusted), the host can be secure.

    source

    • MonkderDritte@feddit.de ⁨6⁩ ⁨months⁩ ago

      Yikes

      source

      • -> View More Comments
    • seth@lemmy.world ⁨6⁩ ⁨months⁩ ago

      Yes, and also is fine if you’re using a cell hotspot.

      source
• Max_P@lemmy.max-p.me ⁨6⁩ ⁨months⁩ ago

  That’s why half decent VPN apps also add firewall rules to prevent leakage. Although nothing can beat Linux and shoving the real interface in a namespace so it’s plainly not available to anything except the VPN process.

  source

  • r00ty@kbin.life ⁨6⁩ ⁨months⁩ ago

    Yes, I don't agree with the no way to mitigate statement.

    I suspect on windows the only real defence is something like.

    • Check if the network has suspicious multiple routes setup from the DHCP
    • If so, either use the IP/Mask/Gateway with manual IP config (to not receive the CIDR routes) or steer clear of an at best questionable network entirely.
    • Maybe use the windows firewall to block all traffic outbound EXCEPT from the firewall program (with perhaps exceptions for local networks as per below linux example). For whatever reason the windows firewall doesn't seem to have a way to specify an interface. But you can specify a program.

    I did look for some way to control Window's handling of DHCP options. But it seems there isn't anything obvious to limit this otherwise. I do not know if the windows firewall has this kind of fine-grained control with its own fire

    For linux, I used to have my own blackout firewall rules. That only allowed the specific LAN range (for mobile use you could include all RFC1918 ranges) and the specific VPN IP out of the internet facing interface. Only the VPN interface could otherwise access the internet.

    source

    • Max_P@lemmy.max-p.me ⁨6⁩ ⁨months⁩ ago

      Some providers have managed to make split tunnelling work fine so those I suspect are not affected because they override the routing at the driver level. It’s really only the kinda lame OpenVPN wrappers that would be affected. When you have the custom driver, you can affect the routing. It’s been a while since I’ve tested this stuff on Windows since obviously I haven’t been paid to do that for 6 years, but yeah I don’t even buy that all providers are affected and that it’s unfixable. We had workarounds for that when I joined PIA already so it’s probably been a known thing for at least a decade.

      source
• SplashJackson@lemmy.ca ⁨6⁩ ⁨months⁩ ago

  But why was this attacking novels? Are comic books safe?

  source
• TipRing@lemmy.world ⁨6⁩ ⁨months⁩ ago

  I use option 121 as part of my work, though I am not an expert on DHCP. This attack does make sense to me and it would be hard to work around given the legitimate uses for that option.

  source

  • runswithjedi@lemmy.world ⁨6⁩ ⁨months⁩ ago

    What are the legitimate uses of option 121?

    source
• Natanael@slrpnk.net ⁨6⁩ ⁨months⁩ ago

  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.

  Ok, so double encrypted and authenticated traffic (TLS inside the VPN) would still be safe, and some stuff requiring an internal network origin via the VPN is safe (because the attacker can’t break into the VPN connection and your client won’t get the right response), but a ton of other traffic is exposed (especially unencrypted internal traffic on corporate networks, especially if it’s also reachable without a VPN or if anything sends credentials in plaintext)

  source
• Cyberflunk@lemmy.world ⁨6⁩ ⁨months⁩ ago

  So…

  reject 121;
  
  

  In your dhclient?

  source
• Got_Bent@lemmy.world ⁨6⁩ ⁨months⁩ ago

  Does this mean I still can’t watch porn in Texas?

  source
• AnAnonymous@lemm.ee ⁨6⁩ ⁨months⁩ ago

  A good reason to never trust in shady VPNs.

  source
• autotldr@lemmings.world [bot] ⁨6⁩ ⁨months⁩ ago

  This is the best summary I could come up with:

  ---

  Researchers have devised an attack against nearly all virtual private network applications that forces them to send and receive some or all traffic outside of the encrypted tunnel designed to protect it from snooping or tampering.

  TunnelVision, as the researchers have named their attack, largely negates the entire purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and to cloak the user’s IP address.

  The attack works by manipulating the DHCP server that allocates IP addresses to devices trying to connect to the local network.

  A setting known as option 121 allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel.

  When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.

  This remedy is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall and (2) it opens the same side channel present with the Linux mitigation.

  ---

  The original article contains 903 words, the summary contains 196 words. Saved 78%. I’m a bot and I’m open source!

  source
• Emmie@lemm.ee ⁨6⁩ ⁨months⁩ ago

  If someone uses vpns for anything other than region locked content then they deserve the outcome really

  source
• the_third@feddit.de ⁨6⁩ ⁨months⁩ ago

  When I design someone, critical applications get their own network namespace with only the VPN interface inside anyway. So, yeah.

  source
• Buelldozer@lemmy.today ⁨6⁩ ⁨months⁩ ago

  Meh, option 121 shenanigans can be detected and remediated via post connection scripting.

  source