Tracking You from a Thousand Miles Away! Turning a Bluetooth Device into an Apple AirTag Without Root Privileges

Tracking You from a Thousand Miles Away! Turning a Bluetooth Device into an Apple AirTag Without Root Privileges

Speakers: Junming Chen

Conference: USENIX Security

YouTube: https://www.youtube.com/watch?v=8BVUrPqkaP4

Overview

This talk, presented by Junming Chen at USENIX Security, unveils a critical security vulnerability within Apple's widely used Find My network. The research, dubbed "Android," demonstrates how nearly any Bluetooth-enabled device – from laptops and smartphones to gaming consoles – can be covertly transformed into a tracking beacon without requiring root privileges or user awareness. By exploiting an overlooked aspect of Bluetooth Low Energy (BLE) advertisement handling and a discrepancy in Apple's Find My protocol implementation, Chen and his team illustrate how an attacker can leverage Apple's global network of devices to achieve precise, street-level tracking of arbitrary Bluetooth devices.

The significance of this discovery cannot be overstated. Apple's Find My network is lauded for its robust privacy protections, employing end-to-end encryption to ensure location data is accessible only to the device owner. This research, however, exposes a fundamental flaw that undermines these assurances, turning a privacy-enhancing feature into a potential instrument for widespread surveillance. It highlights the delicate balance between utility and security in crowdsourced location services and calls into question assumptions about the security of Bluetooth device addressing across various operating systems.

Background

▶ Watch: Introduction to the 'Android' attack on Find My (0:00)

Device location tracking has evolved significantly, moving from imprecise IP-based methods to more granular Wi-Fi and crowdsourced solutions. IP location tracking, while foundational, suffers from severe limitations. In large networks, numerous users might share a single external IP address, making precise physical location determination virtually impossible. This regional accuracy is inadequate for applications demanding street-level precision.

Wi-Fi based location tracking emerged as a more effective alternative. Companies like Apple and Google maintain extensive databases mapping unique identifiers of wireless access points (APs) to their geographic coordinates. Platforms like wiggle.net showcase the impressive coverage of these databases. However, this method faces growing challenges. Its efficacy relies on a pre-existing database, creating "blind spots" in unmapped or unserved areas. Moreover, the increasing adoption of MAC address randomization for devices and now even APs renders existing maps obsolete faster, significantly degrading tracking accuracy over time.

This brings us to crowdsourced tracking, which has revolutionized device location. Systems like Apple's Find My network, Samsung Find My Mobile, and Google Find My Device operate on a principle of mutual assistance: your device helps locate others' lost devices, and in turn, other devices help locate yours. The more participants, the better the coverage and accuracy. Previous research, notably Open Haystack, has provided comprehensive insights into the offline finding mechanisms of Apple's Find My network.

The core of Apple's Find My system for devices like AirTags involves a specific process:

1. An AirTag, paired with an iPhone, exchanges cryptographic material via Bluetooth Low Energy (BLE).
2. If the AirTag loses connection with its paired iPhone, it enters "loss mode" and begins broadcasting BLE advertisements. These are unidirectional, meant to be picked up by any nearby Apple device.
3. Receiving Apple devices collect their current location, generate encrypted location reports, and upload them to Apple's servers.
4. The AirTag owner can then download these reports from Apple's server and use their private key to decrypt them, revealing the AirTag's location.

Privacy is paramount for Apple, especially with its branding around privacy protection. To ensure location reports are exclusive to the owner, Apple employs end-to-end encryption. This allows Apple to claim they do not have access to the location data, mitigating liability. Implementing this within the tight constraints of BLE advertisement payloads (limited to 31 bytes) is challenging. Apple chose the NIST P224 elliptic curve, whose public key occupies 28 bytes. To fit this and other required fields (like the company ID) into the 31-byte limit, Apple cleverly splits the public key into two portions: one stored in the advertisement payload, and the other in the Bluetooth MAC address field.

Traditional Bluetooth MAC addresses are permanent, making devices easily trackable. BLE introduced various types of randomly generated device addresses, such as non-resolvable private addresses (NRPA), resolvable private addresses (RPA), and random static addresses, each distinguished by specific bit patterns. Prior research and Apple's specifications indicated that Find My network used random static addresses, designed to prevent long-term tracking. Open Haystack, a groundbreaking project, reverse-engineered Apple's Find My network, demonstrating how independent developers could access this infrastructure. While valuable for education and experimentation, Open Haystack was not designed for remote attack scenarios due to hardware and physical access constraints.

Key Findings

▶ Watch: Apple Find My network's end-to-end encryption for privacy (3:55)

The research began by attempting to replicate the Open Haystack project. When running the provided script on a Raspberry Pi, the researchers successfully configured the public address, observed it change to match the public key portion, and confirmed that surrounding Apple devices picked up the advertisements. Location reports were downloaded, and the Raspberry Pi was successfully located.

However, a critical anomaly emerged when attempting to port the Open Haystack script to other platforms, such as a PC with a USB Bluetooth dongle. On these systems, the Bluetooth MAC address never changed. This was an unexpected behavior, as the integrity of the Find My tracking relies on the MAC address carrying a portion of the public key. Without the correct public key, decryption of location reports was impossible, preventing device location.

Further investigation into Open Haystack's source code revealed a proprietary command not defined in the official Bluetooth specification being used to change the device's address. More importantly, it was noted that a parameter used to configure advertisements specified the address type as a public address, contradicting earlier understanding and Apple's stated design that the Find My network used random static addresses. This mismatch sparked a deeper inquiry into how Bluetooth addresses are truly interpreted.

The speaker presented an example where a MAC address, based on its leading bits, appeared to be a random static address. Yet, Wireshark, a common network protocol analyzer, identified the same address as belonging to "Expressive Intercorporate," a vendor, implying it was a public address. This apparent contradiction led to a crucial discovery: the common understanding of Bluetooth address types was incomplete. There is an additional bit that determines whether an address is public (permanent, with manufacturer information) or randomly generated. When this bit is '0', it's a public address; when '1', it's a randomly generated address.

This clarified the confusion and led to the most significant finding: Apple's Find My network, contrary to its design specifications, actually accepts more address types than intended, specifically including public addresses. This critical oversight was missed by Apple, Open Haystack, and all derived works.

Another pivotal observation was that on various operating systems—Linux, Android, and Windows—unprivileged applications are allowed to send out Bluetooth advertisements. Specifically, Linux systems, often utilizing the BlueZ Bluetooth stack, were found to implicitly use public addresses when applications send advertisements. This explains why Open Haystack's method of changing a public address on a Raspberry Pi (running Linux) successfully sent out advertisements that were recognized by the Find My network.

The core idea for the "Android" attack then crystallized: if an attacker could craft a private key corresponding to a public key that matches the MAC address of a target Bluetooth device, they could then track that device through the Find My network.

Technical Deep Dive

▶ Watch: Bluetooth payload limit and public key splitting solution (5:10)

The "Android" attack leverages the fundamental observation that Apple's Find My network accepts public Bluetooth addresses despite its design intent to use random static addresses. The attack strategy diverges slightly based on the target operating system due to differences in Bluetooth stack implementations and security models.

For Linux systems, the vulnerability is particularly pronounced. The research investigated 12 popular Linux distributions, all of which use BlueZ as their default Bluetooth stack. BlueZ provides an API through D-Bus that allows unprivileged applications to send out Bluetooth advertisements using the device's public address. This is a critical point of exploitation. Since public addresses are essentially the device's permanent MAC address, and their leading three bytes (the Organizationally Unique Identifier, or OUI) identify the manufacturer, an attacker can anticipate these addresses.

The attack on Linux proceeds as follows:

1. Identify target OUI: The attacker identifies the OUI of a target Bluetooth device (e.g., a specific brand of laptop or gaming console).
2. Pre-compute private keys (Rainbow Table): Knowing that a portion of the public key is embedded in the MAC address, the attacker can pre-compute private keys for all possible MAC addresses associated with known OUIs. This involves generating public/private key pairs (using NIST P224) and checking if the MAC address portion of the public key matches a known OUI. The speaker estimated that storing a rainbow table for all known OUIs would require approximately 20 terabytes of data, which is equivalent to the cost of a $500 hard drive. This pre-computation allows for near-instantaneous matching once a target's OUI is identified.
3. Craft malicious advertisement: Once a matching private key and corresponding public key (split into MAC address and payload portions) are found, the attacker can craft a malicious BLE advertisement.
4. Broadcast via unprivileged application: An unprivileged application on a compromised Linux system (or an attacker-controlled device) can use the BlueZ D-Bus API to broadcast this crafted advertisement, effectively impersonating a legitimate Find My device.
5. Track via Find My network: Any Apple device receiving this advertisement will treat it as a genuine Find My beacon, encrypt its location, and upload it to Apple's servers. The attacker, possessing the corresponding private key, can then decrypt the location reports and track the target device.

Android and Windows present a more complicated scenario. These operating systems typically employ additional layers of protection, such as MAC address randomization and restrictions on applications reading or setting the advertising address without root access. Applications on these platforms can usually only prepare advertisement content, while the system controls the actual broadcasting address.

However, the researchers discovered an ingenious workaround:

1. Mutual VE Address Identification: While an application on Android or Windows cannot directly query its own BLE address from the system, it can read the addresses of other devices from their advertisements.
2. Cooperative Exploitation: If two or more vulnerable Android/Windows devices are within Bluetooth range of each other, they can cooperate. Device A can broadcast a benign advertisement. Device B can then read Device A's actual broadcast MAC address from that advertisement. Device B can then send this address (or a hash of it) back to Device A, or to the attacker. This allows the attacker to infer the MAC address that Device A is using.
3. Rainbow Table Application: Once the actual MAC address of the target Android/Windows device is known, the attacker can use the pre-computed rainbow table (as described for Linux) to find the corresponding private key.
4. Targeted Tracking: With the private key, the attacker can then craft a malicious advertisement that, when broadcast by the target device (or another compromised device nearby), will be picked up by the Find My network and allow tracking.

The researchers also evaluated the cost-effectiveness of this attack. While pre-computing the entire rainbow table is an initial investment, the demand for finding a match in real-time can be met more efficiently by renting cloud GPUs. For instance, renting an RTX 3080 GPU costs just 22 cents per hour, offering an excellent performance-to-cost ratio. In contrast, higher-end GPUs like the H100 were found to be less cost-efficient for this specific task. By leveraging 200 RTX 3080 GPUs, the researchers projected a 90% probability of finding a matching key in just 2.76 minutes, at a total cost of only $2.20. This demonstrates that the attack is not only critical but also remarkably affordable and scalable.

Demo / Proof of Concept

▶ Watch: Prior research: Open Haystack and its experimental nature (6:51)

The core of the demonstration began with the replication of the Open Haystack project. On a Raspberry Pi, the researchers successfully executed the Open Haystack script, which involves configuring a public Bluetooth address to contain a portion of the cryptographic public key. This setup worked as expected: the Raspberry Pi broadcasted advertisements with the manipulated MAC address, and surrounding Apple devices correctly picked them up, generating and uploading encrypted location reports. The researchers were then able to download these reports and accurately locate the Raspberry Pi, confirming the viability of the Find My network for tracking.

The pivotal "demo" of the vulnerability, however, came from the failure of this replication on other platforms. When attempting to run the same script on a standard PC equipped with a USB Bluetooth dongle or on other general-purpose computers, the Bluetooth MAC address would not change. This unexpected behavior was the initial trigger for the deeper investigation into Bluetooth address types and operating system-level handling of BLE advertisements. It demonstrated that while the Open Haystack method worked on some Linux-based systems (like Raspberry Pi), it wasn't universally applicable due to underlying system differences.

Once the root cause (the acceptance of public addresses by the Find My network and the BlueZ stack's handling of these on Linux) was identified, the researchers successfully demonstrated the full tracking capabilities. They measured the real-world performance of this covert tracking mechanism:

• Latency: In a university campus setting, the average time between sending the initial "loss message" (the malicious advertisement) and receiving the corresponding location report was under 7 minutes. In a residential area, this latency slightly increased to 8 minutes. Both figures are well within practical limits for effective real-time tracking, performing comparably to an ordinary Apple AirTag.
• Accuracy: The system proved highly accurate. On average, the estimated location was within 10 feet of the actual ground truth. Furthermore, the researchers tested the system's efficacy in more extreme scenarios, such as tracking an aircraft. Even when the aircraft was flying thousands of feet above ground, the tracking system maintained an accuracy of approximately 200 feet. This level of precision is sufficient for projecting flight paths and gathering other flight-related information.

These demonstrations unequivocally proved that the "Android" attack could effectively turn unsuspecting Bluetooth devices into highly accurate, real-time tracking beacons, leveraging Apple's global Find My network infrastructure, and doing so without requiring root privileges on the target device.

Defensive Implications

▶ Watch: Discovering unexpected behavior on other platforms (7:39)

The discovery of the "Android" vulnerability carries significant defensive implications for users, operating system vendors, and device manufacturers. The good news is that Apple has acknowledged the research findings and has released corresponding patches to address this vulnerability within the Find My network protocol. This indicates that newer versions of Apple's software and devices are designed to correctly filter out or reject advertisements from public Bluetooth addresses that are not legitimate Find My beacons.

However, the speaker correctly speculated that this vulnerability will take years to eventually fade out from the ecosystem. This "long tail" effect is common in security. Many users do not consistently upgrade their operating systems or device firmware immediately, if ever. Older devices, unsupported platforms, or systems where updates are manually managed will remain vulnerable for an extended period. This means that even with Apple's patches, the threat persists for a substantial portion of the global device landscape.

For users, the primary defensive action is to update their systems and applications regularly. Keeping operating systems (Linux, Android, Windows) and Bluetooth drivers up-to-date is crucial. While Apple has patched its backend, the vulnerability also stems from how various OS Bluetooth stacks handle advertisements (e.g., BlueZ allowing unprivileged public address advertisements). Therefore, OS-level patches are also important. Users should be aware that any Bluetooth-enabled device they own could potentially be leveraged for tracking if it falls into the category of vulnerable, unpatched systems.

For operating system vendors (Linux distribution maintainers, Google for Android, Microsoft for Windows), the research highlights the need for stricter control over how unprivileged applications interact with the Bluetooth stack, particularly concerning advertisement addresses. Allowing unprivileged applications to broadcast with public addresses, especially without clear user consent or system-level restrictions, creates a significant privacy loophole. Future Bluetooth stack implementations should enforce the use of randomized or private addresses for unprivileged advertising by default, aligning with privacy-by-design principles.

For Bluetooth device manufacturers, this research underscores the importance of adhering strictly to Bluetooth specifications for address types and ensuring that device firmware does not inadvertently enable such tracking. While the attack primarily targets the OS and the Find My network, understanding how device MAC addresses can be exploited for tracking via crowdsourced networks is vital for designing future privacy-preserving hardware.

In a broader sense, this research serves as a cautionary tale for all developers and architects of crowdsourced location systems. While end-to-end encryption is a vital component of privacy, it alone is not sufficient if the underlying mechanisms for identifying and reporting devices can be subverted. Robust validation of advertisement formats and stricter controls over the types of addresses accepted into the network are essential to prevent similar exploits in the future.

Key Takeaways

• Apple Find My Network Vulnerability: The research revealed a critical flaw in Apple's Find My network, allowing non-Apple Bluetooth devices to be tracked globally without root privileges.
• Public Address Exploitation: Contrary to design, Apple's Find My network accepts advertisements from devices using permanent public Bluetooth MAC addresses, which can be manipulated to embed cryptographic keys.
• OS-Specific Attack Vectors: Linux systems using BlueZ allow unprivileged applications to broadcast with public addresses, while Android/Windows require a "mutual VE address" workaround where devices infer each other's MAC addresses.
• Affordable and Scalable Tracking: The attack is highly cost-effective, with a 90% probability of finding a matching key for tracking within 2.76 minutes for just $2.20 using rented cloud GPUs.
• Real-World Efficacy: The tracking system demonstrated practical real-world performance, with average latencies under 8 minutes and accuracy within 10 feet (ground) or 200 feet (airborne).
• Persistent Threat Despite Patches: While Apple has released patches, the vulnerability will persist for years due to slow user adoption of updates across the vast ecosystem of Bluetooth-enabled devices.

About the Speaker(s)

Junming Chen presented this research, which was conducted with his team. As the lead presenter, he introduced the work as their "latest research finding," indicating his role as a key researcher involved in uncovering and detailing the "Android" attack on Apple's Find My network.