（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=43196207

研究人员在苹果的“查找我的”网络中发现了一个漏洞，允许使用Apple的基础架构跟踪任何蓝牙设备，从而将其转变为Airtags。 “查找我的”网络依赖于丢失设备的BLE广告，在广告地址中嵌入了部分公钥。苹果的预期设计需要“随机静态”地址，但研究人员发现，苹果设备接受了任何地址类型。利用这一点，他们开发了“ nroottag”，这是一种将设备转换为无根访问的跟踪器的攻击。通过生成匹配设备的蓝牙地址的私钥（可以预先计算），它们可以创建有效的“丢失设备”广告。这允许通过Apple网络跟踪Linux，Android和Windows设备。当苹果发行补丁时，漏洞持续了未拨动的设备。该问题源于“查找我的”广告中的BLE地址类型的验证。该研究强调了严重的隐私风险，因为恶意参与者可以在未经用户同意的情况下利用庞大的Apple设备网络进行跟踪。

AirPods快速连接安全漏洞 2024-07-01

Apple 和 Google 为 iOS 和 Android 中不需要的跟踪警报提供支持 2024-05-15

（评论） 2024-07-01

（评论） 2024-05-29

原文

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.

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.

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'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.

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?

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.

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 :)

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.

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.

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.

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).

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

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.

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.

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!?

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.

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.

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.

> 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.

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.

（评论） (comments)

（评论）
(comments)