Apple devices listen for BLE advertisements of a certain form to indicate a "Find My" network lost device.
The lost device advertisements mainly contain the public key part of a key pair.
The public key does not fit in the in payload of the advertisements, so it is stuffed into the address field. Edit: Only 46 bits of the full 224 bit public key is stored in the address field.
In general anyone can make a "lost device" advertisement as demonstrated by OpenHayStack[1]. The requirement is the address field needs to be fully controllable.
BLE advertisements have a header that indicates what kind of address is present (specified by 3 bits: Public, NRPA, RPA, Random Static). The lost device advertisements are supposed to be "Random Static", but the researchers found that Apple "Find My" listeners ("finders") will accept advertisements for any address type.
They use this fact to generate the private key part of a public key that matches an existing host adapter BLE address. The host adapter BLE address cannot generally be changed unless user has root/superuser privileges. This step is computationally expensive. However, private keys can be precomputed (rainbow tables) because a large chunk of the address is a manufacturer code (OUI).
Are you saying that a large chunk of the key (private key or public key?) is a manufacturer code? That's insane
They are not. They are generating a private/public key pair where the first 46 bits of the public key happen to match the victim's BLE address.
The find-my network then accepts beacons (encrypted with the attacker's private key) from this address, and stores it in iCloud to be retrieved by the attacker via the 46-bit prefix.
I don't see a way of fixing this without shutting off the current Airtag network.
> The lost device advertisements are supposed to be "Random Static", but the researchers found that Apple "Find My" listeners ("finders") will accept advertisements for any address type.
Expensive computed public key first 46 bits == Victim's BLE address
The Apple FindMy system doesn't (or didn't) validate that the public key being broadcast had ever been manufactured or registered. So anyone with an iCloud account could query the Apple FindMy hashtable for the last observed encrypted payload, which contains the observed location generated by the nearby phone.
If you have root on the victim's device, you don't need the expensive computation step. You just take a public/private keypair of your choice and reprogram the victim's Bluetooth hardware to broadcast that instead.
What is novel in this attack is that you can use non-root access. You observe the victim's fixed Bluetooth address, and then craft a FindMy beacon that happens to match. Since the FindMy beacon is basically just a public key that the receiver uses to encrypt location data, crafting the beacon is just finding a public/private key pair that matches the victim's Bluetooth address. Since broadcasting a beacon requires less rights (less than root), this is much more broadly exploitable (excluding the expensive precomputation step).
1. To demonstrate technical flaws, on a purely technical basis.
2. As political action in opposition to surveillance or inadequate security measures.
3. Interest in loose-knit collaborative systems with emergent effects that people can assemble together.
4. As a fun prank, not thinking enough about how it would affect other people.
5. The point being to hurt other people, and/or to feel power over them. (This is a thing, including by organized groups/clubs on the Internet, but I think it's a small minority, and doesn't apply to the commenter.)
Incidentally, when I started skimming that comment, I thought it might be about organizing a non-proprietary, open network, for the same benefits as Apple users get, which could be great.
That's generally my policy too, when I wrote the comment I felt confident that I wasn't missing a less mean-spirited interpretation that they may have meant instead, but it's possible my mood this evening clouded my judgement. If I was wrong, apologies to fsckboy
Then sometimes the thinking leads from there, maybe from a bad idea to a good idea, or maybe realizing a related thing in the world is also secretly bad, and can we address that.
Maybe see it as undermining via creating what you see as good, rather than as destroying what you see as bad?
> In addition, we appreciate the help from the Apple Security Team for their prompt responses and acknowledgement. Apple recently released patches in iOS 18.2, visionOS 2.2, iPadOS 17.7.3, 18.2, watchOS 11.2, tvOS 18.2, macOS Ventura 13.7.2, Sonoma 14.7.2, Sequoia 15.2 to fix the vulnerability. However, the attack remains effective as long as unpatched iPhones or Apple Watches are in the proximity of the computer running our trojan.
Seems like a pretty bad vulnerability to just hope 1.5B iPhones alone update soon enough. I know people still on iOS 17/16... All of them are now complicit.
But I'm happy to see my state represented in security research :)
It lets you turn someone else's device into an airtag, then track its location.
FTA's "Architecture of nRootTag":
> (1) The Trojan code runs on the computer to be tracked.
But there probably aren't many situations where someone has a network-enabled device turned on, disconnected from the network, but in range of at least one iPhone that has a network connection. Perhaps on a plane?
Nothing new, really. Apple created a worldwide network of location scanning devices and this is just leveraging the power Apple already has. The genie is out of the bottle now, and live location tracking has become almost trivial.
So, seeing how this is able to allow a device to be tracked without an alternative bluetooth stack: could the Find My network be (ab)used to geolocate devices without a GPS receiver? If a device broadcasts BLE packets and then queries its own location, that should give a pretty accurate location, shouldn't it? Might save some power if the 5G antenna is active already anyway, assuming there's an Apple user nearby.
This is hardly the problem that it's made out to be.
Excellent PR team - every other site reporting makes it sound like they broke FmF. but with a process on the device the device has already been pwnd.
They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app.
>Especially for apps that already have location permissions (something as simple as a weather app) this will hardly be noticed.
If the app already has location permissions, why would they need to pull off this attack? They get the user's location directly.
Looking at the apps I had to purge from family members' phones, I don't think that will be a problem.
> If the app already has location permissions, why would they need to pull off this attack? They get the user's location directly.
Accessing geolocation APIs will show an indicator and add an entry to a log (at least on Android). I don't believe accessing BLE APIs do the same.
As if people would care about that...
Also, 16777216 possibilities really aren't that many these days. With six cores at approximately 3.5GHz, assuming verification costs about 1000 instructions per key, brute-forcing every possibility will take between 4 and 5 seconds at most (half that on average). With appropriate rainbow tables, I think that should be feasible?
Using Core Bluetooth API it is trivial, but you need to either: a) create an app that does it and user has to download it b) modify SDKs existing in apps (e.g. Ad SDKs)
Also turning app/phone into a "BLE beacon" is only possible when app running in the foreground (on iOS).
Knowing the MAC makes the attack reasonable - let's say 5 hours compute for 3080Ti.
Not knowing the MAC makes it exponentially harder. You can still "guess" it, but the search-space is vast and that would take bazillion-years.
So to attack iOS device: - user has to download the app - app has to broadcast fake BLE - some other devices (e.g. Android/RasPi would need to pickup that MAC and pass it to you
- you need code execution on the victim device
- you need internet connectivity
- you need bluetooth permission
- if the victim device has GPS itself, then this attack is pointless because you may as well just use that directly.
Edit: It works without root. Follow up question: Can these discoveries improve openhaystack?
I guess all my Apple devices are looking for this and sharing it to Apple and wonder how much that data adds up.
And of course by requesting a result, you're letting Apple know that your Apple Account cares about a particular Airtag.
All the FindMy anonymity claims go out the window as soon as you actually lose something and want to find it. It's only anonymous if you don't query the network.
Good old days.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
The BLE broadcast stores part of the lost message public key in the advertising message's address, and part of it in the payload -- they are just using a "normal" BLE address and then reverse-engineering a key from that.
> The Find My network specification mandates the use of ran- dom static addresses for advertising lost messages. However, our research reveals that public addresses, resolvable private addresses, and non-resolvable private addresses can also serve this purpose without any issues. This implementation vulner- ability is exploited by our attack to track Linux, Android, and Windows systems.
> Our work uncovered a vulnerability in the Find My ser- vice that permitted all types of BLE addresses for advertis- ing. Exploiting this vulnerability, we proposed a novel at- tack, nRootTag, which transforms a Bluetooth device into an “AirTag” tracker without requiring root privilege escalation. By utilizing over a billion active Apple devices as finders, the attack is able to accurately track user devices. Through rainbow table-based offline key search or GPU-accelerated online key search, an infected computer can be quickly turned into a tracker. Notably, the online key search cost does not in- crease as the number of tracked devices grows. The evaluation shows that the attack is effective across various devices, in- cluding desktops, laptops, smartphones, and IoT devices, and worked on Linux, Windows, and Android platforms. We also discussed how the attack could be extended to track Apple devices.
It's really clever - the BLE spec limits message size, so Apple uses the BLE address as part of the message (the first part of the public key).
But since the public address of a BLE chip has 24 bits of "Company ID" (similar to MAC addresses I guess?), and the registry records are public, they were able to precompute a bunch of public/private keypairs.