Close Menu
Technology Mag

    Subscribe to Updates

    Get the latest creative news from FooBar about art, design and business.

    What's Hot

    US Senator Urges DHS to Probe Whether Agents Were Moved From Criminal Cases to Deportations

    July 31, 2025

    The Texas Floods Were a Preview of What’s to Come

    July 31, 2025

    In a Rut? Here Are the Best Sexy Gifts to Get You (and Your Partner) Revved Up

    July 31, 2025
    Facebook X (Twitter) Instagram
    Subscribe
    Technology Mag
    Facebook X (Twitter) Instagram YouTube
    • Home
    • News
    • Business
    • Games
    • Gear
    • Reviews
    • Science
    • Security
    • Trending
    • Press Release
    Technology Mag
    Home » ‘TunnelVision’ Attack Leaves Nearly All VPNs Vulnerable to Spying
    Security

    ‘TunnelVision’ Attack Leaves Nearly All VPNs Vulnerable to Spying

    News RoomBy News RoomMay 13, 20245 Mins Read
    Facebook Twitter Pinterest LinkedIn Reddit WhatsApp Email

    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 researchers believe it affects all VPN applications when they’re connected to a hostile network and that there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android. They also said their attack technique may have been possible since 2002 and may already have been discovered and used in the wild since then.

    Reading, Dropping, or Modifying VPN Traffic

    The effect of TunnelVision is that “the victim’s traffic is now decloaked and being routed through the attacker directly,” a video demonstration explained. “The attacker can read, drop or modify the leaked traffic and the victim maintains their connection to both the VPN and the internet.”

    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. By using option 121 to route VPN traffic through the DHCP server, the attack diverts the data to the DHCP server itself. Researchers from Leviathan Security explained:

    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. When the traffic hits our gateway, we use traffic forwarding rules on the DHCP server to pass traffic through to a legitimate gateway while we snoop on it.

    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.

    We now have traffic being transmitted outside the VPN’s encrypted tunnel. 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.

    The attack can most effectively be carried out by a person who has administrative control over the network the target is connecting to. In that scenario, the attacker configures the DHCP server to use option 121. It’s also possible for people who can connect to the network as an unprivileged user to perform the attack by setting up their own rogue DHCP server.

    The attack allows some or all traffic to be routed through the unencrypted tunnel. In either case, the VPN application will report that all data is being sent through the protected connection. Any traffic that’s diverted away from this tunnel will not be encrypted by the VPN and the internet IP address viewable by the remote user will belong to the network the VPN user is connected to, rather than one designated by the VPN app.

    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. Network firewalls can also be configured to deny inbound and outbound traffic to and from the physical interface. 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 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. The research, from Leviathan Security researchers Lizzie Moratti and Dani Cronce, is available here.

    This story originally appeared on Ars Technica.

    Share. Facebook Twitter Pinterest LinkedIn WhatsApp Reddit Email
    Previous ArticleTime Is Running Out in the Hunt for Rare Bitcoin
    Next Article Google is bringing Project Starline’s “magic window” experience to real video calls

    Related Posts

    How WIRED Analyzed the Epstein Video

    July 31, 2025

    Microsoft Put Older Versions of SharePoint on Life Support. Hackers Are Taking Advantage

    July 29, 2025

    DHS Faces New Pressure Over DNA Taken From Immigrant Children

    July 25, 2025

    At Least 750 US Hospitals Faced Disruptions During Last Year’s CrowdStrike Outage, Study Finds

    July 24, 2025

    China’s Salt Typhoon Hackers Breached the US National Guard for Nearly a Year

    July 23, 2025

    How China’s Patriotic ‘Honkers’ Became the Nation’s Elite Cyberspies

    July 21, 2025
    Our Picks

    The Texas Floods Were a Preview of What’s to Come

    July 31, 2025

    In a Rut? Here Are the Best Sexy Gifts to Get You (and Your Partner) Revved Up

    July 31, 2025

    Google’s Pixel Tablet is $190 off for a limited time

    July 31, 2025

    Mark Zuckerberg Details Meta’s Plan for Self-Improving, Superintelligent AI

    July 31, 2025
    • Facebook
    • Twitter
    • Pinterest
    • Instagram
    • YouTube
    • Vimeo
    Don't Miss
    Science

    Big Tech Asked for Looser Clean Water Act Permitting. Trump Wants to Give It to Them

    By News RoomJuly 31, 2025

    There are currently more than 50 issued nationwide 404 permits—some of which still require pre-construction…

    The Asus Chromebook CX14 Is a $429 Laptop That Isn’t Horrible

    July 31, 2025

    Aaron Sorkin’s Social Network sequel might recast Mark Zuckerberg

    July 31, 2025

    How WIRED Analyzed the Epstein Video

    July 31, 2025
    Facebook X (Twitter) Instagram Pinterest
    • Privacy Policy
    • Terms of use
    • Advertise
    • Contact
    © 2025 Technology Mag. All Rights Reserved.

    Type above and press Enter to search. Press Esc to cancel.