Following the recent release of Apple's AirTags technology, I wondered if the "Find My" offline search system could be abused to upload arbitrary data to the Internet from devices not connected to WiFi or mobile Internet. This data could be broadcast over Bluetooth Low Energy and picked up by nearby Apple devices. These devices, as soon as they connect to the Internet, would immediately forward this data to Apple's servers, from where it can later be retrieved. Such a technique could be used by small sensors in uncontrolled environments, so as not to waste extra energy using the mobile Internet. In addition, it could be interesting for stealing data from places protected by a Faraday cage, if a person with an iPhone just looked there.
Theoretically, this should be possible: if you manage to emulate two AirTags, then you can encode the data by activating only one of them at a given time. In this case, the receiving device must check which AirTag was active at what time, and decode the data back to its original form. However, such a scheme seems to be extremely unreliable and, perhaps, unsuitable for use in real practical situations due to the very narrow data transmission bandwidth (especially taking into account the limitation of 16 AirTag on Apple ID , it seemed that the amount of data transferred could not exceed several bits per hour).
Therefore, the feasibility of this idea depends on how the system is designed and implemented. It turns out that the decisions to ensure security and privacy made when designing the offline mechanism show that the case we proposed is very effective as a method of penetration, and it is almost impossible to defend against it.
Result: Extract previously transferred / downloaded data using a dedicated Mac app
- You can download arbitrary data from devices not connected to the Internet by broadcasting Find My messages via BLE (Bluetooth Low Energy) technology to nearby Apple devices, which then download the data for you
- ESP32, ( ) macOS, , : https://github.com/positive-security/send-my
- , - Find My, ,
Find My modem (ESP32) // Find My modem (ESP32)
Nearby Apple Devices // Nearby Apple
Mobile Tower or Wifi Access Point // Cell Tower or Wifi Access Point
macOS device with data retrieval app // macOS device with app to retrieve data
Data flow // data flow
.
Description of the offline search network
Fortunately, this protocol has already been largely reversed-engineered by a group of researchers from Darmstadt University of Technology, who published the article “Who Can Find My Devices? “In March 2021 and for proof of concept released the open source implementation of OpenHaystack . With this implementation, you can create your own components that are tracked on the Apple Find My network. Many thanks to this team! It was through their work that ours was able to take place, and both our firmware (also done for proof-of-concept) and the Mac app are based on OpenHaystack.
In a slightly simplified form, the principle of operation of the offline Find My search system is as follows:
- AirTag Apple, , , AirTag ( )
- 2 AirTag Bluetooth, , ( 15 )
- , , .., Find My, , ( ECIES)
- When searching for devices, the paired Owner's Device generates a list of replaceable public keys that AirTag must have used in recent days, and asks Apple for their SHA256 hashes. The Apple backend returns encrypted location reports for those keys whose IDs were requested.
- The owner's device decodes the location reports and outputs the approximate location.
Apple's servers // Apple servers
Finder devices // Searching devices
Owner device // Owner device
Lost device // Lost device
- // Pairing at initial setup
- // Broadcast. Bluetooth public key presentation
- // Download encrypted location reports
- // Download and decrypt location reports
Fig. 1. Simplified flow diagram of tasks solved when offline finding devices
This very beautiful design has characteristic security properties, in particular:
- Tracking protection against nearby attackers with removable public keys
- Inability to determine the location of Apple users
However, for us in this case, the most interesting is this: Apple does not know which public keys belong to your AirTag, and, accordingly, which location reports are addressed to you. Thus, an endpoint requesting location reports for a specific key id does not perform any authorization (but you must authenticate with your Apple ID to access the endpoint).
All security is ensured at the level of encryption of location reports: the location can only be decrypted with the correct private key, and it is stored only on the paired Owner's Device, and it is impossible to pick it up with a simple brute force attack.
Designing a data theft protocol
This suggests that the only medium we can use to encrypt data is the broadcast EC public key (eg, we cannot influence the GPS coordinates, since the "lookup" device adds them).
In the next section, we will consider the Apple backend as a shared storage of public key values, where the SHA256 hash is used as the key, and the encrypted location report is used as the value, moreover, the main operations are as follows:
- You can check if location reports exist for a specific hash whether SHA256
- You can add location reports to a specific SHA256 hash by broadcasting the corresponding public key
I think you already understand the course of events: you can set arbitrary bits in the shared key and value store and query them again. If both the sender and the receiver agree on such an encryption scheme, then arbitrary data can be transmitted using it.
I decided to build a modem that accepts a message over a serial interface and then loops through that data until a new message is received. To ensure that we can distinguish a "0" bit from an unset bit, we will broadcast different public keys depending on the bit value, and will query the receiver for both possible public keys.
There is no guarantee as to when (or if any) specific broadcast messages will be uploaded to Apple's backend as location reports. The point is that some packets may not reach any Apple device, and searching devices may have highly variable delays between receiving a broadcast message and downloading a location report, which may be dependent on upstream connectivity or power mode. Thus, our data encoding should not depend on which location reports arrive and in what order, and also allow the recovery of partially received data streams - those in which some bits are completely lost. To achieve this, I decided to encrypt one bit of data per broadcast, along with an index value indicating,which message bit is set. Thanks to the additional message and modem ID, the system is suitable for multiple use by multiple users, handling multiple messages.
So, by sending a specific bit, we create a 28-byte array like "[4b bit index] [4b message ID] [4b modem ID] [zeros padding ...] [bit value]", operate it as a public key and send representations BLE, for example, for broadcasting information "bit 0 of message 0 is 1".
To send a complete message, the program simply iterates over all its bits and sends a representation to a bit with a public key, in which the index and value of this bit are encrypted.
Message to encode // Message to encode
Generated public key to broadcast // Generated public key for broadcast
Bit index // Bit index
Bit value // Bit value
Encode message bits into broadcast payload
When fetching data, the receiving application will generate the same 28-byte arrays (two per bit, where the possible bit values are 0 and 1) and request an Apple service with SHA256 hashes of these "public keys". Only one of these keys should have location reports attached, which can then be interpreted (eg, bit with index 0 is 1).
Potential bits to query // Bits that can potentially be queried
Potential public keys to test // Public keys that can potentially be tested
Query Apple Backend // Query the Apple
Decode backend public key existence back to original data // Decrypt the public key by getting raw data
Retrieves previously sent data from a macOS device connected to the Internet
Note: you can send not only one bit per message, but, for example, send a whole byte, which will contain the last 8 bits of the public key. While this requires a wider data transmission bandwidth, the receiver will now have to request 255 different key IDs to select / brute force one byte (compare with 16 key IDs when bitwise encoding).
Implementation
Sender side
On the sender side, I decided to use ESP32 - a completely ordinary and cheap microcontroller (and a quick test showed that it can change the BT MAC address much faster than, say, a Linux-based Raspberry Pi). On boot, the firmware based on OpenHaystack broadcasts a hardcoded default message and then listens to the serial interface (as a loop) to see if any new broadcast data arrives - and so on until a new message is received ... When broadcasting a public key, it needs to be split up and encoded in the first 6 bytes in the Bluetooth MAC address (all but the first two bits, since the Bluetooth standard requires the first two bits to be set to 1). We refer you to See section 6.2 of the Darmstadt University of Technology article , where this homemade encoding is described in more detail.
I added a static prefix to my payload so I wouldn't run into problems with the BT spec, and I also included an incremental bit index in the first 6 bytes of the public key, resulting in each bit being transmitted has its own BT MAC address, just in case if there is a MAC address based rate limiting anywhere in the stack.
ESP32 modem output in serial console a
Data extraction side
The Mac app is also based on OpenHaystack and uses the same trick with the AppleMail plugin to send properly authenticated location fetch requests to the Apple backend. The user is prompted to enter a 4-byte modem ID (can be set during the ESP firmware), after which the application will automatically select, decode and display a message with id 0. Then the user can select other messages or change the modem.
The message is fetched 16 bytes (128 bits) at a time (256 key ids are requested) until there are no reports left (for a whole byte).
Minor complication: public key expiration
After implementing both the sender and receiver sides, I ran the first test by broadcasting and trying to get a 32-bit value. After a couple of minutes, I was able to get 23 out of 32 bits, each one is definitely correct and with about 100 location reports, but I did not get any such report for the remaining 9 bits.
Suspected that some of the generated public keys were rejected by nearby Apple devices during the ECIES encryption phase as invalid public keys - and this was quickly confirmed by attempting to load each of the generated payloads as SEC-1 encoded public keys on a P224 curve using Python fastecdsa package: for every bit for which I had no location reports, the microcontroller broadcasted the public key, throwing an InvalidSEC1PublicKey exception when importing the fastecdsa key.
A little context of the encryption used here:
- The 28-byte EC public represents the X coordinate of a particular point, encoded with SEC1.
- The SEC1 public key usually also has a "sign" bit, which determines which of the two possible Y coordinates for a given X coordinate should be encoded. This bit is not transmitted during broadcast and is not important for the public key expiration date.
- When decoding the compressed public key, the corresponding Y coordinate is computed using the fixed curve parameters and verified if the key is valid. Some of the generated public keys fail this test. For more details see section 3.2.2 in the article " Validation of public keys on elliptic curves ":
This problem with invalid public keys can be solved in at least two ways:
The advantage of the second option is that for each bit received, we could also decrypt the location reports to determine at what point a given bit was received, but this requires a little more computational processing. While implementing this option, I found that due to bugs in the implementation of elliptic curve multiplication in the uECC library used for this, for some private keys ESP calculated different public keys than BoringSSL on Mac and fastecdsa on Python (differential fuzzing accidentally crept in?). These public keys were even considered invalid by uECC's own uECC_valid_public_key () function. Therefore, in this pilot project, I settled on option 1.
Message to encode // Encoded message
Generate public key to encode // Generate a public key to encode
BT MAC address // BT MAC address
Test validity, else increment counter // Check if the key is valid, if not, increase the counter by one
Advertisement payload // Payload for the presentation
Encoding and sending the message
Testing / Performance
When we have implemented a public key validation check, everything works flawlessly. I haven't done extensive performance testing or gone into measurements, but here are some estimates:
- ~3 . ,
- - Mac. 16 ~5
- 1 60 , , , . . , , , , ( , Apple)
CDF // Cumulative distribution function
Median… min // Median… 26.3 min.
Publication delay (min) // Delay before publication (min.)
Fig. 8. Delays in the receipt of all reports, considered in § 7.1 as a cumulative distribution function.
Delays in the receipt of reports, measured by a team from Darmstadt University of Technology, based on the materials "Who can Find My Devices?"
Potential Uses
While I was mainly interested in checking the feasibility of what I described, I think the potentially most common practical application is downloading sensor readings or any data from IoT devices without a broadband modem, SIM card, data plan or Wifi connectivity. Considering Amazon uses a similar network called Sidewalk using Echo devices, there may well be a demand for such technologies. Since the cache of searchers accumulates received broadcasts, remaining there until an Internet connection is established, sensors can send data even from areas where there is no mobile network coverage, if people with devices walk in such places.
In a world of high-security networks , where technology that combines lasers and scanners seems to be a promising trick to close the air gap, the Apple devices that visitors bring in can also act as a viable intermediary for stealing data from air-gap systems.or rooms protected by a Faraday cage.
It also appears that the offline discovery protocol could be used to drain traffic on nearby iPhones connected to non-unlimited tariffs . By limiting the number of location reports that can be sent from a single seeker (255 reports / submissions because the count byte is 1), and with each report exceeding 100 bytes, broadcasting multiple unique public keys can lead to a significant increase. traffic outgoing from the smartphone. Although I did not notice any frequency limitation for outgoing location reports, I also did not test how much data could be consumed.
How to iron out the problem
As I mentioned at the very beginning, it will be difficult for Apple to defend against this kind of abuse if they choose to do so.
Apple designed the system with data economy in mind. They cannot read unencrypted locations and do not know which public keys belong to your AirTag, or even which public key a particular encrypted location report is associated with (since they only receive the SHA256 hash of the public key).
In this light, the stated limit of 16 AirTags on Apple ID is interesting, since it seems to me that at the moment Apple has no power to oblige to use it.
However, further tightening of this system is possible, for example, in the following two areas:
- BLE. , , AirTag OpenHaystack, AirTag . , , , BLE , , AirTag , , .
- Apple , id id AirTag, id , 15 16 id Apple ID ( id ). , , : Apple ID .
In this article, we answered the question of whether it is possible to download arbitrary data using devices with Apple owned by other users: definitely yes.
The firmware of the ESP32 modem and an application for extracting data for macOS are implemented, they are posted on Github , you can experiment with them.
Note that this implementation is just a "proof of feasibility" and the "protocol" itself is neither encrypted nor authenticated. For example, you can examine the details of a modem with ID 0x42424242 by simply entering its ID (maybe in the meantime someone can also demonstrate that there is no authentication in this protocol).
One final note: While preparing this post, I noticed that the "status byte" included in the BLE view is obviously being used, for example, as a battery level indicator. Combined with the deterministically generated private keys that are rotated, this probably opens up another data leakage hole (per byte per view), but I haven't tested this approach.
Cloud servers from Macleod are fast and secure.
Register using the link above or by clicking on the banner and get a 10% discount for the first month of renting a server of any configuration!
