Private I: Hijacked DNS puts iOS virtual private networks at slight risk
A VPN creates an encrypted "tunnel" between two endpoints, one on a computer or mobile device and another on a server in a data center (for public VPNs, like Cloak, TunnelBear, and many others) or on a company's network. This tunnel is designed to prevent sniffing of a connection at a public place and over broadband networks.
The research paper points to two key weaknesses they were able to exploit in several popular VPN services' apps, some of which are also available for other platforms, using three common protocols: PPTP, L2TP, and OpenVPN. While iOS and OS X also support PPTP and L2TP for establishing and encrypting a connection, Cloak's Dave Peck and Peter Sagerson, two of its three founders, built a proof of concept that shows an additional protocol, IPsec, is susceptible to one of the exploits.
Peck says that because of how Apple has built IPsec into iOS, any VPN client using that protocol--including Cloak--could be fooled. The company filed a report in Apple's bug-tracking system yesterday (mirrored here), and posted a security notice today on its site. Macworld asked Apple for a comment, and will update this story if one becomes available.
While the severity is high, the risk of wide-scale exploitation is low. Let's get into the details.
How the hijacking works
The five authors of "A Glance through the VPN Looking Glass" found two unique problems in examining commercially available VPN client software. The first relates to IPv6 networking, which doesn't seem to affect iOS and can be worked around in OS X. The second involves DNS (domain name system) hijacking. In both cases, the integrity of the secure tunnel isn't affected. Rather, it's the ability to intercept a subset of traffic that's at stake, allowing a malicious party to act as a man-in-the-middle.
DNS hijacking potentially affects any connection made through the VPN. In the exploit described in the paper, a ne'er-do-well has to hijack local network address assignment using DHCP (Dynamic Host Configuration Protocol). On public networks, a device first connects to the network, and then a DHCP server in the network's router assigns it a local address, and provides a network range for the local network and DNS server details.
In the hijack, an attacker subverts DHCP, typically by creating an "evil twin" hotspot, which is a router that has the name or names of a nearby Wi-Fi network. It's also possible to grab a list of networks that any computer or mobile has connected to in the past, and serve up one of those to capture it.
Once the association is made, the bad guys' DHCP server provides an illegitimate address range that tells the requesting device it's on the same Internet network segment as the DNS server that the VPN client relies on. In many cases, this is Google's Public DNS service, for which the primary address is 8.8.8.8. (Because a VPN server typically provides its own DNS server addresses, just swapping in malicious DNS servers via DHCP doesn't work.)
By fooling the device into thinking it's on the same network segment, it allows the malicious router to provide responses to DNS requests, which would be ignored if a proper local network assignment were made. The router acts as a gateway to pass through all traffic the attackers aren't interested in, and then uses either a local or remote proxy to intercept desired web or other sessions at the other end of the VPN tunnel. That is, a user enters a website address, the false DNS server provides an alternate address, and the connection is made through the other end of the tunnel. To an intercepted user, the session looks normal, but an attacker is sitting in the middle as a relay.
Cloak's Peck and Sagerson were able to duplicate this subversion in iOS using IPsec with about two hours' work by setting up their own malicious test system. Peck says, "We found ways to manipulate the routing table to make these attacks."
The two wanted to highlight this problem because the paper's authors suggest effective mitigation for DNS hijacking with PPTP, an outdated and broken standard still in use at times, and L2TP, a more modern one. The paper says by putting a DNS server in the same network range as the VPN's gateway address, the hijacking can't work with these two standards as well as another called OpenVPN.
However, for IPsec, which Apple has put its development weight behind in iOS, there's no workaround. The proposed mitigation has a VPN service set the address of DNS servers to be in the same network range as the VPN server's gateway address. But with IPsec, there's no concept of a gateway address, Sagerson says, so the mitigation isn't possible.
Apple would need to make low-level, but not difficult changes to iOS's networking stack, the set of software that handles Internet and other communications, to require an explicit route to one or more DNS servers when the VPN client connects.
A limited set of risks
The good news about this exploit is that while it is severe in its nature, it's very to extremely limited in how it might be turned against VPN users.
First, the hijacking doesn't subvert secure web, email, or other connections. For banking, ecommerce, and an increasing number of other sites, an https (SSL/TLS) connection is the default. If an attacker tries to break in on such a connection by presenting a fake certificate, browsers and other software alerts a user that the certificate is invalid. This attack doesn't help with that at all.
If all your surfing is secure, then VPN-related DNS hijacking doesn't affect you, but then there's little reason to use a VPN, either. Peck notes, "If you're only talking to https sites, you probably don't need a VPN." (Peck jokes that his company's goal is to put themselves out of business, as they find it desirable that all routine traffic on the Internet is strongly encrypted.)
Second, it doesn't crack the reliability of the VPN tunnel. While PPTP as a standard is broken and shouldn't be used, L2TP, IPsec, and OpenVPN are reliable when configured correctly, and this new research doesn't change that.
Third, an attacker has to have proximity to where people are connecting to Wi-Fi in large numbers and using VPNs. While there are many ways to attack routers remotely and potentially insert malicious software, that's a far more severe problem, affecting every user of such subverted networks for all non-encrypted connections. This DHCP-plus-DNS hijacking technique might be yet another tool in that arsenal.
It's possible other researchers will use this work to find more easily or broadly exploitable problems in VPN setups in iOS and on other platforms. But now that the details are out, operating system and VPN client developers will be fixing holes. Some of the makers of software mentioned in the paper dispute their software is vulnerable or have made changes since hearing from the researchers or for routine reasons that they told the TorrentFreak site resolve one or both categories of exploit in the paper.
Cloak contacted me, reported to Apple, and posted a blog entry in the interests of making sure the scope of the problem was known early and being straightforward with its customers about even the slightest risk. Peck says, "From the perspective of a VPN provider, anything that effectively removes the protection of the VPN itself is crappy."