In 2020, Apple released a feature for iPhone/iPad users that promised a degree of privacy when users joined wireless networks. This week they released an update that fixed the fact that the previous update didn’t work.

The feature Apple rolled out 3 years ago was one which Apple said hid the MAC address of the users device behind a randomly generated one so that other devices on the network couldn’t “see” its true identity and therefore couldn’t track the users activity.

However, the reality is that the feature only removed the MAC address from one data field, so to the untrained eye it looked like the feature was working, but actually the data was there all along in others.

The tech-y bit

Before we can understand why the Apple privacy feature didn’t work as advertised, we need to understand a bit about the tech that allows devices to communicate (and be tracked).

All devices require a unique identifier when connecting to a network, so that the network knows exactly which device (and by extension, which interface) to send data to.

In many networks, especially those which use Ethernet to communicate, this unique identifier is known as a MAC address (MAC = Media Access Control).

The structure of a MAC address typically looks like this – AB:03:02:CA:34:12:AD.

The MAC address is transmitted by a device when it communicates on the network so that all other network devices know who is communicating, and therefore who to communicate with.

The image below shows a raspberry-pi device in my network communicating with another device and transmitting the relevant MAC addresses.

In a wired network that uses network switches as part of the network topology its fairly difficult to eavesdrop on other devices due to how switches manage data-flows, but in wireless networks, the link between the wireless device and the wireless access point is an open channel which anyone can eavesdrop – as such, device MAC addresses can be identified, and therefore be tracked.

MACs, BSSIDs & SSIDs

While devices communicate with MAC addresses, people generally don’t, so to make life a bit easier for us mere humans, we use a name instead of the MAC address to identify wireless devices.

So, in the world of WiFi, an access point MAC address is known as a BSSID – Basic Service Set Identifier, and is the name we give to the WiFi network – such as “Premier Inn Free WiFi”, or some similar name.

The MAC address of device we use is known as the SSID – Service Set Identifier, so for example this could be “Sams iPhone”.

So, whilst we connect Sam’s iPhone to Premier Inn Free WiFi, what we are actually doing is connecting MAC address F0:EE:7A:AB:04:23 to MAC adddress AB:23:CD:00:23:A6 as an example.

The problem

Anyone else in the same WiFi network can see these data packets being broadcast when the phone is connected to the network and harvest the MAC address data of Sam’s iPhone.

This data can then be used to track the device (and by extension – the user) across different networks.

There are many organisations who regularly do this, some are government agencies, some are commercial entities, others are open source systems.

One example of such an organisation is WIGLE (The Wireless Geographic Logging Engine)

WIGLE uses an app which users can download to their devices that constantly scan networks looking for BSSIDs and SSIDs being broadcast by devices, this data is then sent to the WIGLE database for inclusion is a mapping tool that is accessed via wigle.net

WIFI networks and MAC address data scanned by WIGLE
WIGLE.NET network heat map showing London, UK and a superimposed street view of SSIDs & BSSIDs

Using WIGLE.NET, a device can be identified by either SSID or MAC, and the database will identify all places where that device has been “seen”.

In the image below, a device with a BSSID of Sam’s iPhone has been seen in 5 different locations. The user of the device has used the same MAC address to connect to each different network, thus the user is able to be tracked.

If the user connected to each network with a different MAC address every time, then they would not be able to be tracked.

Searching for Sam’s iPhone returns thousands of devices (as seen below) – it is not possible to identify which are the same device.

The solution

If a device uses a different MAC address every time it connects to a network, it makes the act of tracking that device (user) a fruitless task.

Different mobile phone operating systems now offer the user the ability to enable Randomised MAC addresses for this exact reason.

On an android device, the option for this is typically found in the Settings -> Connections -> WIFI -> Current Network settings -> View More.

By default, the option will be to use the Phone MAC, but this can be altered to use a randomised one.

WIFI MAC settings on an Android device

Apple’s problem

Like with Android, AppleOS offers the user the randomised (private) MAC approach, however, what has just been realised is that instead of completely removing the real MAC of the device from all network transmitted packets, Apple only removed it from one fieldof the transmitted packets. The real MAC is still visible in other fields of the packets.

Apple OS Private MAC address

When an Apple device joins a network, it immediately transmits a broadcast packet to see if there are any devices in the network it can connect to to stream data such as music, or films, etc. While the devices real MAC address is not included in the Ethernet frame data, it is included in the multicast DNS query data.

The video below shows this in action.

Apple users Private MAC leaked in multicast DNS query

The fix

Apple have now fixed this “bug” in the latest OS update (iOS17.1) so that finally, the private MAC does what it was always supposed to do, but it just goes to show that you shouldn’t simply take a manufacturers claim to security as gospel – it might just not be all it seems.