Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Quick Links


Categories

In this Discussion

› › A rogue DHCP server within your network can and will hijack your VPN traffic
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

A rogue DHCP server within your network can and will hijack your VPN traffic

davidedavide Member
edited September 2023 in General

This DHCP server may be your thermostat, smart TV, access point, dildo, and such. From Bing Chat:

A malicious DHCP server can set routing rules on a DHCP client computer that hijack packets generated locally by the client machine which are destined to the VPN, and redirect them toward another destination. This is possible by using the DHCP option 121, which allows the DHCP server to specify classless static routes for the client. The DHCP server can send a route for the VPN network that points to a different gateway than the VPN server, or to a non-existent gateway, effectively hijacking or dropping the VPN packets.

For example, if the VPN network is 10.8.1.0/24 and the VPN server is 10.8.1.1, the DHCP server can send a route like this:

10.8.1.0/24 via 192.168.1.100

This will cause the client to send the packets destined to the VPN network through the gateway 192.168.1.100, which may be a malicious system controlled by the attacker, instead of the VPN server 10.8.1.1. The attacker can then intercept, modify, or drop the packets, depending on their goal.

If such packets are hijacked by malicious routing rules set by the rogue DHCP server, they are never encrypted because they don’t reach the VPN interface. The VPN interface only encrypts the packets that are routed through it, not the packets that are routed to it. Therefore, the packets that are destined to the VPN network but are redirected by the DHCP server are sent in plain text over the network, exposing the data and the credentials of the VPN client.

To prevent this attack, the DHCP client should verify the DHCP options before accepting them, and reject any routes that are not consistent with the VPN configuration. The DHCP client should also use encryption and authentication for the VPN connection, and use certificates or pre-shared keys to verify the identity of the VPN server. The DHCP client can also use tools like ip route or route to check the routing table of the computer and make sure it is correct.

Comments

  • davidedavide Member
    edited September 2023

    I googled for an hour around this issue but I cannot find much about it. It seems that most don't care.

    The simplest solution is to apt-get purge the DHCP client and go static. Mr Bing also suggests to have something like this in /etc/ dhcp/ dhclient-exit-hooks.d/ as a compromise:

    #!/bin/bash
# This script removes the routes for the VPN network 10.8.1.0/24 from the routing table
# It assumes that the VPN interface is tun0 and the physical interface is eth0
# It does not depend on the environment variable name or the format of the DHCP option 121
# You may need to adjust the script according to your network settings

# Delete all routes for the VPN network through the physical interface
ip route delete 10.8.1.0/24 dev eth0
# Add the route for the VPN network through the VPN interface
ip route add 10.8.1.0/24 dev tun0
# Log the action
echo "Removed the route for the VPN network 10.8.1.0/24 from the DHCP option 121" >> /var/ log/ dhclient.log
  • tentortentor Member, Patron Provider

    @davide said: It seems that most don't care.

    That's true, importance of the network security is underestimated.

    Thanked by 1darkimmortal
  • tentortentor Member, Patron Provider

    1. @davide said: Mr Bing also suggests to have something like this in /etc/ dhcp/ dhclient-exit-hooks.d/ as a compromise

    2. @davide said: The DHCP client should also use encryption and authentication for the VPN connection, and use certificates or pre-shared keys to verify the identity of the VPN server.

    Among these options I would go with second because it scales better - all modern VPN solution I am aware of are already doing server authentication, OpenVPN and Wireguard are doing client authentication as well with optional PSK available, so I don't see any reason to use dhclient hooks.

  • davidedavide Member
    edited September 2023

    @tentor Bing gets confused sometimes; mutual authentication in VPN's is ubiquitous. It is the processes that send data thru the VPN that are at risk, as the packets they send to the VPN don't reach the VPN and pass thru a MITM unencrypted.

  • tentortentor Member, Patron Provider

    @davide said: I googled for an hour around this issue but I cannot find much about it

    Read about these security mechanisms: DHCP Snooping, Dynamic ARP Inspection and IP Source Guard. Sure, you can configure everything statically, but as your infrastructure grow (or smart teapots dynamically allocated in your apartments) it becomes exponentially harder.

  • tentortentor Member, Patron Provider

    @davide said: as the packets they send to the VPN don't reach the VPN and pass thru a MITM unencripted

    Oh, my bad. I thought kill-switches exist to fight unexpected routing table changes similar to the scenario of this attack.

  • davidedavide Member

    In home environments? I think most home/office folks using a VPN for its alleged security are 100% exposed to smart devices in their home, and to whomever controls them via arbitrary remote software updates, to potentially being hijacked away from the VPN.

  • davidedavide Member
    edited September 2023

    BOOM I dropped the bomb. Argument won m8 B)

  • tentortentor Member, Patron Provider

    @davide said:
    Argument won m8 B)

    (Un)fortunately, I am unaware of consumer grade network equipment enough to participate in this discussion. At my home I have router with OpenWRT installed. I use few VLANs to isolate untrusted devices from hardened ones.

  • davidedavide Member

    Logic checks out m8 :)

  • neckbreakerneckbreaker Member
    edited September 2023

    "Vulnerability" in question is called TunnelCrack.

    You can learn more on: https://tunnelcrack.mathyvanhoef.com/

    And a response from my VPN providers of choice:
    https://mullvad.net/en/blog/2023/8/9/response-to-tunnelcrack-vulnerability-disclosure/
    https://www.ivpn.net/blog/ivpn-tunnelcrack-vulnerability-assessment/

  • yoursunnyyoursunny Member, IPv6 Advocate

    I have VPN client in the home router: 192.168.121.0/24 goes to the VPN server.
    Rogue devices can reach this prefix too but they will just find downloads from pubic tracker.

  • davidedavide Member
    edited September 2023

    A firewall that selectively blocks outbond packets to protect from hijacking seems like a pain to set up if /etc /hosts is a large and non-contiguous beast. And /etc /nftables.conf would have to redefine part of the same entries. The solutions linked above for Mullvad and Ivpn both unconditionally block all outbond packets with destination to public addresses.

    What are common solutions to unify the management of /etc /hosts and /etc /nftables.conf (and possibly of other config files where the same network resources need to be redefined)?

  • davidedavide Member

    @yoursunny said:
    I have VPN client in the home router: 192.168.121.0/24 goes to the VPN server.
    Rogue devices can reach this prefix too but they will just find downloads from pubic tracker.

    That's to spoof traffic shaping I imagine. I do the same with an ssh socks5. But mine works like shit because socks5 is poorly supported by torrent clients.

  • host_chost_c Member, Patron Provider

    @davide said: This DHCP server may be your thermostat, smart TV, access point, dildo, and such. From Bing Chat:

    Damn, damn that Wifi Dildo....... :smiley:

  • davidedavide Member

    On Tor they probably sell wifi dildo passwords by the million. A pain in the ass indeed.

Sign In or Register to comment.