Blog

Apple tracking bugs - lost and found

Written by Piers O'Hanlon September 2015.

In March of this year I was investigating the privacy properties of the protocols used by mobile devices when they attach to the network. During this process I discovered some bugs in Apple's implementation of a protocol which meant that it could potentially allow for tracking of the previous points of attachment of a device, and hence its user, when moving between WiFi networks. Specifically a malicious actor could potentially discover the addresses of recently visited WiFi Access Points (AP), and the order in which they were seen. In some cases these addresses could also be used to discover the location of these APs. These bugs were discovered in a subsystem, known as 'bootp', which is common to both Apple's mobile (iOS), and desktop (OSX) operating systems, thus both platforms were affected. We used a responsible disclosure approach to inform Apple of these bugs, which have now been logged in the MITRE Corporation's Common Vulnerabilities and Exposure (CVE) system as CVE-2015-3778. Apple's most recent updates, released on the 13 August 2015, largely fix these bugs, as described in the security advisories, for iOS 8.4.1 and OSX 10.10.5.

The specific protocol responsible for this behaviour is known as Detection of Network Attachment for IPv4 (DNA - not to be confused with biological DNA!), which is standardised by the Internet standard's body, the Internet Engineering Task Force (IETF), as RFC4436. This protocol is used to speed up the process of connection to the Internet by mobile devices. It is mainly used by Apple devices in their mobile (iOS), and desktop (OSX) operating systems, although Google also use it to a lesser extent in their ChromeOS operating system which runs on their ChromeBooks.

As is the case in many systems there are trade-offs to be made when trying to provide for both privacy and performance. And in the case of DNA the protocol attempts to utilise information about previous recent points of attachment (e.g. WiFi Access Point's link layer MAC address) to speed up the connection at subsequent points of attachment with the aim of reducing reconnection times when revisiting previous networks.  The privacy issue with DNA is that when a device connects to any new network it then attempts a 'reachability test' to the addresses of previous APs thus revealing their addresses to the network and potentially anyone else in WiFi range. The protocol specification (RFC4436) doesn't actually draw a distinction between the use of DNA on secured versus public networks, nor does it specify any dependence upon the name of the WiFi network.

The protocol was initially implemented as described in the RFC, however in 2012 Mark Wuergler of Immunity, Inc. reported the privacy issues (CVE-2012-3725) to Apple and as described in their security advisory HT202615 for iOS 6 they attempted to fix the privacy problem. They tried to do this by limiting the use of DNA so that it only reuses cached AP MAC addresses on their correspondingly named WiFi networks, thus keeping most of the performance benefits of DNA and limiting the privacy issues. Unfortunately their 'fix' contained the bugs that I discovered which actually negatively impacted the performance, whilst providing no improvement to the privacy aspects of the protocol, so Apple mobile devices continued to leak such information. Furthermore their description of the fix ('This issue was addressed by disabling DNA on unencrypted Wi-Fi networks') in the security advisory was incorrect.

Once Apple released their latest fix I tested the behaviour of an updated iPhone running iOS 8.4.1 and was able to confirm that they appear to have fixed the issue in the way they had planned in 2012. However their description of the fix ('This issue was addressed through disabling DNAv4 on unencrypted Wi-Fi networks') was still incorrect - they basically reused their incorrect description of the fix from 2012. They have confirmed that they will be amending this description.

I was able to ascertain these problems in Apple's systems partly due to the fact that they provide open source access to the code for a number of their software systems. However the source code is not usually available for their latest systems so I also had to do some 'black box' testing to check what was going on in their actual implementations.

It should be noted that they do not appear to have addressed the issue of ordering of DNA reachability tests. This may seem a minor point but the range of WiFi access point names is not that unique, and most users utilise a more limited subset of networks which provide widespread coverage (e.g. The Cloud, BTWifi, Starbucks etc) so these network providers can allow for ordered DNA based tracking. Furthermore it is also trivial for a malicious actor to set up a WiFi Access Point (or Hot Spot) that matches an AP of interest to elicit and capture DNA interactions of interest.

 

Piers O'Hanlon is a Researcher at the Oxford Internet Institute. His work on the Being There project focusses on providing for enhanced consensual privacy for robots and mobile devices. Specifically he is looking at ways in which the link layer interactions may be modified to provide for more privacy.

At the Oxford Internet Institute his research tackles aspects of privacy and security, having worked on sensor systems, and smart home devices. Previously, at University College London, he worked on networked multimedia transport, congestion control, grid, and security systems. He is an active participant in the Internet Engineering Task Force (IETF), having authored a number of standards and drafts in congestion control, emergency services, and signalling areas.

He has also had a long standing collaboration with artists and has been involved with work that has shown in a number of galleries around the world, including Dream Speculator and Onomatopoeia.

To read more about the Oxford Internet Institute's work in the Being There project please visit their project page.