Hacker News new | past | comments | ask | show | jobs | submit login
What an attacker gets from Apple devices if they sniff Bluetooth traffic (hexway.io)
190 points by est31 3 months ago | hide | past | web | favorite | 81 comments



Clickbait title: 'If Bluetooth is ON on your Apple device everyone nearby can understand current status of your device, get info about battery, device name, Wi-Fi status, buffer availability, OS version and even get your mobile phone number'


And for the phone number part, “If Bluetooth is ON on your Apple device AND you’re trying to Airdrop something (which you’d expect to send some identifying information) or connect to a new WiFi network (same)...”

To be fair I wouldn’t necessarily expect those actions to send out a hash of my phone number, but the threat indicated by the title is definitely overblown.


AirDrop has to send out a hash of you so that way the surrounding devices that are set to "contacts only" can use it to determine if you're in their contacts list (and therefore that it should respond).

I'm not sure why WiFi has to send a hash of your phone number, I thought it just prompted nearby devices to ask if they wanted to share it. Maybe there is some functionality there relating to determining if the sender is in your address book, I'm not sure.


Yes, it will only share the WiFi password with devices in your contacts.


> I'm not sure why WiFi has to send

AirDrop operates on both Bluetooth and WiFi


A part of the problem is that bluetooth is almost always ON on iPhones. The way one typically toggles it from the control center only disables bluetooth for a short period of time (24 hours), after that, it turns on again. One has to go into settings to actually disable bluetooth.


And it's the same shit with Wifi. Hitting the button in the control center merely disconnects from the current network; to actually turn it OFF, you have to go into the settings. I hate that.


To be fair I quite like that feature. Usually if I'm disconnecting from a WiFi it's because it's not working very well and I want to use my mobile data instead. If I forget to turn it back on I'd end up using way too much data.


I hope you realize that doesn't mean that you disconnected.

Try opening an ad-monetized app that requires network connection to load the ads. Make sure cellular date for that app is off. You'll get ads. Unless something has changed in the past few weeks, you should see ads load despite the fact that they should not in this scenario.

This means the Wi-Fi isn't off, isn't even in a respectful hibernate state, it's on but telling you it's off. It's your child telling you "yes mommy/daddy I'll do it right" and then cuts corners knowing you're going to trust them.

In the past few weeks my iPhone X has been having a strange Wi-Fi bug where it says it's on in the top corner of the screen, but in settings it says it's off. I didn't turn it off. When I go to turn it off, it's frozen and I have to restart settings. I'm highly suspicious it's related to Apple's Wi-Fi and Bluetooth default hibernate code or implementation of that code.

Apple screwed the pooch on this one. They should allow us to toggle the hibernate mode or long press to choose whether to go into hibernate or actually turn off, not force us to use it in a misleading way.

I've trained myself to always turn it off in settings, it's annoying, but it fits apple's product motto:

It just works.


Fair point, but they could just have used short/long press to have both options, as mentioned elsewhere in this discussion.


Yeah true, they could easily give both options


Gotta love the dark pattern. I remember when they made the change, I was pretty frustrated with that.


"Dark pattern" seems too strong. Apple doesn't benefit from your turning Bluetooth on and isn't trying to manipulate you into doing so.

It's fixing the annoying issue of today's AirPods failing because of something I did yesterday afternoon which I forgot.


Apple does benefit from turning bluetooth on.

Your phone will locate and report bluetooth ibeacons, and allow apple to update their crowdsourced location databases.

The same thing with wifi (which has the same behavior in control panel)

It would have been SO SIMPLE to have a nicer pattern. short press to disconnect, long press to turn off.


>It would have been SO SIMPLE to have a nicer pattern. short press to disconnect, long press to turn off.

Indeed, this is exactly what I expected would happen when I long pressed and I was disappointed when it didn’t. There are definitely times like this when Apple’s UX gets more credit than it deserves.


Apple could have made that a three way toggle, or even made turning off Bluetooth permanently through a 3DTouch action or haptic long press action. Many people provided feedback on this when iOS 11 was released. Apple has not shown any willingness to solve this for Bluetooth or WiFi (both toggles in Control Center work the same way).


I mean, iPhone's have a somewhat checkered history with their batteries failing.

Which is one of the reasons why I'd always leave Bluetooth/WiFi off by default, and only turned them on when I actually need them: Cut way down on the battery draw.

That option is now gone, instead the default has become "everything is always on", drawing on the battery, thus forcing you to recharge more often, cutting down on the lifespan of your battery.

Not saying that was Apple's plan all along, but it's one of the outcomes of this pointless change. When the solution to this could be as simple as "double-tapping the icon will turn it off permanently, tapping once temporary".


> That option is now gone,

....No, it's really not.

You can still turn WiFi and Bluetooth off (really off) from the Settings app, and they will stay off until you turn them back on.

You can even turn them back on from Control Center.


Meanwhile I was absolutely thrilled they made this change. I can't count the number of times I realized WiFi was off because I had temporarily disabled it earlier as I stood just on the edge of my network's range and forgotten to re-enable it again.


Now imagine everyone less tech savvy than us who doesn't know why their bluetooth headphones won't work.

My family loves their iPhones but I don't think anyone knows how to swipe up from the bottom to check the control panel, much less what the bluetooth symbol is and how they should reenable it if their fat-finger disabled it one day. Or how to even troubleshoot that as a possibility.

Calling it a "dark pattern" is a bit silly and dramatic. This simple feature saves users a bunch of headache.

If you want to perma-disable bluetooth, you can toggle it off from the phone options instead of the quick menu. It's a great UI trade-off.


> If you want to perma-disable bluetooth, you can toggle it off from the phone options instead of the quick menu. It's a great UI trade-off.

It's not really a great UI trade-off.

It made the usability for a whole lot of users worse, all on the basis of other users forgetting what hardware they previously disabled/enabled.

Now you are forcing everybody who doesn't want BT to be always on, to always deep-dive into the options if they still want to use it for a moment. Which is something that the quick menu originally was supposed to be there for. So overall it's pretty much a step back.

Which is kinda sad, because there are more than one solutions to that which could have made everybody happy. Like giving a setting that defines the quick menu icons behavior (temporary vs permanent disable), or the ability to press to icons several times to at least toggle between temp/permanent disabled and on.


IIRC in previous versions of iOS, a Bluetooth icon would be visible when enabled. After reading the article, I thought, “Well, my Bluetooth is off.” But it sure wasn’t.


Agreed. It is weird that they just hash the phone number and don't salt it with something else. Even just appleid+phonenumber would be huge and prevent pre-attacks.


It's what about an hour to calculate the SHA of all 10 digit numbers in the US?


I was curious: my Laptop needed 18 minutes.


haha, I checked my source and I had the units wrong so I was off by a factor of 1000. Looks like 8x GTX1080s can do almost 3 billion SHA256 hashes per second, so you could just brute force these with no table with the right hardware.


Then the problem is: “You’re leaking your Apple ID to everyone in your contact list!” or more, depending on how exactly they’d plan to distribute Apple IDs to everybody else. The hash of the phone number thing is to provide the “contacts only” airdrop thing.


I'm missing what you are saying, sorry. If I know your email already, nothing is getting leaked. If I don't know your apple ID email, I have to brute force all combinations of email concatenated with your phone number to figure it out. If a stranger doesn't know either piece, they'd have to pre-image the entire space which is nigh impossible (all phone #s X all email addresses)


It’s convenient to just have a phone number be the piece both sides know. It’s not as magical if you need to also give your AppleID to every single contact manually, and if you have some sort of Phone Number to AppleID lookup service it’d be abused just as badly is what I’m saying here.


You're right, but they probably have/want to cover the case where you've given someone just your phone number (or just your email).


This article fails to mention that AirDrop is only enabled for Contacts by default.

Furthermore, each AirDrop session is a TLS session, where the users exchange iCloud certificates to authenticate each other.

See: https://www.apple.com/business/site/docs/iOS_Security_Guide.... (p. 45)

The phone is only as secure as the user makes it.


I believe that this information leak occurs BECAUSE AirDrop is only enabled for Contacts by default - you disclose your own hashed phone number when you open the Share dialog in order to allow nearby phones to decide whether you're on their Contacts list.


The claimed threat vector is loss of anonyminity. There is no anonyminity designed into AirDrop, and nowhere in Apple's documentation do I see the claim for it.

You iCloud account is your identity. When you choose to share things directly from your phone, you are choosing to share that identity. How else can another iPhone verify you?

There is no information leak. This is a clickbait title combined with a 'Well, duh' moment.


There’s a difference between disclosing “I am phone XYZ and I want to AirDrop” and “here is my phone number.” I would call that an information disclosure.

With that said I agree with you that it’s an intuitive and non-serious disclosure, but it appears some disagree.


Except it's not "here is my phone number", it's "if you know my phone number you can tell it's me".


It's functionally the same, because attackers can brute force all phone numbers to reverse the hash.


I just looked up Apple's Security White Paper and it explains that the Bluetooth LE signal only includes a "short identity hash", and then the receiving device responds with its own identity info, and then the sending device establishes a peer-to-peer WiFi connection and sends its "long identity hash", which the receiver then uses to confirm that it knows the recipient before responding with its own "long identity hash".

Which it to say, it sounds like you only get partial information about the sender prior to identifying yourself and establishing a direct connection. So you cannot passively identify the exact phone number of an unknown sender.

The "short identity hash" itself it says is "created based on the email addresses and phone numbers associated with the user’s Apple ID", though I have to assume that it's independently hashing each piece of info because if you hash the whole set, then the receiver would have to know the whole set, which would be a problem (my device knows more email addresses for me than any of my friends do).


Interesting. Looking at the code, it uses the first 3 bytes of the sha256 hash. That's 24 bits of entropy, or 16777216 possibilities. So if you know the area code, you can find the full phone number with decent probability.

https://github.com/hexway/apple_bleee/blob/master/hash2phone...


So basically someone trying to call all phone numbers and identify your number, when it rings falls in the same category?


No, calling a number is expensive. It takes time, processing power, a phone plan, etc. It also alerts the victim, as well as your phone provider who will likely shut you down. Calculating a hash is cheap, a single GPU can calculate 5 billion sha256 hashes/second.


That doesn't make sense. It's whether they are in my contact list.

If visibility is set to everyone then your phone will identify itself using its phone number so people know which device is yours and can click to share with it.


Doesn't the statement go both ways? How do you tell that a remote phone is in your contact list?


But Airdrop for contacts only is basically broken-especially for sharing between your own devices that are supposed to be on the same apple id-so you need to set it to ‘everyone’ for it to work all the time


I use AirDrop mostly to share with my own devices quickly, and I've been baffled that I have to set sharing to everyone to see my own devices. Setting it to contacts hasn't worked, and that's a big oversight by Apple.


I don't think that's true.

I just tested it, and with Contacts Only on both phone and laptop I'm still able to share things with myself.


Here's the problem space - I'm interested in how HN would design AirDrop without this information leak:

How do you allow two mutually untrusted client devices to determine that they share a common 9-digit number, without disclosing the secret? And for bonus points, how do you allow this to happen without two-way communication or access to a central authority?


This isn't my specialty, but I'm interested in cryptography. Here goes:

When an iCloud user is created, a keypair is generated. The private key is stored in the user's keychain; the public key is pushed to iCloud's server and placed in a central directory. Public keys of all of the user's contacts are cached locally on the device.

When Alice opens her phone to share something via AirDrop, it polls available devices over BTLE. The polling message contains a nonce.

Bob's device responds with a message containing two values: a nonce of his own, and a hashed+signed payload:

    (ecdsa_sign
        (bobs_private_key,
        (sha256_hash
            (concat
                alices_nonce,
                bobs_nonce))))
Alice's device computes the hash of the nonces, then iterates her contacts to find the one whose public key verifies the signature.

This approach defeats a precomputed attack by including a nonce from both parties - a rainbow can't be generated for all transactions, only this one in particular. It does not expose Bob's identity, because all that is transferred is a (random) nonce and a signed message.

The main drawback I see here is that when adding a contact, you have to download their public key from iCloud before you can share with them - so two devices cannot use AirDrop if they are not online, if they have not been online since the contact was added. As a workaround, you could set a flag when unsynced contacts are present and show a dialog if an AirDrop poll is detected before syncing occurs. In that case, you could fall back to something more closely resembling the currently implemented protocol, which would at least limit the data leakage present today to an edge case that requires explicit approval by the user.


From the article:

> your phone sends out SHA256 your phone number hash to all the devices around you every time you hit Share.

In theory, this should be enough to protect your number (although it's still a fingerprinting vector). The reason it's a problem isn't because other people can see the hash -- is because it's trivial to iterate over the list of possible phone numbers and figure out which one corresponds to each hash.

So... don't use 9 digit phone numbers. I'm sure I'm missing something, but this does not seem like a hard problem, at all.

Everyone using an Apple device has an Apple account. AirDrop is not compatible with Android; so this isn't a compatibility thing. I can't think of any reason why this needs to be a hash of a phone number instead of a randomized string that's attached to your account. Airdrop is fundamentally a way for you to share files across Apple devices -- so just give them new IDs.

Yes, this means that there's a tiny amount of coordination with Apple servers that would need to happen when you add a new contact or share with a brand new phone number you've never seen before, but is anyone on here seriously going to argue that's worse for privacy than essentially transmitting your phone number in the open every time you use AirDrop?

From later in the article:

> How does your friend know that the person requesting a password is you? Broadband BLE requests contain your data, namely, SHA256 hashes of your phone number, AppleID, and email.

There's a device with a screen, right in front of you, and the screen has to be visible for you to click the share button. Your friend also needs to be right next to you so that your phone's are close enough to connect over Bluetooth.

So pick one to two randomized dictionary words, display them on the screen, and just read that out loud to your friend as confirmation.

Is there something I'm misunderstanding about how these features work? The developers at Apple aren't dumb, so I'm assuming there's some good reason for needing to use a mobile number as a device ID for a proximity-based sharing service on a tightly-controlled device.


> Yes, this means that there's a tiny amount of coordination with Apple servers that would need to happen when you add a new contact or share with a brand new phone number you've never seen before,

I would just have hashes of all the numbers of all your contacts on both phones and if your hash sent over matches you have a contact. No need to phone home.


That’s exactly how it works currently, but 9 numbers isn’t enough entropy to protect against a brute force enumeration.


The system appears to have been architected for purely offline use and that constraint would need to be lifted - otherwise, I agree, whatever method is used to associate a phone number with iMessage could be used to issue an “Airdrop token” also.


> I can't think of any reason why this needs to be a hash of a phone number instead of a randomized string that's attached to your account.

That’s what came to mind to me when I read this article. iMessage already uses per-device public key encryption, it seems like per-device UUIDs hashed with the user<->user connection could be used to make the sniffed hashes non-reversible without knowing the UUIDs of the sharing phone and one of his contacts


Send nonce+hash(phonenumber+nonce)? Then recipient could just iterate over contacts and check if they get same hash for anyone. Expensive but works?

OR send (handshake) message encrypted with recipients phone number (put through KDF). Anyone knowing the recipient probably could be able to get your phone number, but that seems like an improvement?


The first approach protects against a global lookup table attack but doesn’t help with the root issue that a 10 digit phone number isn’t enough entropy and you could still brute force the number (depending on the hash algorithm) in seconds to hours.

The second approach isn’t how AirDrop works as a product: when you open the Share dialog, you see a list of eligible recipients (either people with open permissions OR you in their contacts list). The recipient is the one doing the identity check, so their phone number isn’t known upfront.


I'm unfamiliar with AirDrop, but is there any reason it _has_ to work with phone numbers? Would sending nonce+hash(AppleID+nonce) work? I suspect an email address would have significantly more entropy than a phone number (36^6 * 4 ~= 10^10, so six alphanumerics plus four common email domains has about the same entropy (assuming random distribution-you could make better guesses)).

One downside is that it may be make targeted attacks easier (if you can guess the approximate form of someone's email address, you can easily confirm it), but that doesn't seem like much of a leak if you can already guess sufficiently closely. Sending hash(nonce+AppleID+phone number) might be an option, but that feels more limiting.


The email address I use for Apple ID is not the same one my contacts would have.


> is there any reason it _has_ to work with phone numbers? Would sending nonce+hash(AppleID+nonce) work?

I would suggest it's because phone number is (should be) device specific, while AppleID's can be shared across devices. But now that I think about it, does anyone know if AirDrop works with iDevices that don't have a SIM? Such as the iPod Touch?


> does anyone know if AirDrop works with iDevices that don't have a SIM? Such as the iPod Touch?

Macs.


Doh. Of course. Thanks.



The constant stream of information broadcast on Bluetooth is a concern. But MAC addresses of Apple devices have been randomized for a long time. The device name is something that could be used as a fingerprint for a longer duration if it turns out to be unique. What are the other risks, from a tracking perspective, from this general information broadcast?


technical problems aside it’s not great to see how many people around us leave leave AirDrop on for everyone.

Sitting in a train or plane full of people means there’s usually 3-4 at least in range to randomly annoy with shared pictures or to force open a link in safari

works as intended I guess

sidenote: anyone know what limits there are on all things short range wireless? How many AirPods can reasonably work in a small area? How many Apple watches can unlock a mac wirelessly? How much AirDrop/short range device discovery can happen simultaneously?


On some morning flights I'd bet that close to half of the passengers are using some type of wireless noise cancelling headphones, and I have yet to notice any problems. So the bandwidth or noise doesn't seem to be an issue.


The title is a lie.

Checking the status of your phone or collecting your phone number is much different of collecting information for “what happens on your iPhone”. I am downvoting this.


I mean, fair enough. But all of these are highly local (and most require user interaction), meaning they're less of a privacy concern and more of a security concern for high-value targets. Localized phishing, mostly. Plus you can guard against them by turning off bluetooth.

Worth knowing about if you're somebody important, or manage security for someone who is, but pretty far from "Everyone Knows What Happens on Your iPhone".


The edge case would be a someone using these techniques on, say, an attractive woman three seats down on the train.

In addition, one (hypothetically) could use iOS state awareness in conjunction with other attack vectors to gain access: i.e., we have an attack vector to gain remote access, but it only works if the target device is unlocked.


Is this true on Android too? Can someone just lift your phone number via you merely having your Bluetooth/Wi-Fi/etc. running?


First off, "someone can lift your phone number via you merely having Bluetooth running" is entirely not true of this information leak.

The scope of this issue is that an unsalted SHA256 of your phone number is broadcast when you open the Share dialog with AirDrop and Bluetooth active. Your phone number is broadcast to determine whether the sending device is in the receiving device's contacts list.

The feature that causes this information leak (AirDrop) has no equivalent on stock Android, but hundreds of horrifyingly insecure apps exist to replicate it.

Google are introducing a similar feature (Fast Share) soon and we will see how it fares security wise.

This is an interesting cryptography question: how do you allow two mutually untrusted client devices to determine that they share a common secret, without disclosing the secret? And for bonus points, how do you allow this to happen without two-way communication?


> how do you allow two mutually untrusted client devices to determine that they share a common secret, without disclosing the secret?

Use a PAKE. Although I think they all require two-way communication.

https://en.wikipedia.org/wiki/Password-authenticated_key_agr...


>This is an interesting cryptography question

Is that a solved problem?


It sounds impossible for very-low-entropy secrets. Like just imagine if the secret is 1 bit. Anyone can pretend they have that 1 bit (since they can just try both possibilities), which would let them determine that's the same secret the other person has. The only solution would seem to be to stretch the entropy and make a brute-force enumeration slow.


Tangentially, on Android every app you have run at least once can know your phone number through standard APIs. On iOS, as far as I know and as far as I have observed, there is no API for that — apps have to ask the user what the devices' phone number is and trust that input. So Apple revealing phone numbers (through a rainbow table of hashes attack) in this AirDrop sharing scenario isn't congruent with its approach of not revealing phone numbers in other cases.


> Tangentially, on Android every app you have run at least once can know your phone number through standard APIs.

How would that work? As far as I'm aware an app either needs explicit permissions (READ_PHONE_STATE) or the user gets prompted when the app requests the phone number (as shown in https://android-developers.googleblog.com/2017/10/effective-...).


Any idea why this is flagged? I found the demos and the GitHub repo pretty interesting.


I didn’t flag but it’s obvious why: the title and introduction paragraph is comically misleading. Without the hyperbole it would be an interesting discovery, with the hyperbole it’s obnoxious fear mongering.


It got flagged for the title I think: https://news.ycombinator.com/item?id=20529383

Few hours later after flagging an admin has changed the title to the current one and un-flagged it. I just copy-pasted the title from the original one in the submisison without thinking much about it. In retrospect, the new title is much better.

Also as another commenter hinted, Apple has some very loyal fans.


> Any idea why this is flagged?

In my experience, anti-Apple sentiment tends to get either downvoted/flagged to oblivion or upvoted through the stratosphere. I suspect it's due to Apple being a particularly polarising firm: those who like it, love it, while those who dislike it, loathe it.


Are there any news from Apple's side?


md5 of a 10 digit phone number... classic noob mistake.


MAybe the IT community should be telling people the truth: smartphones are terminals to the worldwide network of hackers. There should be no expectation of real privacy. Encryption can temporarily obscure data, until it becomes obsolete.


The legal frameworks surrounding privacy all revolve heavily around "reasonable expectations of privacy". I can't be upset if someone learns salacious information from the street through an open window; but if I close the blinds and someone intentionally peeks through a crack, they are violating my expectation of privacy and potentially breaking a law, even though I failed to secure that privacy properly by covering every square inch of the window.

In some cases, it can be possible to use E2E encryption to create a secret that is functionally impossible to discover. But even in cases where digital security is flawed, vulnerable, or outsourced to a third party, it's still valuable to us from a legal standpoint to maintain social expectations of privacy.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: