Today’s news is detailing a novel CVE, TunnelVision (CVE-2024-3661). Which allows attackers “to force a target user’s traffic off their VPN tunnel using built-in features of DHCP.” Leviathan Security Group provides a proof of concept in the linked article, as well as, more detailed findings.
Along side this, is another vulnerability reportedly found by a Reddit user two weeks ago (April 22nd), regarding VPNs leaking DNS traffic on Androids. MULLVAD released an article with a proof of concept on May 3rd. This is the vulnerability we will be testing today using tcpdump on a router/WAP flashed with OpenWrt.
Below are the steps provided by MULLVAD:
- Download spam_get_requests.html
On your Android device. The page also works without downloading, just by opening it in the browser and pressing “Start”. - Install the WireGuard app & Chrome
On your Android device. I’ll be testing it out with PIA VPN’s app, which uses WireGuard tunnels, with both Chrome and Opera GX, which is based on Chrome. - Import wg1.conf, wg2.conf into WireGuard
This lets you quickly switch between them. Demonstrating the leak that occurs between switching tunnels, or disabling the VPN. Which should block all traffic due to a setting we’ll enable in step 5. - Enable wg1 tunnel in the WireGuard app and allow the VPN permission
- In Android VPN settings enable “Always-on VPN” & “Block connections without VPN” for WireGuard
Found under Connections > More connection settings > VPN > WireGuard/PIA VPN and pressing the gear icon on the latest version of Android OS.
- Start capturing data on your router by using e.g:
tcpdump -i <INTERFACE> host <IP of android device>
We find the interface name on OpenWrt’s web GUI, under Network > Interfaces, and choosing the one your phone is connected to over WiFi. Mine is connected to gh0s7H0us3, which uses the interface br-lan.
Host IP is the IP assigned to your phone on the local network. We can find it on pfSense’s web GUI, under Status > DHCP Leases. Mine currently is 10.0.0.145.
Using a laptop or desktop connected to the same network, SSH into your OpenWrt router/WAP with:
ssh root@<router/WAP’s local IP>
Accept the fingerprint and login with your credentials.
From here, you’ll need to update the package repos on OpenWrt. Which, I’m told, only saves to RAM. So, you’ll need to do this every time you install a new program through SSH. Then install tcpdump.
opkg update
opkg install tcpdump
After that finishes, I use the following command to enable it to listen for the traffic we’re looking for. Don’t forget to replace the interface and host IP with your own.
tcpdump -i br-lan udp and host 10.0.0.145 and port 53
- Split the screen to show both WireGuard & Chrome side by side
Chrome should be able to run in the background, either way. - Open spam_get_requests.html with Chrome & press “Start”
The button may appear really small without zooming in.
- Toggle back and fourth between wg1 and wg2 in the WireGuard app until you see the leaks in the next step.
This works the same and toggling just the one, or turning PIA VPN on and off. - Observe DNS traffic similar to this on the router:
10.0.0.1.53 (The network gateway’s IP through port 53, DNS.) and 10.0.0.145.# (My phone’s IP through a temporary ephemeral port.) are communicating in plain text, despite being configured to do otherwise.
My Observations
PIA VPN has the same issue as WireGuard itself. Though I do have it configured to use WireGuard tunnels, due to how much faster they are.
Opera GX, despite being based on Chrome, was worse. Spilling a constant stream between the VPN being toggled on and off. Which, in my personal experience, is pretty par for it’s course.
According to MULLVAD, this issue isn’t on either the browser, or VPN’s plate, however. Stating that the primary fault lies with the OS. Due to the main issue being that the “Block connections without VPN” apparently not working as intended. This lines up with the other CVE, TunnelVision (CVE-2024-3661), owing it’s existence to built in DHCP features. Leaving VPNs on a rough streak in recent weeks.
Post Script
I’d like to thank everyone for their patience in the Home Lab guide’s delay. Even though this post uses software and configurations that those guides would have explained, had it been completed by now. I just really want to make sure every configuration I suggest using in it, is up to my standard. As such, I know I shouldn’t be making another promise intend to release a guide to pentest your own home network. Once I complete that, and feel confident in my network’s configuration, then I’ll be content publishing a guide on setting up your home network in a similar fashion.