Apple bleee. Everyone knows what’s on your iPhone (2020)(hexway.io)
hexway.io
Apple bleee. Everyone knows what’s on your iPhone (2020)
https://hexway.io/research/apple-bleee/
14 comments
While the article is full of great insight into the features stated, the title is clickbait and doesn't match the content at all.
The title seemed to match the content pretty well based on my reading.
You can get personally identifiable info from an iPhone pretty easily given the methods described
You can get personally identifiable info from an iPhone pretty easily given the methods described
If I am understanding the article correctly, this is unpatched and apple haven't even had any warning as they've not disclosed any of this as they didn't consider it a vulnerability (I think I would disagree but haven't fully digested the article)
Edit - it's 3 years old I'm guessing they have made some changes since
Edit - it's 3 years old I'm guessing they have made some changes since
> …[Apple] they didn't consider it a vulnerability…
Neither does the author, seemingly: "This behavior is more a feature of the work of the ecosystem than vulnerability."
Neither does the author, seemingly: "This behavior is more a feature of the work of the ecosystem than vulnerability."
Yes by they I meant the author, I would consider it information disclosure, this data is meant to be private and the designers have made an attempt to keep it that way.
The article is from 2020 so I’m curious: how much of this is still valid today?
Especially:
> Broadband BLE requests contain your data, namely, SHA256 hashes of your phone number, AppleID, and email. Only the first 3 bytes of the hashes are sent, but that's enough to identify your phone number
Is that a viable way of accessing someone’s phone number in 2023?
Especially:
> Broadband BLE requests contain your data, namely, SHA256 hashes of your phone number, AppleID, and email. Only the first 3 bytes of the hashes are sent, but that's enough to identify your phone number
Is that a viable way of accessing someone’s phone number in 2023?
It's doable. Out of 100 million numbers here in Spain and 16 million possible 3-byte hashes, there will be 6 possible numbers for each 3-byte hash on average. That's low enough for trial and error.
Yes. Brute forcing it takes at most a few seconds on modern consumer hardware. Probably under a second, tbh.
There's always a hard balance to strike between security and usability, and it's impossible to get right. It seems that it's less Apple and more Bluetooth that the author is concerned about, and simply turning it off will prevent every issue listed. (And given the point of Bluetooth is to connect with devices around you, it seems reasonable to assume that people with it on would like these connections to happen.)
That being said, Apple does have modes which disable these features for people who are worried, including their Lockdown Mode: https://support.apple.com/en-by/guide/personal-safety/ipsd5b...
That being said, Apple does have modes which disable these features for people who are worried, including their Lockdown Mode: https://support.apple.com/en-by/guide/personal-safety/ipsd5b...
> Well, AirDrop seems to be less anonymous than we thought. It's possible to identify you: your phone sends out SHA256 your phone number hash to all the devices around you every time you hit Share.
It's wild that this hash isn't salted.
It's wild that this hash isn't salted.
Either the salt has to be static for all phones in the area, or it has to be calculable, which in the end is pretty much the same as it is now.
How would salting work in this scenario? Both devices would have to share the salt, wouldn’t they?
You broadcast salt || SHA256(phone number || salt). If you know the original phone number, you can check whether it's a match.
And if you don’t know the phone number you can brute force that pretty easily and it’s all the same. How many bits of enthropy are there on phone numbers?
[deleted]
All it does is marginally increase the cost of reverse engineering the sha2. Instead of having a rainbow table of every phone number’s salt, you generate one with that salt whenever you want to get the phone number it broadcasted.
Yeah and you probably won't even need to rainbow that because it's a pretty quick operation on a decent GPU. For example here in Spain we have only 100 million mobile numbers. That sounds like a lot but it's peanuts for a gpu. Going through the entire keyspace would take a fraction of a second because my 4090 can do 20 billion salted SHA256 hashes per second!
This doesn't seem any more secure than broadcasting SHA256(phone number).
The phone number part seems inexcusable but isn’t everything else pretty much necessary for a wireless data protocol like Bluetooth to work?
Surprising that Apple can devise an authentication method for the battery that is strong enough to prevent all 3rd party phone repairs whatsoever, but when it comes to wirelessly authenticating another iPhone for purposes of deciding whether to share or not your Wi-Fi password, then there's no check whatsoever...
I wish there was an Android app that emulated all these weird Apple ecosystem BLE handshake things. They're kinda nifty.
Turn off airdrop for non contacts? Turn off airdrop? Pretty misleading of them saying every time you click share instead of share with airdrop everyone can see some info.
My guess is that the SHA2 of the phone number is used for exactly this feature, so you can accept connections from your contacts only (your iPhone most likely already has a SHA2 calculatedfor each contact phone number) and ignore the rest.
Your phone will probably broadcast its hash in that scenario too.
Your phone will probably broadcast its hash in that scenario too.
Yes, very much so. It is also a mass generalization and a complete falsehood when the author makes bold claims like "Gen Z is using AirDrop to cheat". But they seem completely fine with their extremely generous claims.
I wonder if there have been any changes to this default behavior in the 5 years since.
Why is this flagged?
Voicing my suspicion will get ny comment flagged as well I suspect, but consider the HN reader base, what they get paid to do, and come to your own biased conclusions like I did. Many here feel that an attack on 'free' data, or a top tech company, is an attack on their livelyhood, and they are correct. Also the article is a bit overblown in many aspects which gives the clickbait anger response. Both, I feel, are valid reasons to flag this, even if I personally think many points in the post remain relevant.
[deleted]
Wow, not salting the phone number before hashing it was a pretty amateur move. Whoever did that made other mistakes... bank on it.
Assuming that there's some functionality by which if you know someone's phone number, you can identify them in some UI, how would you salt this?
Do you salt all the phone numbers with the same salt? Do you send out the salt and expect phones to respond with the salted hashes (in which case, how does this achieve anything?). Do you salt based on geographic location? (Again...) Do you make every phone use the same salt and try to hide it?
Do you salt all the phone numbers with the same salt? Do you send out the salt and expect phones to respond with the salted hashes (in which case, how does this achieve anything?). Do you salt based on geographic location? (Again...) Do you make every phone use the same salt and try to hide it?
What would salting do? The sender would need to share the salt anyway. I guess it would eliminate a database of number hashes approach but brute forcing a salted phone number hash should not be a big problem in any case.
Salting would prevent an attacker from being able to find your phone number by hashing every possible phone number in your area code and comparing each hash with what they captured over the air.
Or am I misunderstanding something?
Or am I misunderstanding something?
SHA-256 is designed to be quick to compute, so with salt and maybe some guessing of area code the march can be found within seconds. For salt to make a difference they’d need to use some intentionally slow hash functions, like bcrypt.
Not really. As the salt is known, they can still do this easily. They just can't make a rainbow table of it. That's the only thing salting really accomplishes.
You're overestimating how long it takes to brute force SHA256 all 10 digit phone numbers from scratch.
Just out of curiousity, took a look at some benchmarks and apparently a M2 macbook pro can hit 300MH/s easily. That would mean something like 30 seconds to hash the entire search space. I guess specilaized GPU implementations can do a lot better.
Take this with a grain of salt though, I did not test the speed claim myself.
Take this with a grain of salt though, I did not test the speed claim myself.
You're overestimating how long it takes to brute force SHA256 all 10 digit phone numbers from scratch.
Oooookay. I'll show myself out.
/s
Oooookay. I'll show myself out.
/s
Not sure why the sarcasm.
Security should not be implemented by anyone who is not a subject matter.
It's a subject where it's easy to sound informed while being completely wrong.
I'm of the opinion this should be a development interview question.
"How would you implement {security solution} from scratch" -- The only acceptable answer being refusal.
Security should not be implemented by anyone who is not a subject matter.
It's a subject where it's easy to sound informed while being completely wrong.
I'm of the opinion this should be a development interview question.
"How would you implement {security solution} from scratch" -- The only acceptable answer being refusal.