Virtual private networking (VPN) companies market their services as a way to prevent anyone from snooping on your Internet usage. But new research suggests this is a dangerous assumption when connecting to a VPN via an untrusted network, because attackers on the same network could force a target’s traffic off of the protection provided by their VPN without triggering any alerts to the user.

Image: Shutterstock.

When a device initially tries to connect to a network, it broadcasts a message to the entire local network stating that it is requesting an Internet address. Normally, the only system on the network that notices this request and replies is the router responsible for managing the network to which the user is trying to connect.

The machine on a network responsible for fielding these requests is called a Dynamic Host Configuration Protocol (DHCP) server, which will issue time-based leases for IP addresses. The DHCP server also takes care of setting a specific local address — known as an Internet gateway — that all connecting systems will use as a primary route to the Web.

VPNs work by creating a virtual network interface that serves as an encrypted tunnel for communications. But researchers at Leviathan Security say they’ve discovered it’s possible to abuse an obscure feature built into the DHCP standard so that other users on the local network are forced to connect to a rogue DHCP server.

“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,” Leviathan researchers Lizzie Moratti and Dani Cronce wrote. “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.”

The feature being abused here is known as DHCP option 121, and it allows a DHCP server to set a route on the VPN user’s system that is more specific than those used by most VPNs. Abusing this option, Leviathan found, effectively gives an attacker on the local network the ability to set up routing rules that have a higher priority than the routes for the virtual network interface that the target’s VPN creates.

“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,” the Leviathan researchers said. “This is intended functionality that isn’t clearly stated in the RFC [standard]. 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.”

Leviathan found they could force VPNs on the local network that already had a connection to arbitrarily request a new one. In this well-documented tactic, known as a DHCP starvation attack, an attacker floods the DHCP server with requests that consume all available IP addresses that can be allocated. Once the network’s legitimate DHCP server is completely tied up, the attacker can then have their rogue DHCP server respond to all pending requests.

“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,” the researchers wrote. “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 researchers say their methods could be used by an attacker who compromises a DHCP server or wireless access point, or by a rogue network administrator who owns the infrastructure themselves and maliciously configures it. Alternatively, an attacker could set up an “evil twin” wireless hotspot that mimics the signal broadcast by a legitimate provider.

ANALYSIS

Bill Woodcock is executive director at Packet Clearing House, a nonprofit based in San Francisco. Woodcock said Option 121 has been included in the DHCP standard since 2002, which means the attack described by Leviathan has technically been possible for the last 22 years.

“They’re realizing now that this can be used to circumvent a VPN in a way that’s really problematic, and they’re right,” Woodcock said.

Woodcock said anyone who might be a target of spear phishing attacks should be very concerned about using VPNs on an untrusted network.

“Anyone who is in a position of authority or maybe even someone who is just a high net worth individual, those are all very reasonable targets of this attack,” he said. “If I were trying to do an attack against someone at a relatively high security company and I knew where they typically get their coffee or sandwich at twice a week, this is a very effective tool in that toolbox. I’d be a little surprised if it wasn’t already being exploited in that way, because again this isn’t rocket science. It’s just thinking a little outside the box.”

Successfully executing this attack on a network likely would not allow an attacker to see all of a target’s traffic or browsing activity. That’s because for the vast majority of the websites visited by the target, the content is encrypted (the site’s address begins with https://). However, an attacker would still be able to see the metadata — such as the source and destination addresses — of any traffic flowing by.

KrebsOnSecurity shared Leviathan’s research with John Kristoff, founder of dataplane.org and a PhD candidate in computer science at the University of Illinois Chicago. Kristoff said practically all user-edge network gear, including WiFi deployments, support some form of rogue DHCP server detection and mitigation, but that it’s unclear how widely deployed those protections are in real-world environments.

“However, and I think this is a key point to emphasize, an untrusted network is an untrusted network, which is why you’re usually employing the VPN in the first place,” Kristoff said. “If [the] local network is inherently hostile and has no qualms about operating a rogue DHCP server, then this is a sneaky technique that could be used to de-cloak some traffic – and if done carefully, I’m sure a user might never notice.”

MITIGATIONS

According to Leviathan, there are several ways to minimize the threat from rogue DHCP servers on an unsecured network. One is using a device powered by the Android operating system, which apparently ignores DHCP option 121.

Relying on a temporary wireless hotspot controlled by a cellular device you own also effectively blocks this attack.

“They create a password-locked LAN with automatic network address translation,” the researchers wrote of cellular hot-spots. “Because this network is completely controlled by the cellular device and requires a password, an attacker should not have local network access.”

Leviathan’s Moratti said another mitigation is to run your VPN from inside of a virtual machine (VM) — like Parallels, VMware or VirtualBox. VPNs run inside of a VM are not vulnerable to this attack, Moratti said, provided they are not run in “bridged mode,” which causes the VM to replicate another node on the network.

In addition, a technology called “deep packet inspection” can be used to deny all in- and outbound traffic from the physical interface except for the DHCP and the VPN server. However, Leviathan says this approach opens up a potential “side channel” attack that could be used to determine the destination of traffic.

“This could be theoretically done by performing traffic analysis on the volume a target user sends when the attacker’s routes are installed compared to the baseline,” they wrote. “In addition, this selective denial-of-service is unique as it could be used to censor specific resources that an attacker doesn’t want a target user to connect to even while they are using the VPN.”

Moratti said Leviathan’s research shows that many VPN providers are currently making promises to their customers that their technology can’t keep.

“VPNs weren’t designed to keep you more secure on your local network, but to keep your traffic more secure on the Internet,” Moratti said. “When you start making assurances that your product protects people from seeing your traffic, there’s an assurance or promise that can’t be met.”

A copy of Leviathan’s research, along with code intended to allow others to duplicate their findings in a lab environment, is available here.

The Minnesota-based Internet provider U.S. Internet Corp. has a business unit called Securence, which specializes in providing filtered, secure email services to businesses, educational institutions and government agencies worldwide. But until it was notified last week, U.S. Internet was publishing more than a decade’s worth of its internal email — and that of thousands of Securence clients — in plain text out on the Internet and just a click away for anyone with a Web browser.

Headquartered in Minnetonka, Minn., U.S. Internet is a regional ISP that provides fiber and wireless Internet service. The ISP’s Securence division bills itself “a leading provider of email filtering and management software that includes email protection and security services for small business, enterprise, educational and government institutions worldwide.”

U.S. Internet/Securence says your email is secure. Nothing could be further from the truth.

Roughly a week ago, KrebsOnSecurity was contacted by Hold Security, a Milwaukee-based cybersecurity firm. Hold Security founder Alex Holden said his researchers had unearthed a public link to a U.S. Internet email server listing more than 6,500 domain names, each with its own clickable link.

A tiny portion of the more than 6,500 customers who trusted U.S. Internet with their email.

Drilling down into those individual domain links revealed inboxes for each employee or user of these exposed host names. Some of the emails dated back to 2008; others were as recent as the present day.

Securence counts among its customers dozens of state and local governments, including: nc.gov — the official website of North Carolina; stillwatermn.gov, the website for the city of Stillwater, Minn.; and cityoffrederickmd.gov, the website for the government of Frederick, Md.

Incredibly, included in this giant index of U.S. Internet customer emails were the internal messages for every current and former employee of U.S. Internet and its subsidiary USI Wireless. Since that index also included the messages of U.S. Internet’s CEO Travis Carter, KrebsOnSecurity forwarded one of Mr. Carter’s own recent emails to him, along with a request to understand how exactly the company managed to screw things up so spectacularly.

Individual inboxes of U.S. Wireless employees were published in clear text on the Internet.

Within minutes of that notification, U.S. Internet pulled all of the published inboxes offline. Mr. Carter responded and said his team was investigating how it happened. In the same breath, the CEO asked if KrebsOnSecurity does security consulting for hire (I do not).

[Author’s note: Perhaps Mr. Carter was frantically casting about for any expertise he could find in a tough moment. But I found the request personally offensive, because I couldn’t shake the notion that maybe the company was hoping it could buy my silence.]

Earlier this week, Mr. Carter replied with a highly technical explanation that ultimately did little to explain why or how so many internal and customer inboxes were published in plain text on the Internet.

“The feedback from my team was a issue with the Ansible playbook that controls the Nginx configuration for our IMAP servers,” Carter said, noting that this incorrect configuration was put in place by a former employee and never caught. U.S. Internet has not shared how long these messages were exposed.

“The rest of the platform and other backend services are being audited to verify the Ansible playbooks are correct,” Carter said.

Holden said he also discovered that hackers have been abusing a Securence link scrubbing and anti-spam service called Url-Shield to create links that look benign but instead redirect visitors to hacked and malicious websites.

“The bad guys modify the malicious link reporting into redirects to their own malicious sites,” Holden said. “That’s how the bad guys drive traffic to their sites and increase search engine rankings.”

For example, clicking the Securence link shown in the screenshot directly above leads one to a website that tries to trick visitors into allowing site notifications by couching the request as a CAPTCHA request designed to separate humans from bots. After approving the deceptive CAPTCHA/notification request, the link forwards the visitor to a Russian internationalized domain name (рпроаг[.]рф).

The link to this malicious and deceptive website was created using Securence’s link-scrubbing service. Notification pop-ups were blocked when this site tried to disguise a prompt for accepting notifications as a form of CAPTCHA.

U.S. Internet has not responded to questions about how long it has been exposing all of its internal and customer emails, or when the errant configuration changes were made. The company also still has not disclosed the incident on its website. The last press release on the site dates back to March 2020.

KrebsOnSecurity has been writing about data breaches for nearly two decades, but this one easily takes the cake in terms of the level of incompetence needed to make such a huge mistake unnoticed. I’m not sure what the proper response from authorities or regulators should be to this incident, but it’s clear that U.S. Internet should not be allowed to manage anyone’s email unless and until it can demonstrate more transparency, and prove that it has radically revamped its security.