Apple
Apple introduced a privacy-enhancing feature that concealed the Wi-Fi address of iPhones and iPads when they connected to a network three years ago. However, it has now been revealed that the feature has never functioned as intended. Despite assurances that the unchangeable address would be hidden and replaced with a unique private address for each network, Apple devices have continued to display the real address, which subsequently gets broadcasted to every other connected device on the network.
The issue arises from the fact that a Wi-Fi media access control address, commonly known as a MAC address, can be utilized to track individuals as they move from network to network, similar to how a license plate number tracks a vehicle’s movement within a city. In 2013, a researcher demonstrated a proof-of-concept device that logged the MAC addresses of all devices it encountered. The objective was to deploy numerous devices throughout a neighborhood or city and compile a profile of iPhone users, including the social media platforms they visited and the various locations they frequented each day.
As previously reported:
Enter CreepyDOL, a low-cost, distributed network of Wi-Fi sensors that stalks people as they move about neighborhoods or even entire cities. At 4.5 inches by 3.5 inches by 1.25 inches, each node is small enough to be slipped into a wall socket at the nearby gym, cafe, or break room. And with the ability for each one to share the Internet traffic it collects with every other node, the system can assemble a detailed dossier of personal data, including the schedules, e-mail addresses, personal photos, and current or past whereabouts of the person or people it monitors.
In 2020, Apple released iOS 14, which featured a default setting that concealed Wi-Fi MAC addresses when devices connected to a network. Instead, the device would display a “private Wi-Fi address” unique to each network. Over time, Apple has improved this feature, including the ability for users to assign a new private Wi-Fi address for a specific network.
Apple recently released iOS 17.1, which addressed various issues and vulnerabilities, including a patch for a vulnerability (CVE-2023-42846) that prevented the privacy feature from working. Tommy Mysk, one of the security researchers credited with discovering and reporting the vulnerability, stated that the flaw has existed since the release of iOS 14 in September 2020.
Mysk explained, “From the beginning, this feature has been ineffective due to this bug. We were unable to prevent the devices from sending these discovery requests, even with a VPN, or even in Lockdown Mode.”
When an iPhone or any other device joins a network, it sends a multicast message to all other devices on the network. This message inherently includes a MAC address. Starting with iOS 14, this value was, by default, unique for each network.
At first glance, the feature appeared to work as intended, with the request listing the “private Wi-Fi address” as the source. However, upon closer inspection, it became evident that the actual, permanent MAC address was still being broadcasted to all connected devices, albeit through a different field in the request.
Mysk published a short video demonstrating how a Mac using the Wireshark packet sniffer captures traffic on the local network it’s connected to. When an iPhone running iOS prior to version 17.1 joins the network, it transmits its actual Wi-Fi MAC address on port 5353/UDP.
Upgrade to iOS 17.1 to prevent your iPhone from being tracked across Wi-Fi networks.
For the majority of iPhone and iPad users, the impact of this revelation is likely minimal, if at all. However, for individuals with strict privacy concerns, the failure to hide the real MAC addresses for three years could pose a significant problem, especially considering Apple’s explicit claim that using the feature “helps reduce tracking of your iPhone across different Wi-Fi networks.”
Apple has not provided an explanation for how such a fundamental flaw remained unnoticed for such a long period of time. The company’s advisory simply states that the fix involved “removing the vulnerable code.”
