The Curious Case of Apple iOS IKEv2 VPN On Demand

TL;DR

Apple’s iOS IKEv2 VPN On Demand may leak traffic when it is unable to establish an IPSEC tunnel to the defined VPN gateway. We’ve reported this to Apple, and after analysing it they didn’t consider it a security issue.

Details

VPN On Demand is a feature from iOS (and OSX) that allows the enforcement of a specific set of rules when the connection being used by the iOS device requires a specific VPN connection in order to proceed. According to Apple’s own documentation, rules can trigger things such as “Recognise when an unknown Wi-Fi network is being used and require VPN for all network activity”.

We’ve identified that not all network activity is actually sent through the VPN, even when explicitly required, when the IPSEC tunnel is not fully established. We don’t know the exact reason, but it happens when the device is attempting to establish an IPSEC tunnel, but fails to get a reply from the VPN server.

We’ve confirmed this behaviour by connecting the iOS device to a wireless network where we blocked all IPSEC traffic. The result was that from time to time some of the traffic the iOS device was attempting to send via the IPSEC tunnel ended up being transmitted in clear.

For testing we configured a VPN server and an iOS device with a provisioning profile for an IKEv2 VPN On Demand configuration, using the excellent AlgoVPN set of scripts. The configuration forced the use of a VPN whenever it is connected to unknown wireless networks.

At the wireless router we dropped all outbound traffic to our VPN gateway’s IP address (represented by 95.yyy.yyy.yyy on the image below), to ensure that IPSEC failed, and connected the iOS device to the wireless network. On the device we also attempted to access an external website on port 80 using safari (this host is represented by the IP 164.xxx.xxx.xxx on the image below). We captured all the traffic sent from the iOS device on our router internal interface.

Looking at the captured packets (initial DHCP and DNS traffic omitted for brevity), we see how after a few attempts of connecting the IPSEC tunnel a burst of TCP traffic is passed outside the tunnel:

Right at the end, the attempts to connect the tunnel continue, as traffic to the VPN server continues being dropped.

During the burst, which lasts less than half a second, it is possible to see connections to Apple’s push notification service servers (all those IP addresses from the 17.0.0.0/8 class A network) and our connection to the 164.xxx.xxx.xxx website on port 80, which is successful and returns the webpage content to our browser.

From a user perspective it appears to simply be an extremely slow connection (it took around 12 seconds to receive a reply), until the page loads in one burst.

What could an attacker see?

If the victim is using an open wifi network and the IPSEC connection fails for some reason, which is quite common on free WiFi hotspots that block anything that’s not HTTP(s), a passive eavesdropper will be able to see not only DNS traffic, but also bursts of other traffic. If the connections are from a clear text protocol, such as HTTP, the passive attacker may be able to obtain partial contents.

In an active attack scenario when the attacker is able to perform a man-in-the-middle attack, this behaviour can be forced by blocking any IPSEC related traffic.

Mitigations

Apple stated during our communications that only Always-On VPN will ensure all traffic is tunneled. However, this requires that the device is supervised, which will be a limitation to regular (non enterprise) users.

We’ve not observed the behaviour described above when using a WireGuard On Demand setup. When using WireGuard with an On-Demand configuration all traffic was either sent via the WireGuard tunnel, or not sent at all, as one would expect.

Do keep in mind that if you’re using a hostname for the server endpoint address, initial DNS request will always have to be performed by the client outside of the VPN tunnel.

Conclusion

We were surprised to see this behaviour in a functionality which aims to provide privacy to connections through untrusted networks. We were even more surprised that Apple does not consider this to have a security impact. We hope that Apple ends up fixing this issue, which we consider a vulnerability, with the VPN On Demand.

Timeline

• 25 Feb 2019 - Details sent to Apple;
• 27 Feb 2019 - Apple acknowledged, assigned ID 709646100, and is investigating the report;
• 5 Mar 2019 - Apple states they do not see security implications, and that users should use Always-On VPN to ensure all traffic is tunneled;
• 6 Mar 2019 - We contest the assessment, and provide links to Apple’s own documentation where it doesn’t state anywhere that traffic may not be tunneled when using On-Demand VPN;
• 7 Mar 2019 - Apple replies that it is continuing the investigation on the report;
• 9 Apr 2019 - Request Apple for a status on the issue;
• 11 Apr 2019 - Apple replies that they still don’t see any security implications, and that users should use Always-On VPN to ensure that all traffic is tunneled, and provides a link to their iOS Deployment Reference at https://help.apple.com/deployment/ios/#/iore8b083096;
• 11 Apr 2019 - We inform Apple that in this case we will publish the issue.
• 29 Apr 2019 - Article published

References

• iOS Deployment Reference - VPN On Demand - https://help.apple.com/deployment/ios/#/iord4804b742
• WireGuard - https://www.wireguard.com/
• AlgoVPN - https://github.com/trailofbits/algo