CVE-2024-23963: Apple Find My Vulnerability Exposes Real-Time User Locations

Key Takeaways

• A security researcher successfully reverse-engineered Apple’s private Find My People protocol.
• The researcher demonstrated that a Linux machine could access and decrypt live location data shared via Apple’s Find My app.
• This process was achieved without requiring a Mac or iPhone, by simulating an Apple device.
• The project did not expose a new vulnerability in Apple’s systems but detailed the previously undocumented workings of the Find My protocol.

A cybersecurity researcher has successfully deconstructed Apple’s proprietary Find My People protocol, showcasing the ability of a Linux system to register with Apple’s internal services. This groundbreaking work allowed the researcher to acquire an existing location-sharing key and subsequently decrypt a friend’s real-time location data, all without the need for an Apple device like a Mac or iPhone.

The initiative began with a seemingly straightforward goal: to integrate geofence alerts for Discord using location data already shared by a friend through Apple’s Find My application. What initially appeared to be a simple authenticated API interaction quickly evolved into an intensive week-long effort to reverse-engineer Apple’s intricate private device-identity and messaging infrastructure, as no prior open-source project had fully replicated this complex workflow.

Through careful analysis of decompiled Apple daemons, specifically fmfd, findmylocated, and searchpartyd, alongside leveraging existing open-source tools such as FindMy.py and pypush, the researcher meticulously reconstructed the entire data pipeline, field by field.

Faking an Apple Device From Scratch

Overcoming Authentication Hurdles

The initial challenge centered on authentication. Standard iCloud login tokens proved ineffective, returning 401 errors when used against the legacy Find My Friends API. This issue arose because each Apple service employs its own set of scoped credentials, which are issued through a specialized broker exchange.

Following successful authentication via GrandSlam, Apple’s proprietary account login protocol, the researcher managed to obtain a delegate token for IDS. IDS functions as Apple’s private identity and encrypted-messaging layer, forming the backbone for services like iMessage and Find My.

Transforming this token into a functional device identity demanded a certificate signing request with highly specific and previously undocumented parameters. These included a 2048-bit RSA key, a SHA-1 signature, and a common name derived from the SHA-1 hash of the account’s profile ID, all encapsulated within a gzip-compressed XML property list.

Registering as a Find My device presented its own unique set of requirements. It necessitated enrollment under Apple’s “alloy” multiplexer service, specifically involving six distinct sub-services, rather than a direct registration with Find My Friends.

Acquiring and Decrypting Location Keys

The most intricate conceptual hurdle involved persuading Apple to transmit the encryption key for an already-accepted location share to the newly emulated Linux “device.”

According to a Zerotistic researcher, a SubscribeAndFetch request, configured with an intent of distributeKeys, prompts the original sharing device to redistribute its current key. This key is transmitted via the Apple Push Notification Service, enveloped within a cryptographically signed and ECDH-verified package known as pair-ec.

Crucially, this entire process did not require any resharing of location data or modifications to the account settings. This is because Apple’s underlying architecture is designed to automatically provision existing keys to newly authorized devices.

The delivered key was identified as utilizing elliptic-curve cryptography on the P-224 curve, which is distinct from the P-256 keys employed within the messaging envelope itself.

With the specific per-share key successfully obtained, the researcher then queried Apple’s SearchParty service, where encrypted location reports are stored. The ciphertext was subsequently decrypted locally using an ECDH key exchange and AES-GCM. The outcome was a live, verified set of coordinates, an accuracy radius, and a timestamp for the consenting friend’s device, all acquired exclusively through Linux-based tools.

This comprehensive exercise did not uncover a new security flaw that would necessitate a patch from Apple, as it merely accessed location data that had already been voluntarily shared with the researcher’s account. Its primary significance lies in being the first detailed documentation of how Apple’s private IDS and SearchParty protocols manage the distribution and rotation of location-sharing keys. This information is invaluable for researchers aiming to develop interoperable or self-hosted Find My clients.

What You Should Do

• Review your Find My sharing settings regularly to ensure you are only sharing your location with trusted individuals.
• Understand that while this research did not expose a new vulnerability, it highlights the technical complexity of Apple’s location-sharing mechanisms.
• Be mindful of who you grant location access to, as the underlying architecture is designed for seamless key distribution to authorized devices.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.