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 184.108.40.206. (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.
Sign up for Computerworld eNewsletters.