Whispering Under the Eaves: Protecting User Privacy Against Commercial and LLM-powered Automatic Speech Recognition Systems

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

Speakers: Junming Chen, Xiaoyue Ma, Lannan Luo, Qiang Zeng, Researchers, George Mason University

Conference: USENIX Security

YouTube: https://www.usenix.org/conference/usenixsecurity25/presentation/chen-junming

Overview

This groundbreaking research introduces nRootTag, a novel attack method that weaponizes Apple's ubiquitous Find My network to maliciously track Bluetooth-enabled devices, transforming them into de facto AirTags without requiring root privileges. Presented by researchers from George Mason University, this work exposes a critical vulnerability in the Find My implementation, demonstrating how ordinary computers and IoT devices running Linux, Windows, or Android can be co-opted for highly effective and stealthy location tracking. The implications for user privacy and security are substantial, given the global reach of Apple's Find My network, which encompasses over a billion active Apple devices acting as passive location reporters.

The significance of nRootTag lies in its broad applicability and low barrier to entry. Unlike previous methods that required elevated system privileges or specific hardware, nRootTag operates without root privileges, making it feasible for a wider range of adversaries, from malicious app developers to intelligence agencies. The attack boasts an impressive success rate of over 90% within minutes, at a computational cost as low as a few US dollars, especially when leveraging cloud-based GPU resources. This blend of effectiveness, efficiency, and stealth makes nRootTag a potent new threat in the landscape of digital surveillance, capable of tracking desktops, laptops, smartphones, and various IoT devices with alarming precision.

Background

Apple's Find My network is designed to help users locate their lost Apple devices and AirTags by leveraging the immense installed base of iPhones, iPads, and Macs. The core mechanism involves a Bluetooth tracker (e.g., an AirTag) periodically broadcasting Bluetooth Low Energy (BLE) advertisement messages, often referred to as "lost messages." Nearby Apple devices, acting as "finders," receive these messages, encrypt the current location (obtained via GPS) using the tracker's public key, and then upload these encrypted location reports along with a hashed public key to the Apple Cloud. The owner can then query the Apple Cloud using their private key to decrypt and view the tracker's location. A crucial aspect of the Find My protocol, confirmed by prior research like OpenHayStack, is that finder devices do not authenticate whether a lost message originates from an official Apple device or if the device is registered with Apple Cloud, ensuring anonymity for legitimate AirTags but also opening avenues for misuse.

The BLE protocol defines two primary categories of advertising addresses: Public Addresses and Random Addresses (Section 2.1). A Public Address is a permanent, globally unique identifier comprising a 24-bit Organizationally Unique Identifier (OUI) assigned by the IEEE and a 24-bit manufacturer-specific part. These are typically used by Linux systems. Random Addresses, conversely, are designed for enhanced privacy, changing periodically. They are further categorized into Non-Resolvable Private Addresses (NRPA), Resolvable Private Addresses (RPA), and Random Static Addresses. Windows commonly uses NRPAs, while Android typically uses RPAs. The Find My specification mandates that lost messages should be advertised using a random static address, with specific bits of the public key embedded within the advertising address itself to overcome the 31-byte BLE advertisement payload limit (Section 2.3). Specifically, the least significant 46 bits of the advertising address must match the least significant 46 bits of the first six bytes of the public key.

Prior attempts to exploit the Find My network, such as OpenHayStack, demonstrated that devices like the ESP32 could be turned into trackers. However, these methods typically required root privileges to modify the BLE advertising address to align with a generated public key. Obtaining root privileges is often a non-trivial and detectable step in an attack chain, severely limiting the applicability of such methods. Other location tracking techniques, such as IP-based geolocation or MAC-address-based tracking, suffer from significant accuracy limitations, dynamic IP assignments, Network Address Translation (NAT), VPN usage, and the widespread adoption of MAC address randomization. In contrast, nRootTag's approach leverages the vast and precise Find My network, bypassing these traditional limitations and the need for additional infrastructure (Section 3).

Key Findings

The research behind nRootTag uncovers several critical findings that underpin its effectiveness:

• Undocumented Find My Vulnerability: The most significant discovery is that Apple's Find My network implementation accepts all types of BLE advertising addresses (Public, NRPA, RPA, and Random Static) for lost messages, despite the official specification mandating only random static addresses (Section 3, 4.1, 9). This crucial oversight, overlooked by both Apple and prior research, is the fundamental enabler for nRootTag's non-root operation across diverse operating systems.
• nRootTag: Non-Root Tracking: nRootTag is the first demonstrated attack method that transforms a computer into an "AirTag" tracker without requiring root privilege escalation. Instead of modifying the advertising address, it searches for a public/private key pair that matches the target device's existing advertising address (Section 1).
• Broad Platform and Device Compatibility: The attack is highly versatile, proven effective on Linux, Windows, and Android systems, encompassing a wide array of devices including desktops, laptops, smartphones, and various IoT devices such as the Steam Deck, Raspberry Pi, Sony smart TV (Bravia A80J), and Meta VR headset (Quest 2) (Section 1, 6.4, Tables 5 & 6).
• High Efficiency and Low Cost: nRootTag achieves a success rate of over 90% within minutes. For Attack-II (targeting Windows/Android with changing addresses), an online key search to achieve 90% success takes approximately 2.76 minutes (billed as 3 minutes) and costs merely 2.20 USD using 200 rented RTX 3080 GPUs (Section 1, 5.4.2, 6.2.2). Crucially, the cost of this online key search does not increase with the number of tracked computers, making it highly scalable.
• Stealth and Evasion Capabilities: While portable devices (e.g., laptops) continuously advertising lost messages might trigger Apple's unwanted tracking alerts, nRootTag incorporates evasion techniques. By setting the Status field of the lost message to 0x00 (mimicking a MacBook, which Apple deems "irrelevant" for tracking alerts), the attack can successfully prevent alerts on the latest iOS versions (Section 7.2). Stationary devices inherently do not trigger such alerts.
• Programmatic Bluetooth Control: On Linux systems, the research discovered a specific rule file (61-gnome-settings-daemon-rfkill.rules) that allows non-root users to write to /dev/rfkill, enabling programmatic control over Bluetooth adapters without requiring user interaction or root privileges on most tested distributions (Section 5.1, Table 5).

Technical Deep Dive

The technical ingenuity of nRootTag lies in its ability to circumvent the need for root privileges by leveraging an implementation flaw in Apple's Find My network. Instead of forcing a device's BLE advertising address to match a pre-generated public key (which requires root), nRootTag reverses the process: it finds a public/private key pair whose public key already matches the target device's existing advertising address. This matching criteria is specific: the least significant 46 bits of the BLE advertising address must correspond to the least significant 46 bits of the first six bytes of the public key (Figure 2, Section 1).

The attack employs two distinct approaches, tailored to different operating systems based on how they handle BLE advertising addresses:

1. Attack-I (Linux Systems): This approach targets Linux systems, which typically use a Public Address for BLE advertising. Public addresses are constant and, critically, accessible without root privileges. They incorporate a 24-bit OUI assigned by the IEEE. nRootTag precomputes rainbow tables that store public/private key pairs for various OUIs. When a Trojan on a Linux machine retrieves its public address, the server can instantly retrieve the matching key pair from the rainbow table (Section 4.2).
2. Attack-II (Android and Windows Systems): These systems predominantly use periodically changing Random Resolvable Private Addresses (RPAs) (Android) or Non-Resolvable Private Addresses (NRPAs) (Windows). These addresses cannot be directly accessed by non-root programs. To overcome this, nRootTag employs an ingenious sniffing mechanism: if a popular app (containing the Trojan) is installed on multiple nearby devices, one Trojan instance (Trojan B) can sniff the advertising address of another target Trojan instance (Trojan A) (Section 4.2, 5.2). Trojan A periodically broadcasts an "address-query" message containing its unique ID and a sequence number. Trojan B, upon sniffing this, extracts A's advertising address and sends an "address-response" message back, containing A's ID, address, and the sequence number. This allows the server to obtain the target's current advertising address without root access on the target device itself. The range of BLE 5.0 (up to 400m) is sufficient for this inter-Trojan communication (Section 4).

The overall architecture of nRootTag comprises four main components (Figure 4, Section 4.3):

• Trojan: Deployed on the target computer, it retrieves the advertising address, queries the Server for a matching public key, and then advertises Find My lost messages.
• Server: Receives key requests, performs key searches (rainbow table lookup or online GPU search), queries the Apple Cloud for location reports using the SHA256 hash of the public key, and decrypts them using the private key.
• Database: Stores the precomputed rainbow tables.
• Key Generation and Search Module: Responsible for building rainbow tables offline or performing real-time key searches, heavily leveraging GPU acceleration.

A custom database system is designed for efficient storage of the rainbow tables (Section 5.3, Figure 5). Key optimizations include:

• Public Key Elimination: The public key can be derived from the private key (using the secp224r1 curve utilized by Find My), so only the 28-byte private key needs to be stored, saving space.
• OUI-based Organization (Attack-I): For Linux's public addresses, records for each OUI are stored in separate files (named after the OUI). The remaining 24 manufacturer-specific bits of the address serve as an implicit index into an array within that file, reducing each record to just 28 bytes (the private key). The rainbow table for Attack-I requires approximately 20.10 TB of storage for 47,054 OUIs, which is affordable (e.g., a 24 TB hard drive for 479.99 USD) (Section 5.3, 6.2.1).
• Attack-II Storage: For Attack-II, the rainbow table is indexed by the 46 critical bits of the address, requiring 2^46 records, totaling approximately 1.75 PB of storage. This is prohibitively expensive for individual attackers (estimated 65,601.85 USD initial setup for on-premises storage) (Section 5.3, 6.2.2).

Key Generation and Search:

The process of finding a matching public/private key pair is modeled as a coupon collector's problem. For Attack-I, the effective search space N is 2^48. For Attack-II, it's 2^46 (due to only 46 bits being critical for matching). The researchers implemented a highly optimized key generation module utilizing multiple GPUs. Using 200 RTX 3080 GPUs, building the rainbow table for Attack-I takes approximately 2.70 hours at a cost of 118.80 USD. For Attack-II, it takes a mere 0.65 hours at 28.60 USD (Section 5.4.1, 6.2.1, 6.2.2).

For Attack-II, given the immense storage cost of a full rainbow table, online key search is presented as a more cost-effective alternative for short-term or intermittent tracking. This involves continuously generating key pairs until one matches the target's current advertising address. With 200 RTX 3080 GPUs, achieving a 90% success probability for a match takes 2.76 minutes and costs 2.20 USD. A key insight is that the cost remains constant regardless of the number of tracked computers, as the generated keys can be simultaneously checked against a hash table of all target addresses (Section 5.4.2, 6.2.2, Figure 8). The RTX 3080 GPU was selected as optimal due to its low rent-to-KPS (Keys per Second) ratio of 0.045 (Table 2).

Demo / Proof of Concept

The efficacy and broad applicability of nRootTag were rigorously demonstrated through comprehensive evaluations across various scenarios and devices.

Location Tracking Accuracy and Latency:

• Stationary Tracking: A desktop computer running the Trojan in an office environment yielded an average first location report latency of 6.75 minutes (90th percentile at 10.34 minutes). In a residential environment, the average latency was slightly longer at 8.09 minutes (90th percentile at 15.92 minutes). Location estimation using DBSCAN with ball tree clustering provided highly accurate results, with estimated Finder locations within 3 meters of the ground truth (Section 6.3.1, 6.3.2, Figure 9a).
• Riding Scenario: A Raspberry Pi carried on an e-bike (approx. 15 km/h) over a 57-minute ride collected a small number of location reports. Seven out of nine reports aligned with the actual track, while two showed deviations of 45.88 m and 58.92 m (Section 6.3.2).
• Flight Scenario: A Steam Deck on a 91-minute flight (average 863 km/h) yielded 17 location reports. The average distance between reported locations and ground truth was 70.03 meters. The reported locations allowed for the reconstruction of the flight path, and with external data like Flight Radar 24, the flight number could be deduced (Section 6.3.2, Figure 10). The Confidence attribute in location reports was observed to correlate with deviation, with levels 2 and 3 showing low deviation, and level 1 reports (high deviation) being excluded from analysis (Table 4).

Platform and Device Validation:

• Attack-I (Linux): The attack was successfully validated on 12 different Linux distributions, including popular desktop environments like Ubuntu, Fedora, and Debian, as well as IoT platforms like SteamOS (on Steam Deck) and Raspberry Pi OS. Even on distributions where Bluetooth was initially disabled, nRootTag could programmatically enable it without alerts, demonstrating the stealthy nature of the operation (Section 6.4, Table 5).
• Attack-II (Android/Windows): This approach was successfully demonstrated on seven Android phones (versions 11-14), a Sony smart TV (Bravia A80J), a Meta VR headset (Quest 2), a Dell laptop (Windows 11), and a Gigabyte desktop (Windows 11). For Android and Windows, a nearby Raspberry Pi running the Trojan (placed 20 meters away in a different room) was used to sniff advertising addresses, confirming the practicality of the multi-Trojan address retrieval method. The study noted that smart TVs and VR headsets often prevent users from disabling Bluetooth, further aiding the attack (Section 6.4, Table 6).

Evasion of Unwanted Tracking Alerts:

The researchers confirmed that Apple's unwanted tracking detection, designed to alert users about rogue AirTags, can be circumvented. By setting the Status field in the lost message to 0x00, nRootTag can mimic advertisements from a MacBook. Apple's system typically filters out such messages from triggering alerts, deeming them "irrelevant" for tracking purposes. This evasion technique was validated on the latest iOS versions, effectively preventing alerts for portable devices (Section 7.2).

Defensive Implications

The nRootTag attack highlights a significant vulnerability in Apple's Find My network, posing considerable challenges for mitigation. The primary defensive measure for Apple would be to enforce its own specification:

• Strict Enforcement of BLE Address Types: Apple could patch its finder devices (i.e., iPhones, iPads, Macs, Apple Watches) to only process Find My lost messages that originate from random static addresses, as mandated by the protocol specification (Section 7). This would directly nullify the core vulnerability exploited by nRootTag.
• Challenge: The sheer scale of the Find My network, comprising over a billion active devices, means that a complete and widespread patch deployment would take a considerable amount of time. During this transition period, the vulnerability would remain exploitable on unpatched devices.
• Residual Risk: Even with widespread patching, if an attacker could identify and target devices that legitimately use random static addresses for advertising (e.g., certain smart home or health devices), nRootTag could still be adapted to exploit these, leveraging the same vast network for tracking (Section 7). Further research is needed to assess this broader implication.

Beyond Apple's direct mitigation, several other defensive strategies are crucial:

• Enhanced Software Supply Chain Security: nRootTag's deployment hinges on infecting a target device with a Trojan. Robust defenses against malicious apps, phishing campaigns, drive-by downloads, and software supply chain attacks are paramount. Organizations and individuals must exercise extreme caution regarding software installations and updates.
• User Permission Awareness: On Android 13 and later, explicit user permission is required for an app to enable Bluetooth if it's disabled. Users should be more discerning about granting Bluetooth permissions to applications, especially those that don't have a clear functional need for it, as Bluetooth permissions are often perceived as less sensitive than GPS location permissions (Section 4.4, 6.4).
• Network and Device Monitoring: Security teams could monitor for unusual BLE advertising patterns from devices within their networks, specifically looking for devices broadcasting Find My lost messages when they are not legitimate Apple trackers.
• macOS Specifics: While the paper notes that Apple has mitigated the specific Internal Blue technique used for macOS tracking in subsequent versions, the general principle of indirect tracking via nearby Android/Linux/Windows devices remains a concern for Apple devices as well (Section 7).

Key Takeaways

• Apple's Find My network possesses a critical implementation vulnerability that allows the use of non-standard BLE advertising addresses (Public, NRPA, RPA), enabling unauthorized tracking.
• nRootTag is the first attack of its kind to transform common Bluetooth-enabled devices (Linux, Windows, Android desktops, laptops, smartphones, IoT) into Find My trackers without requiring root privileges.
• The attack is highly efficient, boasting a >90% success rate within minutes, and cost-effective, with online key search costing as little as 2.20 USD for a 90% success probability for Attack-II.
• The cost of online key search does not increase with the number of tracked devices, making the attack highly scalable for adversaries.
• Stationary devices are inherently stealthy, and portable devices can evade Apple's unwanted tracking alerts by mimicking MacBook advertisement types (Status field 0x00).
• Mitigation primarily requires Apple to enforce its own Find My specification on its billion-plus finder devices, a challenging and time-consuming deployment effort.

About the Speaker(s)

The research behind nRootTag was conducted by Junming Chen, Xiaoyue Ma, Lannan Luo, and Qiang Zeng, all affiliated with George Mason University. Their work represents a significant contribution to the field of system security, particularly concerning mobile platforms and the privacy implications of widely adopted wireless technologies like Bluetooth. This paper was recognized with a Distinguished Artifact Award at the USENIX Security conference, highlighting the quality and impact of their technical contributions.