[HN Gopher] Turning a Bluetooth device into an Apple AirTag with...
___________________________________________________________________
Turning a Bluetooth device into an Apple AirTag without root
privileges
Author : layer8
Score : 480 points
Date : 2025-02-27 17:03 UTC (1 days ago)
(HTM) web link (nroottag.github.io)
(TXT) w3m dump (nroottag.github.io)
| mmastrac wrote:
| 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.
| Domenic_S wrote:
| > 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.
| krupan wrote:
| Apple used the company ID as part of the key material??
| gruez wrote:
| No. Read the paper again, specifically figure 3.
| sedatk wrote:
| > 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.
| lynndotpy wrote:
| 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.
| deskr wrote:
| [flagged]
| dang wrote:
| 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.
| chefandy wrote:
| 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.
| internetter wrote:
| How does this differ from https://github.com/seemoo-
| lab/openhaystack
|
| Edit: It works without root. Follow up question: Can these
| discoveries improve openhaystack?
| layer8 wrote:
| It doesn't require installing a custom Bluetooth firmware.
| saagarjha wrote:
| Well they copied the diagrams from there for one
| malmeloo wrote:
| 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.
| hackernudes wrote:
| 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
| krupan wrote:
| 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
| rahimnathwani wrote:
| 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.
| avidiax wrote:
| > 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.
| aorloff wrote:
| victim's BLE address == target device they previously
| scanned and set up an Airtag for ?
| malmeloo wrote:
| 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.
| avidiax wrote:
| 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.
| aorloff wrote:
| 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
| jychang wrote:
| 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.
| dtech wrote:
| 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.
| lelandbatey wrote:
| 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.
| helsinki wrote:
| 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.
| layer8 wrote:
| They use rainbow tables.
| bluGill wrote:
| Generated once.
| fsckboy wrote:
| 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...)
| sodality2 wrote:
| 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 :)
| rahimnathwani wrote:
| It lets you turn someone else's device into an airtag, then
| track its location.
|
| Only if you can get their device to run your code.
| Limeray wrote:
| No, read the summary from the top comment.
| hug wrote:
| 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.
| raudette wrote:
| 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.
| rahimnathwani wrote:
| Yes, not having GPS is one reason. The other one (less
| good) is that you can continue to track the device even
| when it has no network connection (as long as it's turned
| on and near an iPhone).
|
| 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?
| larusso wrote:
| 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.
| mannyv wrote:
| 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.
| jeroenhd wrote:
| 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.
| dmitrygr wrote:
| 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.
| jimiasty wrote:
| 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).
| dmitrygr wrote:
| Please read the original source again. You need to KNOW
| (or guess) own mac address as it becomes a part of the
| key.
| jimiasty wrote:
| 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
| jeroenhd wrote:
| 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?
| dmitrygr wrote:
| The problem is not pre-calculation. The problem is that
| because you don't know your MAC address, you need to
| broadcast all of those things, since you don't know which
| one will be valid. Either at once or sequentially. Either
| way, iOS will not let you set up that much broadcasting.
| gruez wrote:
| >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.
| mschuster91 wrote:
| > 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...
| jeroenhd wrote:
| > 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.
| WatchDog wrote:
| 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.
| anigbrowl wrote:
| Not a problem at all depending on what your goal is.
| devmor wrote:
| 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.
| rahimnathwani wrote:
| It does not remove that ability.
| jeroenhd wrote:
| 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.
| ck2 wrote:
| um, can't this be abused to flood the system like a ddos?
| prepend wrote:
| 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.
| layer8 wrote:
| 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.
| lgats wrote:
| what's the fix for this sort of exploit? Narrowing the
| accepted packets to airtag specific packet types?
| malmeloo wrote:
| OpenHaystack has been around for a long time, and they don't
| really seem to care much
| kittikitti wrote:
| 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.
| layer8 wrote:
| It's still end-to-end-encrypted, but the attacker effectively
| controls both ends. There is no backdoor.
| ww520 wrote:
| I never knew Apple let anyone access the lost announcement
| messages from the AirTags sent through iCloud.
| layer8 wrote:
| You need the private key associated with the AirTag in order to
| decrypt the result.
| octoberfranklin wrote:
| ... 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.
| malmeloo wrote:
| 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.
| ctkhn wrote:
| 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.
| 1024core wrote:
| This was posted a month ago:
| https://news.ycombinator.com/item?id=42835772
| Rebelgecko wrote:
| 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?
| malmeloo wrote:
| 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.
| rubatuga wrote:
| 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.
| Angostura wrote:
| Simply turning off Find My Phone does the same, I believe
| reader9274 wrote:
| Something straight out of Samy Kamkar's book. Nice
| slicktux wrote:
| 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!?
| tensility wrote:
| 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.
| cantrecallmypwd wrote:
| Seems like this opens up the possibility of open source hw/sw
| compatible AirTags and virtual AirTags, yeah?
___________________________________________________________________
(page generated 2025-02-28 23:02 UTC)