• adam_y@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 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.

  • the_third@feddit.de
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    8 months ago

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

      • the_third@feddit.de
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 months ago

        There’s readily available docker containers for it but I wanted to build it by hand. Well, more or less, Extremely hacky but it works, so fine for me.

        I started out with cheating and used this wrapper around wg-quick that gives us a persistent network namespace with the tunnel interface in it:

        https://github.com/dadevel/wg-netns

        cat /etc/systemd/system/wg-qbittorrent.service
        [Unit]
        Description=WireGuard Network Namespace for qBittorrent
        Wants=network-online.target nss-lookup.target
        After=network-online.target nss-lookup.target
        
        [Service]
        Type=oneshot
        Environment=WG_ENDPOINT_RESOLUTION_RETRIES=infinity
        Environment=WG_VERBOSE=1
        ExecStart=/opt/wg-netns/bin/wg-netns up /etc/wireguard/wgconfig.yaml
        ExecStop=/opt/wg-netns/bin/wg-netns down /etc/wireguard/wgconfig.yaml
        RemainAfterExit=yes
        
        WorkingDirectory=%E/wireguard
        ConfigurationDirectory=wireguard
        ConfigurationDirectoryMode=0700
        
        CapabilityBoundingSet=CAP_NET_ADMIN CAP_SYS_ADMIN
        LimitNOFILE=4096
        LimitNPROC=512
        LockPersonality=true
        MemoryDenyWriteExecute=true
        NoNewPrivileges=true
        ProtectClock=true
        ProtectHostname=true
        RemoveIPC=true
        RestrictAddressFamilies=AF_INET AF_INET6 AF_NETLINK
        RestrictNamespaces=mnt net
        RestrictRealtime=true
        RestrictSUIDSGID=true
        SystemCallArchitectures=native
        
        [Install]
        WantedBy=multi-user.target
        

        Then I built a static binary of qbittorrent using this really neat docker image: https://github.com/userdocs/qbittorrent-nox-static

        …and stuffed the result into a systemd service that runs it in the namespace wg-netns provides:

        cat /etc/systemd/system/qbittorrent-nox.service 
        
        [Unit]
        Description=qBittorrent-nox service
        Wants=network-online.target wg-qbittorrent.service 
        After=local-fs.target network-online.target nss-lookup.target wg-qbittorrent.service 
        
        [Service]
        Type=simple
        PrivateTmp=false
        #User=qbittorrent
        ExecStart=/usr/sbin/ip netns exec ns-qbittorrent sudo -u qbittorrent /opt/qbittorrent/qbittorrent-nox
        TimeoutStopSec=1800
        RestartSec=15
        RestartMaxDelaySec=600
        RestartSteps=10
        Restart=always
        
        [Install]
        WantedBy=multi-user.target
        
        

        To get the webui out of that I stuck two instances of socat together at the stdout and from there it depends on whatever you want to use as a reverse proxy on the host - or you bind to a network interface if you trust the network:

        cat /etc/systemd/system/qbittorrent-webui.service 
        [Unit]
        Description=qBittorrent-nox webui forwarding into its namespace
        Wants=network-online.target wg-qbittorrent.service 
        After=local-fs.target network-online.target nss-lookup.target wg-qbittorrent.service 
        
        [Service]
        Type=simple
        PrivateTmp=false
        ExecStart=/opt/qbittorrent/forward-webinterface.sh
        TimeoutStopSec=1800
        Restart=always
        RestartSec=10
        
        [Install]
        WantedBy=multi-user.target
        
        cat /opt/qbittorrent/forward-webinterface.sh
        #!/bin/sh
        set -eu
        
        exec socat tcp6-listen:"8080",reuseaddr,fork,range=[::1]/128 "exec:ip netns exec ns-qbittorrent socat stdio 'tcp-connect:127.0.0.1:8080',nofork"
        
        

        Works, is reboot safe, stopped caring about beauty at that point.

        • xabadak@lemmings.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          8 months ago

          Do you know how to make it so all the host’s traffic is sent through the VPN namespace? I couldn’t figure out how to do this so I ended up just writing my own firewall. Network namespaces seems like a better solution.

          • the_third@feddit.de
            link
            fedilink
            English
            arrow-up
            0
            ·
            8 months ago

            I haven’t found the time to research an answer for you, sorry. The way I’d go is: create a veth of your physical uplink and stuff it into its own namespace with dhcp client and wg userspace tools. Do not configure the original interface in your initial namespace. Use the approach wg-netns uses to spawn the tunnel interface in initial network ns. Done.

  • Optional@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 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?

    • azuth@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 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.

  • LordCrom@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 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

      • LordCrom@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 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

  • kinther@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 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.

  • dgmib@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 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.

    • bdonvr@thelemmy.club
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 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

    • wreleven@lemmy.ca
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 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.

    • GamingChairModel@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 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.

      • dgmib@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 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.

        • GamingChairModel@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          8 months ago

          That’s a fair point, you’re right.

          I do still think that a lot of people do use VPNs in public spaces for privacy from an untrusted provider, though, perhaps more than your initial comment seemed to suggest.

        • Natanael@slrpnk.net
          link
          fedilink
          English
          arrow-up
          0
          ·
          8 months ago

          Plaintext connections inside corporate networks can still be MITM’ed if the adversary knows what they’re targeting, while they can’t connect to the corporate network they can still steal credentials