[HN Gopher] Attack of the Week: Airdrop Tracing
___________________________________________________________________
Attack of the Week: Airdrop Tracing
Author : feross
Score : 48 points
Date : 2024-01-11 17:03 UTC (1 days ago)
(HTM) web link (blog.cryptographyengineering.com)
(TXT) w3m dump (blog.cryptographyengineering.com)
| JimDabell wrote:
| > While AirDrop's device-to-device communications channel is
| typically protected from third-party snooping by its own layer of
| security, that wouldn't shield someone who may have been tricked
| into connecting with a stranger, perhaps by tapping on a
| deceptively named device in a list of contacts or by
| thoughtlessly accepting an unsolicited connection request. This
| step is required for the sender to be identified, according to
| security experts.
|
| Apple already acted on this, didn't they? AirDrop now defaults to
| off and you can only switch it on for ten minutes at a time - you
| can't forget to switch it off again. When Apple implemented this
| change, I remember that they were criticised because people said
| they were doing what China wanted by cracking down on P2P
| communication. Now it's the opposite situation but the same
| criticism.
| zaltekk wrote:
| I believe what they changed is the ability for "everyone" to
| discover you to a 10 minute toggle. It defaults to always being
| discoverable to your contacts.
|
| I assume that it still broadcasts your hashes even in the
| contacts-only mode, so you'd need to turn receiving off to stop
| that. Or go a step further and disable Bluetooth entirely* when
| you don't need it.
|
| * If you disable Bluetooth in the Control Center pulldown it
| won't actually disable Bluetooth or beacons. It just won't
| connect to devices. You need to go into Settings to actually
| disable Bluetooth.
| varenc wrote:
| Your phone isn't passively broadcasting hashes if it's just
| an AirDrop receiver no matter what mode it's in. This vuln
| only poses a privacy risk for those _sending_ AirDrops.
| fragmede wrote:
| PSI is an interesting bit of cryptography. If I were random Apple
| engineer, how would I have found it or found a cryptographer to
| talk to to find it?
| fma wrote:
| As far as I know, dissidents would hang around major population
| area (i.e, subway station) and allow for anonymous users to
| connect to them to transfer files. This security issue would
| allow the Chinese government to track them.
|
| However, also as far as I know...although VPNs are banned in
| China, there are ways to get them. I'd wonder how much do
| dissidents use Airdrop in this manner if they can access the
| global Internet anonymously. Given mass surveillance in China,
| I'm sure the Chinese government can track "oh this airdrop sender
| appears every time this person is in this station".
|
| I also hope that Apple adopts an open source protocol for AirDrop
| not just for cross platform compatibility, but auditable
| security. Android has its own "Nearby Share". If Apple doesn't
| want to get in trouble for "fixing" this, they can easily adopt a
| cross platform compatible protocol that just happens to also fix
| this.
| vyrotek wrote:
| Is this sort of sharing big enough to warrant dedicated and
| open-source devices just to do this? A sort-of glorified USB
| Drive with a sharing protocol and nothing else. You walk around
| and it just syncs up with things around you. Something that
| looks like an original iPod with a screen and folders of files.
|
| I don't know anything about the AirDrop or NearbyShare
| protocols, but I wonder if they can be implemented in such a
| device?
|
| All the recently announced dedicated AI devices make me think
| people might be into it.
| lxgr wrote:
| This would be great, and I'd be really happy to see it.
|
| One (definitely not insurmountable) problem that would exist in
| such a federated and open system is credential authentication:
|
| Currently, Apple signs your email address and phone number
| (hash) so that you can't impersonate somebody's trusted
| contacts and send unwanted material to them without their
| consent, which has been a problem for Apple in the past. That's
| supposedly also why they have removed the "allow all AirDrop
| senders" option in favor of one that times out after 10
| minutes.
|
| There would either have to be a federated alternative to that,
| or the open source system would have to drop sender
| authentication; then you could only receive AirDrops while your
| device is in "allow all senders" mode.
| olliej wrote:
| How would federation solve this problem?
|
| The reason there's anything in the airdrop protocol that can
| be converted to a person is to allow your device to say who
| is sending it _if_ you know their identity already, and /or
| to filter the messages if you don't.
|
| The whole point of this activity was that people did not
| care, nor want to care, about who was sending payloads. In
| such an environment the solution is no identity at all, not
| federation of identity.
|
| If you do try to do this simply because of "federation", all
| china does it use the same federation system to get the user
| information (because the whole point here is china was
| monitoring local bluetooth info, so some nebulous application
| of federation dust doesn't magically resolve anything).
|
| The problem here is that people were using a system is not
| anonymous by design (there is a deterministic relationship
| between the underlying account and the hash by _published
| design_ ), and that relationship is necessary for basic
| functionality. A hindsight being 50/50 step could have been
| to use a password hashing function, but airdrop has existed
| long enough at this point for me to assume that the iterative
| systems would have relatively low iteration counts, and
| mobile hardware probably can't afford the resources to make
| every airdrop also perform memory bounding steps.
| lxgr wrote:
| > How would federation solve this problem?
|
| I'm not saying that federation solves the anonymity
| problem, I'm just saying that the current implementation
| includes Apple as a trust anchor for email address and
| phone number verification and issuance of corresponding
| certificates. My point is that in order to enable an open
| cross-platform solution, there would have to be some
| alternative mechanism to that.
|
| What they could add is a sender-side option that makes
| sending completely anonymously. This would be possible
| without any change on the receiver side, but would require
| recipients to enable "allow all senders" mode.
| error503 wrote:
| Fundamentally this verification is based on your contact
| list, which is formed from people you already know and
| have added to your contacts, so there's not really any
| need for a centralized trust. Presumably you trust the
| e-mail address of the contact you added, and the
| federation protocol could easily define how the
| authoritative hash/key for each user would be shared
| based on their e-mail.
|
| In most cases this could also be resolved at first
| contact in meatspace, directly between the devices when
| establishing contact via the typical ways users share
| contact information - QR code or some form of short range
| networking, or even with an SMS challenge.
| bobobob420 wrote:
| Many people use vpn openly in china for business and gaming.
| Its sort of allowed. Source : my Chinese mates
| notso411 wrote:
| Why doesn't it store a shared secret based on some information
| from both parties once a contact has been mutually agreed to be
| shared... then you can quickly do a verification without any
| interception from outside sources or any information leaking
| lxgr wrote:
| How do you Airdrop to new contacts then? And how do you sync
| shared secrets securely across multiple devices of a single
| user?
| notso411 wrote:
| You must have been in person to share contact details
|
| Same way it does with password manager
| lxgr wrote:
| That would unfortunately make for behavior inconsistent
| with the way AirDrop works today. You might have to become
| "visible to everyone" randomly on a new device, for
| example.
|
| Not insurmountable, but it would probably be quite un-
| Apple-like.
| error503 wrote:
| It can't be mutual because the receivers don't broadcast, so
| the sender doesn't know which contacts are in range.
|
| I was also thinking you might be able to use asymmetric crypto
| for this, and encrypt the hash + a nonce using your private
| key, and anyone with your public key can decrypt it and check
| the hash against the contact list. But this means the potential
| receiver needs to decrypt with every public key it knows, which
| for large contact lists might be prohibitively expensive.
|
| Someone has probably devised a more clever way, though.
| deafpolygon wrote:
| Is it an unfixed exploit when Apple knowingly left it as is for
| whatever reason?
| kornhole wrote:
| If a company creates a back door for a government in a way that
| it looks like an oopsie vulnerability, it gives them plausible
| deniability. If someone reports the vuln and they don't fix it,
| this somewhat shatters the plausible deniability.
|
| Operation triangulation https://securelist.com/operation-
| triangulation-the-last-hard... revealed the use of four different
| vulnerabilities, hidden code and undocumented features to take
| over Iphones. Its sophistication points to an APT. Apple did not
| deny helping the attacker TMK.
| lxgr wrote:
| Does it still count as an "oopsie vulnerability" if Apple has
| publicly documented this behavior for years in their
| documentation?
|
| https://support.apple.com/guide/security/airdrop-security-se...
|
| > Apple did not deny helping the attacker TMK.
|
| I can imagine many non-malicious alternative explanations for
| Apple not commenting on that particular vulnerability. For
| example, doing that here opens the door to a future in which
| every non-denial is seen as implicit admission of
| collaboration.
|
| It's also possible that Apple themselves was compromised: It's
| a large company, and other types of leaks do happen.
|
| I'd focus much more on the things Apple very publicly does
| _not_ do, such as in this case not using private set
| intersection for AirDrop.
|
| The best vulnerability is the one you don't even have to
| defend, because it's just the absence of a more secure (but
| also more complicated) alternative. There are countless
| historical examples of that: Unencrypted instant messaging,
| non-end-to-end encrypted cloud storage etc.
| SheinhardtWigCo wrote:
| The idea that Apple needs to _create_ backdoors for governments
| seems absurd when you consider that any competent government
| will have essentially unfettered access to Radar, i.e. a
| firehose of almost every security bug discovered by Apple or
| reported to it.
| dylan604 wrote:
| Why would any sane person allow accepting connections like this
| from any device? I don't even want to allow anyone from my
| contacts blindly just because I have saved their phone number.
| That isn't an automatic "I trust this person implicitly" flag.
|
| Clearly, I'm of "a certain age" where I don't blindly trust
| anyone for anything. It's amazing how quickly the concept of
| trust has been tossed aside from tech
| gruez wrote:
| > Why would any sane person allow accepting connections like
| this from any device? I don't even want to allow anyone from my
| contacts blindly just because I have saved their phone number.
| That isn't an automatic "I trust this person implicitly" flag.
|
| How is this any different than your phone accepting random MMS,
| imessages, or phone calls from any random phone number?
| masom wrote:
| This isn't how Airdrop works.
|
| The first step is a device lookup with "Bonjour", which allows
| devices to ping each other an see who's who. Any network device
| since the 1980s pretty much does this by default unless you
| disable it. Remember Netbios?
|
| The second step, is Airdrop requesting a device to accept a
| connection.
|
| At that point, you see who is sending you the send request, and
| you can accept/deny. Airdrop is also disabled by default from
| unknown senders since a dude sent a dick pick on an airplane.
| Your Apple device will only accept connections from known
| contacts by default, and you can override that setting to allow
| connections from anyone.
|
| You can disable this behaviour in Settings by blocking Airdrop.
|
| From the article: > While AirDrop's device-to-device
| communications channel is typically protected from third-party
| snooping by its own layer of security, that wouldn't shield
| someone who may have been tricked into connecting with a
| stranger, perhaps by tapping on a deceptively named device in a
| list of contacts or by thoughtlessly accepting an unsolicited
| connection request. This step is required for the sender to be
| identified, according to security experts.
| lxgr wrote:
| > The second step, is Airdrop requesting a device to accept a
| connection.
|
| > At that point, you see who is sending you the send request,
| and you can accept/deny.
|
| Revealing the identity hash must happen earlier than that,
| since the entire point of the "only contacts" feature is that
| you can't even see non-contacts on your AirDrop share sheet.
|
| And since Apple (correctly, in my view) didn't want receiving
| devices to publicly broadcast their identities (or even worse
| the set of acceptable senders), it's on the sender to
| initially broadcast their identity to _all_ devices within
| range.
|
| The candidate devices (i.e. those that have the sender in
| their contacts) then respond and get populated in the share
| sheet target list.
|
| What's potentially surprising is that this must happen even
| before selecting AirDrop as a share target, since (at least
| on my device) I can already see nearby AirDrop contacts in
| the "frequently contacted" part of the general share sheet...
| masom wrote:
| Yes, there's a more complicated explanation as it's all
| happening as part of Bonjour
| https://developer.apple.com/bonjour/
|
| The sender device broadcasts their identity, while the
| receiving devices will follow the Airdrop settings. When in
| contacts only and/or disabled, your device will not
| broadcast your personal identity in the clear.
|
| Your device itself broadcasts its presence through various
| protocols.
|
| This is a follow-up to the NetBIOS protocol that did the
| same (Windows shares is another example).
| lxgr wrote:
| As far as I understand the "vulnerability" (it's really AirDrop
| working as publicly documented), it happens when you attempt to
| share content, not when you're visible for receiving content.
| jxy wrote:
| Recall when anyone could page you? Now they can text you. And
| by "text", I mean, any media.
| BuildTheRobots wrote:
| Good writeup, thank you for sharing.
|
| Even before the discovery phase (which is where this issue sits),
| the two devices apparently create a TLS tunnel with both client
| and server certificates, signed by Apple and containing UUIDs
| linked to the device and Apple ID [0].
|
| I have no idea if/where/how these certs are used elsewhere, but
| this seems like another avenue of identification and tracking
| even if it doesn't directly expose the phone number or email
| address. I'm pondering early IMSI catchers didn't expose the
| MSISDN, but enough listeners in various places seeing the same
| IMSI sure helped for correlation. Does anyone know of any
| writeups on Apple's internal (device) CA infrastructure?
|
| [0] Section 2.4:
| https://www.usenix.org/system/files/sec21-heinrich.pdf
| gruez wrote:
| >Even before the discovery phase (which is where this issue
| sits), the two devices apparently create a TLS tunnel with both
| client and server certificates, signed by Apple and containing
| UUIDs linked to the device and Apple ID [0].
|
| From the abstract
|
| >We propose a novel optimized PSI-based protocol called
| PrivateDrop that addresses the specific challenges of offline
| resource-constrained operation and integrates seamlessly into
| the current AirDrop protocol stack
|
| Is section 2.4 how it works today, or what they're proposing
| for the future?
| pushcx wrote:
| They're also moving to reduce AirDrop privacy. If you want to
| have a Home or Work address set in Maps, it forces the creation
| of a Contact Card with that info. Then AirDrop got a new feature
| called NameDrop, on by default, where phones near each other play
| an animation and display a button to send your Contact Card to
| the other (single press, no confirmation). There's no
| documentation of what info is shared this way, and it's not
| delineated on the Contact Card in the Contacts app.
|
| https://support.apple.com/guide/iphone/namedrop-iphone-share...
|
| The way this and other features in iMessage and Wallet work,
| Apple has adopted Facebook's approach to privacy: users are
| assumed to want to use their government's single idea of their
| name for all actions, and the default visibility for everything
| is as public as possible.
| lelandfe wrote:
| Don't the phones practically need to be touching for that
| feature?
|
| I don't think that reduces AirDrop privacy, you'd know who it
| was from that distance anyway.
| jrmg wrote:
| You also need to affirmatively press the button obviously
| titled 'share' before it sends the contact info.
| NavinF wrote:
| Yep. I'm convinced that anyone complaining about this has
| never used the feature. Context on how this misinformation
| started on the Facebook pages of police departments:
| https://www.macrumors.com/2023/11/27/ios-17-namedrop-
| misinfo...
|
| Some day I'd like to use an LLM to read every user's
| comments on websites like this and automatically tag the
| users that fell for similar fake stories. That way I can
| avoid wasting time researching their claims
| dang wrote:
| Recent and related:
|
| _Apple knew AirDrop users could be identified and tracked as
| early as 2019_ - https://news.ycombinator.com/item?id=38971811 -
| Jan 2024 (13 comments)
|
| _China Says It Cracked Apple AirDrop to Identify Message
| Sources_ - https://news.ycombinator.com/item?id=38925681 - Jan
| 2024 (21 comments)
___________________________________________________________________
(page generated 2024-01-12 23:00 UTC)