Login
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.
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.”
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.
ConnectWise, which offers a self-hosted, remote desktop software application that is widely used by Managed Service Providers (MSPs), is warning about an unusually sophisticated phishing attack that can let attackers take remote control over user systems when recipients click the included link. The warning comes just weeks after the company quietly patched a vulnerability that makes it easier for phishers to launch these attacks.
A phishing attack targeting MSP customers using ConnectWise.
ConnectWise Control is extremely popular among MSPs that manage, protect and service large numbers of computers remotely for client organizations. Their product provides a dynamic software client and hosted server that connects two or more computers together, and provides temporary or persistent remote access to those client systems.
When a support technician wants to use it to remotely administer a computer, the ConnectWise website generates an executable file that is digitally signed by ConnectWise and downloadable by the client via a hyperlink.
When the remote user in need of assistance clicks the link, their computer is then directly connected to the computer of the remote administrator, who can then control the client’s computer as if they were seated in front of it.
While modern Microsoft Windows operating systems by default will ask users whether they want to run a downloaded executable file, many systems set up for remote administration by MSPs disable that user account control feature for this particular application.
In October, security researcher Ken Pyle alerted ConnectWise that their client executable file gets generated based on client-controlled parameters. Meaning, an attacker could craft a ConnectWise Control client download link that would bounce or proxy the remote connection from the MSP’s servers to a server that the attacker controls.
This is dangerous because many organizations that rely on MSPs to manage their computers often set up their networks so that only remote assistance connections coming from their MSP’s networks are allowed.
Using a free ConnectWise trial account, Pyle showed the company how easy it was to create a client executable that is cryptographically signed by ConnectWise and can bypass those network restrictions by bouncing the connection through an attacker’s ConnectWise Control server.
“You as the attacker have full control over the link’s parameters, and that link gets injected into an executable file that is downloaded by the client through an unauthenticated Web interface,” said Pyle, a partner and exploit developer at the security firm Cybir. “I can send this link to a victim, they will click this link, and their workstation will connect back to my instance via a link on your site.”
A composite of screenshots researcher Ken Pyle put together to illustrate the ScreenConnect vulnerability.
On Nov. 29, roughly the same time Pyle published a blog post about his findings, ConnectWise issued an advisory warning users to be on guard against a new round email phishing attempts that mimic legitimate email alerts the company sends when it detects unusual activity on a customer account.
“We are aware of a phishing campaign that mimics ConnectWise Control New Login Alert emails and has the potential to lead to unauthorized access to legitimate Control instances,” the company said.
ConnectWise said it released software updates last month that included new protections against the misdirection vulnerability that Pyle reported. But the company said there is no reason to believe the phishers they warned about are exploiting any of the issues reported by Pyle.
“Our team quickly triaged the report and determined the risk to partners to be minimal,” said Patrick Beggs, ConnectWise’s chief information security officer. “Nevertheless, the mitigation was simple and presented no risk to partner experience, so we put it into the then-stable 22.8 build and the then-canary 22.9 build, which were released as part of our normal release processes. Due to the low severity of the issue, we didn’t (and don’t plan to) issue a security advisory or alert, since we reserve those notifications for serious security issues.”
Beggs said the phishing attacks that sparked their advisory stemmed from an instance that was not hosted by ConnectWise.
“So we can confirm they are unrelated,” he said. “Unfortunately, phishing attacks happen far too regularly across a variety of industries and products. The timing of our advisory and Mr. Pyle’s blog were coincidental. That said, we’re all for raising more awareness of the seriousness of phishing attacks and the general importance of staying alert and aware of potentially dangerous content.”
The ConnectWise advisory warned users that before clicking any link that appears to come from their service, users should validate the content includes “domains owned by trusted sources,” and “links to go to places you recognize.”
But Pyle said this advice is not terribly useful for customers targeted in his attack scenario because the phishers can send emails directly from ConnectWise, and the short link that gets presented to the user is a wildcard domain that ends in ConnectWise Control’s own domain name — screenconnect.com. What’s more, examining the exceedingly long link generated by ConnectWise’s systems offers few insights to the average user.
“It’s signed by ConnectWise and comes from them, and if you sign up for a free trial instance, you can email people invites directly from them,” Pyle said.
ConnectWise’s warnings come amid breach reports from another major provider of remote support technologies: GoTo disclosed on Nov. 30 that it is investigating a security incident involving “unusual activity within our development environment and third-party cloud storage services. The third-party cloud storage service is currently shared by both GoTo and its affiliate, the password manager service LastPass.
In its own advisory on the incident, LastPass said they believe the intruders leveraged information stolen during a previous intrusion in August 2022 to gain access to “certain elements of our customers’ information.” However, LastPass maintains that its “customer passwords remain safely encrypted due to LastPass’s Zero Knowledge architecture.”
In short, that architecture means if you lose or forget your all-important master LastPass password — the one needed to unlock access to all of your other passwords stored with them — LastPass can’t help you with that, because they don’t store it. But that same architecture theoretically means that hackers who might break into LastPass’s networks can’t access that information either.
Update, 7:25 p.m. ET: Included statement from ConnectWise CISO.
FreshRSS 