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).
> Hold up, how are they generating a private key from a public key?
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.
They patched the finders, presumably by fixing this:
> 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.
ok so it seems like 2 attack patterns, one where you can replace the bluetooth on the target device, and another where you can find a matching public key prefix and set up an beacon for it using your own private key ? or am I still not getting that
No, they find the victim's MAC and generate a payload to broadcast from the victim's device, which will make the device appear to Apple devices as a genuine Airtag. Apple devices then upload location reports to Apple, and the attacker downloads them. No real Airtags are involved.
They pregenerate the key pairs. The trojan sends the MAC to the server, and the server looks in its (precomputed) stash of key pairs, to find a public key that matches.
They're brute-forcing the generation of a public key using random private keys. The exact private key doesn't matter. The full length of the generated public key doesn't even matter, only the first 46 bits. Since they only need to find a public key matching those 46 bits instead of the full 226 bits, that makes a brute force search possible.
Hm, interesting. 2^46 is only 70 trillion, so yeah, totally computationally feasible. So,
if i understand correctly, they only need a GPU to generate a database of 70 trillion private / public keys? Damn, not bad.
could Android users in a place like NYC/LA/London create a mesh network of "virtual airtags" that virtually follow all the iPhones around the city advertising to each that it is mysteriously being followed endlessly? I would switch to Android to participate. (ok, that's my opsec, i'm already on Android. haha gotcha! that's my opsec, i actually have...)
It's not something I'd do, but there are a number of reasons people might do something like this, including:
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 certainly a more charitable interpretation of their comment than I gave it, perhaps I was unfair though I rather suspect the intent was closer to my reaction than your ideas
Text-based communication, especially informal comment text, are obviously pretty terrible at accurately conveying tone and intent. I like to adhere to the “assume good faith” maxim whenever possible, although that’s increasingly difficult in this polarized age of “Roman salutes.” Anyhow, I personally read their comment as something of a tongue-in-cheek chaotic neutral sort of curiosity.
> "I like to adhere to the “assume good faith” maxim whenever possible"
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
Maybe an off-the-cuff idea, in curiosity and good-natured mischievousness, and then minutes later, while thinking it through, would realize, oh yeah, that could be bad, whew, sigh, and that's humbling.
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.
I use Apple and Android because I like gadgets and technology and software. I dislike anything proprietary. I am up for doing anything to undermine Apple's proprietary products. If Apple has a proprietary means of telling people they are being stalked by stalking devices that Apple also sells, yes, i will do anything to undermine it. And anyway, it's Apple stalking and telling people they are being stalked, not me.
Would you be interested in creating a non-proprietary alternative for functionality people desire (with whatever technical and philosophical differences you want)?
Maybe see it as undermining via creating what you see as good, rather than as destroying what you see as bad?
At this point the best thing is mave sure this is well known. If he has the idea you can bet evil [china, north korea, russia... should come to mind] will too. If I do it I'm harmless but it forces apple to react. If evil does that they will also hide their tracks and so we are less likely to find out while they do their harm.
An interesting thing to note from the article is that this isn't just a garden variety jailbreak/adversarial interoperability with a BLE protocol. It lets you turn someone else's device into an airtag, then track its location.
> 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 :)
The patch for iOS is not to stopp the potential hijack via a Trojan software but to stopp the mesh of iOS devices to broadcast the find my messages around.
Yeah - this is really really cool, but if you have code running on the target device, why relay its location via FindMy? If you are already talking to an external server to get pre-computed keys, there are easier ways to share location than FindMy… I guess if the target device doesn’t have GPS, FindMy does get you closer than other geolocation methods.
Seems like a good way to physically pin down where a hacked computer may be located. Could be useful for people like ransomware authors who infect devices all over the world.
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.
It's a matter of time before advertising SDKs within any ad-supported apps will start leveraging this to geolocate users without additional permissions. Especially for apps that already have location permissions (something as simple as a weather app) this will hardly be noticed.
>It's a matter of time before advertising SDKs within any ad-supported apps will start leveraging this to geolocate users without additional permissions.
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.
Won't work on iOS. An app cannot simply get the local MAC address on iOS. Privacy reasons. And trying all the (2^8)^3 options will also not work - for power reasons you'll be quickly throttled.
Could the 256^3 presets not be pre-calculated? It's not like the intent for these keys is to make them private and secure, so reusing the same key material except for the MAC address itself shouldn't be a problem, should it?
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?
You don't need MAC address - you just need the iPhone to broadcast specific BLE advertising packet/payload.
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
This won't really affect OpenHaystack in any meaningful way. The only additional thing this paper shows is that it is possible to brute-force the key necessary to broadcast a valid FindMy BLE message, without needing to change the advertised MAC address (which generally requires root privileges). If you wanted to turn your own devices into Airtags, you could just change the advertised MAC with root permissions to skip the brute-force step.
In the spirit of constructive criticism, I'd suggest that the GPU section of the summary feels like a fish out of water and should probably either be removed or supplemented with a bit more context from the actual paper. Cheers.
For those who don't want their iPhone participating in the Find My network, from my understanding, turning off iCloud disables the sharing of BLE advertisements.
So, this vulnerability requires root access to a device…
That means I can make my own laptop broadcast lost beacons and I’ll have free anti-theft tracking of my device!?
Nice. I have some Chipolo trackers but the tracking is pretty bad compared to air tags. Would this approach let me make them trackable via Apple's network too?
Only if you manage to flash custom firmware on them. But there's already been many efforts on creating firmware for devices costing only a few bucks each, so that's probably easier.
... and an Apple Account with an SMS-verified telephone number.
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.
Actual Airtags rotate their keys on a daily basis (when in lost mode), and Apple can't predict those keys. Theoretically they could tell that you're looking for a tag reported by devices x y and z, but the actual locations are encrypted.
Does anyone know if the fix for this vulnerability removes the ability to use your own arbitrary BLE devices on the FindMy network? I haven't personally looked through the technical details of how that has been accomplished in the past, but it sounds up front like it might.
People will still be finding these vulnerabilities. Just fewer of them, and fewer of them from within the United States, and fewer of them publishing the details publicly.
My gut says a lot of vulnerabilities disclosed like this had probably already been found by those people that won’t disclose them publicly. Programs that expose these vulnerabilities, funded by countries that can afford it, are probably the biggest stopgaps keeping it mostly in the realm of sketchy nation-state intelligence agency shenanigans rather than organized crime with ransomware-gang-level technical savvy and terrorist organizations. The frustrating thing is that there’s no way you can guarantee that some future problem would have been prevented by a program like this — it’s just good societal-level stewardship of our communications infrastructure. People that consider it reasonable for regular people to defend themselves against things like this without societal support and guidance are delusional. Beyond that, if we think we’re going to maintain dominance in the digital space, removing our collective investment in figuring out what that entails based on a dubious assumption that private industry will pick up the slack unprompted is as penny wise and pound foolish as you get.
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
Interesting. They seem to be abusing a hole where Apple wasn't confirming that the broadcast addresses were valid for tags (ie: "random static" addresses rather than public ones).
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.
> they are just using a "normal" BLE address and then reverse-engineering a key from that.
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.
Here is my quick summary:
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).
[1] https://github.com/seemoo-lab/openhaystack
Hold up, how are they generating a private key from a public key? That's supposed to be very difficult.
Are you saying that a large chunk of the key (private key or public key?) is a manufacturer code? That's insane
> Hold up, how are they generating a private key from a public key?
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 get how Apple patched this. What does the patch change to do differently?
I don't see a way of fixing this without shutting off the current Airtag network.
They patched the finders, presumably by fixing this:
> 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.
victim's BLE address == target device they previously scanned and set up an Airtag for ?
No.
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.
ok so it seems like 2 attack patterns, one where you can replace the bluetooth on the target device, and another where you can find a matching public key prefix and set up an beacon for it using your own private key ? or am I still not getting that
No, they find the victim's MAC and generate a payload to broadcast from the victim's device, which will make the device appear to Apple devices as a genuine Airtag. Apple devices then upload location reports to Apple, and the attacker downloads them. No real Airtags are involved.
They pregenerate the key pairs. The trojan sends the MAC to the server, and the server looks in its (precomputed) stash of key pairs, to find a public key that matches.
They're brute-forcing the generation of a public key using random private keys. The exact private key doesn't matter. The full length of the generated public key doesn't even matter, only the first 46 bits. Since they only need to find a public key matching those 46 bits instead of the full 226 bits, that makes a brute force search possible.
Hm, interesting. 2^46 is only 70 trillion, so yeah, totally computationally feasible. So, if i understand correctly, they only need a GPU to generate a database of 70 trillion private / public keys? Damn, not bad.
They use rainbow tables.
Generated once.
could Android users in a place like NYC/LA/London create a mesh network of "virtual airtags" that virtually follow all the iPhones around the city advertising to each that it is mysteriously being followed endlessly? I would switch to Android to participate. (ok, that's my opsec, i'm already on Android. haha gotcha! that's my opsec, i actually have...)
[flagged]
It's not something I'd do, but there are a number of reasons people might do something like this, including:
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 certainly a more charitable interpretation of their comment than I gave it, perhaps I was unfair though I rather suspect the intent was closer to my reaction than your ideas
Text-based communication, especially informal comment text, are obviously pretty terrible at accurately conveying tone and intent. I like to adhere to the “assume good faith” maxim whenever possible, although that’s increasingly difficult in this polarized age of “Roman salutes.” Anyhow, I personally read their comment as something of a tongue-in-cheek chaotic neutral sort of curiosity.
> "I like to adhere to the “assume good faith” maxim whenever possible"
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
Maybe an off-the-cuff idea, in curiosity and good-natured mischievousness, and then minutes later, while thinking it through, would realize, oh yeah, that could be bad, whew, sigh, and that's humbling.
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.
I use Apple and Android because I like gadgets and technology and software. I dislike anything proprietary. I am up for doing anything to undermine Apple's proprietary products. If Apple has a proprietary means of telling people they are being stalked by stalking devices that Apple also sells, yes, i will do anything to undermine it. And anyway, it's Apple stalking and telling people they are being stalked, not me.
Would you be interested in creating a non-proprietary alternative for functionality people desire (with whatever technical and philosophical differences you want)?
Maybe see it as undermining via creating what you see as good, rather than as destroying what you see as bad?
At this point the best thing is mave sure this is well known. If he has the idea you can bet evil [china, north korea, russia... should come to mind] will too. If I do it I'm harmless but it forces apple to react. If evil does that they will also hide their tracks and so we are less likely to find out while they do their harm.
An interesting thing to note from the article is that this isn't just a garden variety jailbreak/adversarial interoperability with a BLE protocol. It lets you turn someone else's device into an airtag, then track its location.
> 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 :)
No, read the summary from the top comment.
The patch for iOS is not to stopp the potential hijack via a Trojan software but to stopp the mesh of iOS devices to broadcast the find my messages around.
Actually, very much yes. The device to be tracked needs to be exploited somehow in order to run the code to advertise its existence via BLE.
FTA's "Architecture of nRootTag":
> (1) The Trojan code runs on the computer to be tracked.
Yeah - this is really really cool, but if you have code running on the target device, why relay its location via FindMy? If you are already talking to an external server to get pre-computed keys, there are easier ways to share location than FindMy… I guess if the target device doesn’t have GPS, FindMy does get you closer than other geolocation methods.
Seems like a good way to physically pin down where a hacked computer may be located. Could be useful for people like ransomware authors who infect devices all over the world.
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.
The problem with this exploit is it needs something on the device that sends out BLE packets.
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.
It's a matter of time before advertising SDKs within any ad-supported apps will start leveraging this to geolocate users without additional permissions. Especially for apps that already have location permissions (something as simple as a weather app) this will hardly be noticed.
>It's a matter of time before advertising SDKs within any ad-supported apps will start leveraging this to geolocate users without additional permissions.
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.
> They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app.
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.
> They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app.
As if people would care about that...
Won't work on iOS. An app cannot simply get the local MAC address on iOS. Privacy reasons. And trying all the (2^8)^3 options will also not work - for power reasons you'll be quickly throttled.
Could the 256^3 presets not be pre-calculated? It's not like the intent for these keys is to make them private and secure, so reusing the same key material except for the MAC address itself shouldn't be a problem, should it?
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?
You don't need MAC address - you just need the iPhone to broadcast specific BLE advertising packet/payload.
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).
Please read the original source again. You need to KNOW (or guess) own mac address as it becomes a part of the key.
Yes, you are correct!
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
Not a problem at all depending on what your goal is.
Yeah
- 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.
I get that this is an attack, but if I could get this on my own non-apple bluetooth devices that would be really convenient.
This was posted a month ago: https://news.ycombinator.com/item?id=42835772
How does this differ from https://github.com/seemoo-lab/openhaystack
Edit: It works without root. Follow up question: Can these discoveries improve openhaystack?
This won't really affect OpenHaystack in any meaningful way. The only additional thing this paper shows is that it is possible to brute-force the key necessary to broadcast a valid FindMy BLE message, without needing to change the advertised MAC address (which generally requires root privileges). If you wanted to turn your own devices into Airtags, you could just change the advertised MAC with root permissions to skip the brute-force step.
It doesn’t require installing a custom Bluetooth firmware.
Well they copied the diagrams from there for one
In the spirit of constructive criticism, I'd suggest that the GPU section of the summary feels like a fish out of water and should probably either be removed or supplemented with a bit more context from the actual paper. Cheers.
I wonder if Apple will keep this open out of the kindness of their heart. Or all these unintended uses will result in them locking down their network.
I guess all my Apple devices are looking for this and sharing it to Apple and wonder how much that data adds up.
They already fixed it in recent updates, but many non-updated devices will remain around for quite a while. It’s not fixable server-side.
what's the fix for this sort of exploit? Narrowing the accepted packets to airtag specific packet types?
OpenHaystack has been around for a long time, and they don't really seem to care much
For those who don't want their iPhone participating in the Find My network, from my understanding, turning off iCloud disables the sharing of BLE advertisements.
Simply turning off Find My Phone does the same, I believe
So, this vulnerability requires root access to a device… That means I can make my own laptop broadcast lost beacons and I’ll have free anti-theft tracking of my device!?
Something straight out of Samy Kamkar's book. Nice
Nice. I have some Chipolo trackers but the tracking is pretty bad compared to air tags. Would this approach let me make them trackable via Apple's network too?
Only if you manage to flash custom firmware on them. But there's already been many efforts on creating firmware for devices costing only a few bucks each, so that's probably easier.
Seems like this opens up the possibility of open source hw/sw compatible AirTags and virtual AirTags, yeah?
I never knew Apple let anyone access the lost announcement messages from the AirTags sent through iCloud.
You need the private key associated with the AirTag in order to decrypt the result.
... and an Apple Account with an SMS-verified telephone number.
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.
Actual Airtags rotate their keys on a daily basis (when in lost mode), and Apple can't predict those keys. Theoretically they could tell that you're looking for a tag reported by devices x y and z, but the actual locations are encrypted.
Does anyone know if the fix for this vulnerability removes the ability to use your own arbitrary BLE devices on the FindMy network? I haven't personally looked through the technical details of how that has been accomplished in the past, but it sounds up front like it might.
It does not remove that ability.
um, can't this be abused to flood the system like a ddos?
> This work was supported in part by the US National Science Foundation (NSF) under grants CNS-2304720, CNS-2310322, CNS-2309550, and CNS-2309477
Good old days.
People will still be finding these vulnerabilities. Just fewer of them, and fewer of them from within the United States, and fewer of them publishing the details publicly.
My gut says a lot of vulnerabilities disclosed like this had probably already been found by those people that won’t disclose them publicly. Programs that expose these vulnerabilities, funded by countries that can afford it, are probably the biggest stopgaps keeping it mostly in the realm of sketchy nation-state intelligence agency shenanigans rather than organized crime with ransomware-gang-level technical savvy and terrorist organizations. The frustrating thing is that there’s no way you can guarantee that some future problem would have been prevented by a program like this — it’s just good societal-level stewardship of our communications infrastructure. People that consider it reasonable for regular people to defend themselves against things like this without societal support and guidance are delusional. Beyond that, if we think we’re going to maintain dominance in the digital space, removing our collective investment in figuring out what that entails based on a dubious assumption that private industry will pick up the slack unprompted is as penny wise and pound foolish as you get.
[flagged]
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
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.
Interesting. They seem to be abusing a hole where Apple wasn't confirming that the broadcast addresses were valid for tags (ie: "random static" addresses rather than public ones).
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.
> they are just using a "normal" BLE address and then reverse-engineering a key from that.
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.
Apple used the company ID as part of the key material??
No. Read the paper again, specifically figure 3.
[flagged]
[flagged]
So whatever happened to Big Tech's eNd TO EnD enCRYptIOn? If I had to guess, this was an intentional backdoor that was just discovered.
It’s still end-to-end-encrypted, but the attacker effectively controls both ends. There is no backdoor.