Home

Podfeet Podcasts

Security Bits logo - a green padlock with the words Security Bits to the right and in tiny letters below ithat it says 10101010 indicating a digital lock

Security Bits — 12 May 2024

  • by Bart Busschots

    • Feedback & Followups

    Deep Dive — Two VPN Problems, one Minor, one Major

    Two unrelated VPN stories have broken recently, leading to a real danger of confusion — one is a minor short-term problem affecting only Android that’s easy for Google to fix, and the other is a fundamental problem that changes how we need to think about the problems VPNs can and can’t solve.

    The Android-only DNS Leak (Minor Problem with Easy Fix)

    Let’s start with the easy one.

    Until Google fix one of the two DNS APIs in Android, one of them ignores the system-wide setting to route all traffic through the VPN connection, allowing some DNS queries from some VPN clients to briefly bypass the VPN and go directly to the internet.

    Since DNS is an old pre-encryption protocol, DNS queries leak information about what domains you’re interacting with to any adversaries-in-the-middle, be they attackers or ISPs. For domains that don’t implement digital signatures on their records, i.e. domains without DNSSEC enabled (still the case for most non-government domains 🙁), an AiTM could also manipulate the leaked DNS responses, tricking your VPN client into connecting to a malicious server. Assuming your VPN client actually checks the validity of the TLS cert sent by the server, that kind of attack would fail though.

    In reality, the risk is small, and the fix for Google is trivial, add one if statement to one C function. Even before Google fix Android itself, VPN developers can fix their own apps by using the DNS API call that’s working just fine rather than the one missing the check.

    Links

    TunnelVision — Why No VPN Can Keep You Save on an Untrusted Network

    Now, let’s dig into the big news — many of us have been using VPNs to solve a problem they cannot solve, never could, and never should have been marketed as solving.

    TLDR; VPNs enable you to safely connect through untrusted networks, not from untrusted networks.

    I have been guilty of saying that one of the many problems VPNs can solve is safely connecting to the internet from an untrusted network, but I was wrong. In my defence, many consumer VPNs are marketed in that way, and with the benefit of hindsight, it should always have been obvious that was not true.

    The three most common use cases used to market VPNs to consumers are:

    1. Securely connecting to the internet from untrusted networks like public WiFi, coffee shops, and hotels (WiFi or Ethernet!) — was never true, will never be true
    2. Connecting to the internet without your ISP spying on you — has always been true, still is
    3. Accessing geo-restricted sites and services from anywhere — not security related but still true

    One of the biggest of those promises has always been false and always will be, though workarounds are possible, even if they might amount to a new game of cat-and-mouse.

    Note that the typical Corporate use cases are also partially affected:

    1. Securely connect to the corporate network from anywhere — was only ever partly true, remains partly true — the remote network needs to be trusted, so home networks are fine, public WiFi, coffee shops, hotels etc are not
    2. Securely connect multiple corporate locations into a single apparent LAN — has always been true, remains true
    3. Securely project the corporate LAN into the cloud — has always been true, remains true

    Before I go on to explain why we need to rethink the problems VPNs solve, it’s important to note that there is a simple workaround for the public network problem — use your VPN over a cellular network connection rather than an untrusted WiFi/ethernet connection!

    One final point before we dive into the currently known attack vector, and the possible workarounds — the currently know attack is just one of an infinity of possible attacks, because the fundamental problem is that conceptually, VPN technology does not, and cannot, control the low-level setup of a computer’s connections to local networks. VPNs sit on top of the TCP/IP protocol, so everything lower down the network stack — including the Ethernet protocol (MAC addresses etc.), DHCP, and even the IP routing protocol — is out of their control!

    This current attack abuses an important DHCP feature to configure user devices to route some traffic around the VPN and through a malicious device before continuing, unencrypted to its destination.

    Because this attack doesn’t even attempt to break the VPN encryption, no certificate warnings will be generated to alert the user of the problem. Also, to succeed, the attack must be fine-grained, routing only traffic to specific IP addresses around the VPN.

    To understand the attack you need to know the following:

    1. Every computer connected to a network over the IP protocol must have a local routing table that the OS uses to route packets appropriately.
    2. The IP protocol uses a most specific match rule to determine which routing table entry to apply to a given packet
    3. The reason regular users never need to enter IP settings into our devices is the ubiquitous use of the Dynamic Host Configuration Protocol (DHCP)— we in effect trust the network we’re connecting to to tell our devices how to configure themselves on the network
    4. DHCP is another one of those old pre-encryption protocols, so anyone on a LAN can answer DHCP queries, and the first reply wins — if an attacker is faster than the legitimate router, their settings will get applied!
    5. As well as telling devices what IP address they should use, DHCP can also send routing table entries to clients when they ask for their network settings.
    6. Internally, within a device, a VPN connection is a virtual network device, a kind of pretend Ethernet port, so traffic is sent through the VPN connection using the IP routing table
    7. It is completely legitimate for devices to be configured to send some, but not all, traffic through a VPN connection (within VPN apps this feature is often labeled as a split tunnel)

    With all that out of the way, how does the TunnelVision attack work?

    A malicious actor joins a public network and enables their device to do two things:

    1. Act as a DHCP server
    2. Act as a router

    Before launching the attack the attacker sends out a DHCP query for their own device to learn the network’s legitimate settings.

    When a victim broadcasts a DHCP request, the attackers answer very quickly with a malicious reply that has the legitimate network settings, plus, a number of malicious routing table entries with very specific rules to send traffic to specific IP addresses through the attacker’s device instead of the VPN’s virtual network device. If the attacker beats the legitimate DHCP server in getting their reply out, the attack succeeds, if not, it fails!

    Key points:

    1. Because the attack depends on a race, it can never be 100% successful
    2. Because the attack relies on having a routing table entry that is more specific than the entry to route the desired traffic through the VPN, it can only ever be used for very targeted attacks
    3. The attack does not break any encryption, be that VPN encryption, or application-layer encryption like HTTPS, SSH, etc.
    4. The attack depends on the victim device supporting the DCHP option for adding routes

    By pure accident, Android is immune to this specific attack, because it does not support the DHCP option for setting routes. This has the side effect of causing no end of problems on corporate networks, but it’s convenient for home users 🙂

    So, possible mitigations? Again, these cannot change the fundamental reality than VPN protocols can’t control the LAN configuration, but this specific attack, which is the only one we know of ATM, can be mitigated in at least two ways:

    1. At the OS level, the DHCP option for routing table entries could be disabled. This is fine for home users, but will break many corporate networks because that feature exists for good reason!
    2. VPN apps could augment their use of VPN protocols with the use of virtualisation features available in many modern OSes to effectively convert the entire host OS from the VPN’s endpoint to just another untrusted network it securely tunnels through
    3. The routing table is visible to all processes on a computer, so VPN apps could provide a visualisation of the computer’s routing setup showing which destination IP ranges are going through the VPN, and which are not. This would provide transparency to power users, who might well be happy using the netstat terminal command to check the routes themselves but is unlikely to help regular users.

    Links

    ❗ Action Alerts

    Worthy Warnings

    • 🇺🇸 FBI warns of fake verification schemes targeting dating app users — www.bleepingcomputer.com/…
      • Warning is from US authorities but is relevant everywhere
      • Use the pretence of pretending to offer safety by using a supposed identity verification service that is actually an identity theft portal
    • 🇺🇸 🇰🇵 NSA warns of North Korean hackers exploiting weak DMARC email policies — www.bleepingcomputer.com/…
      • Warning is from US authorities but is relevant everywhere
      • Most relevant in a work context, where abuse of poorly configured DMARC settings on legitimate domains can result in very convincing spear-phishing attacks against low-level workers in organisations of interest to NK, or to important people with access to money or resources in any organisation
    • DropBox announced that their DropBox Sign service was compromised, and that account details (but not documents) leaked, including lots of PII as well as hashed passwords, 2FA/MFA tokens, and API keys — www.bleepingcomputer.com/…
      • Excellent response from DropBox
        • All affected passwords reset
        • All affected users will be forced to reregister for 2FA/MFA
        • All affected API keys have been limited until the users generate new ones and re-configure their integrations/apps to use them
      • For small businesses without full-time IT staff, rotating API keys may prove challenging
      • An Interesting detail in DropBox’s notification — they are explicitly warning users not to click any links in emails purporting to be from DropBox about this breach, because legitimate emails actually from DropBox won’t ask you to click anything, but to go directly to DropBox yourself in your browser
    • Dell API abused to steal 49 million customer records in data breach — www.bleepingcomputer.com/…

    Notable News

    Palate Cleansers

    Legend

    When the textual description of a link is part of the link it is the title of the page being linked to, when the text describing a link is not part of the link it is a description written by Bart.

    Emoji Meaning
    🎧 A link to audio content, probably a podcast.
    ❗ A call to action.
    flag The story is particularly relevant to people living in a specific country, or, the organisation the story is about is affiliated with the government of a specific country.
    📊 A link to graphical content, probably a chart, graph, or diagram.
    🧯 A story that has been over-hyped in the media, or, “no need to light your hair on fire” 🙂
    💵 A link to an article behind a paywall.
    📌 A pinned story, i.e. one to keep an eye on that’s likely to develop into something significant in the future.
    🎩 A tip of the hat to thank a member of the community for bringing the story to our attention.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Scroll to top