Exploiting the Wi-Fi Stack on Apple Devices
googleprojectzero.blogspot.com
googleprojectzero.blogspot.com
Just writing the blog post and generating all the images for it must've taken many days.
The usage of source code and avoiding deep assembly documenting helped a lot. You are still looking at several man days of deep work on understanding the driver and stack.
KASLR was the only real mitigation to bypass. That could have been a difficult part worth it's own discussion. Bypassing ASLR typically requires an info leak.
I think 3-4 weeks of one person's effort is a good guess. +/- 1wk depending.
It looks pretty neat, conceptually. It loads the kernel into a random location in memory on boot. I haven't looked into how random it is, but it's a good idea.
>The exploit has been tested against the iPhone 7 running iOS 10.2 (14C92).
was because iOS 10.2 has a known kernel exploit developed by Ian Beer [1], and they used that as part of the basis of subsequent research. Presumably they either found some iPhones still running 10.2 (which stopped being signed a long while back) or like many well funded researches just keep a set of different iPhones loaded with major iOS versions so they're ready to go for research if an exploit is found after signing stops (dedicated jailbreakers sometimes to the same thing if they can). And of course security patches themselves are handy for reverse engineering old exploits from whatever bugs Apple fixes.
In part one read under "Kernel Memory Analysis Framework".
----
1: https://googleprojectzero.blogspot.co.uk/2017/04/exception-o...
I think the pertinent question is: why didn't they make the change more clear?
1. You're in a coffee shop. The WiFi sucks today. You turn off WiFi so you can use your cellular connection instead.
2. Many hours later, you go home, having forgotten about #1.
3. You binge-watch the entirety of Doctor Who streaming on your phone, not realizing the phone is still using cellular.
4. Large bill from your provider.
Reminds me of the time where I couldn't trust what the UI says about the audio of my desktop computer running Linux circa 2005
6. Get said subscription.
7. Stop worrying.
In any case, I'm not going to pay a bunch of extra money every month just in case I forget about the WiFi.
With 45GB you can watch a mere 10 hours of 4k TV per month.
Regardless, I think Apple could have come up with a more user-friendly solution. This just looks like a lazy hack to be honest.
Unfortunately, that still doesn't explain Apple's decision to make it harder to switch off WiFi. Do iPhone users simply not notice the status bar?
I'm lead to believe it's not iPhone users specifically, but people in general.
I've worked in IT, but qualified as a tradesmen nearly a decade before, and I occasionally forget to turn wifi back on when I get home. I currently work for a large steel fabrication company. One of the project managers here doesn't even use email.
It's way too easy for the average person to forget to turn wifi on and blow all your mobile data / get slogged with overage.
In a similar fashion, it's not hard to see and feel when a / the tyres on your car need a bit of air, but we mandate tyre pressure monitoring systems.
We are, for good or bad, reluctant to regulate software system. So, I guess, as always, if we think of a better design we should probably make a demo or promote it, maybe iOS / Android will pick it up along the way.
Llama on Android has been doing this for years, but the UX was a mess in my opinion. Apple could streamline the setup process, throw in some "amazing"s and "revolutionary"s, mix that with Touch/FaceID, and voila, you have a viable solution.
I didn't down vote you by the way.
The problem isn't that Apple made it hard to turn off WiFi, it's that they changed one of the controls without making it clear that it had changed.
On a 6s or newer, with 3D touch, you can cut it down to 2-3: unlock, force touch on Settings and toggle WiFi from the menu that appears. (That might be 1-2, I forget whether you can force touch and drag to what you want to activate, or whether it has to be a separate tap.)
Anyway, here's my count: 1. use touch-id to unlock the phone 2. press home to get to first screen with the settings app (if you aren't already) 3. tap Wifi 4. turn it off
You then need to navigate back to where you were previously.
What they instead achieved up to iOS 10 was:
* worse location data in maps * airdrop does not work * AirPlay might not work (doesn’t work across networks) * Handoff doesn’t work * phone call and sms forwarding doesn’t work * applications don’t auto update in background anymore * system updates are not downloaded in background anymore * might waste their data plan
I think it’s impossible to have people know and be aware of all these side effects. It’s much better to change the UI: have the common button do what people think of and know it does: get off a network. And have the more comprehensive shut down button a couple of taps deeper in settings.
This is how it was even before smartphones. Android keeps wifi location scanning and various other things running, even if you turn off wifi, so it actually accomplishes what people want: to turn off wifi networking until they turn it on again.
The change made in iOS 11 is a clear regression.
Now, whether they've done so correctly - both from the perspective of what actually happens, and how it is communicated to the user - that's certainly an issue and it's clear they haven't executed this well.
Maybe the reason people have trouble connecting cause and effect (if that's even true) is that UI designers keep lying to them about what their system is doing.
the other reasons you list are minor issues, who needs constant update possibilities, phone call forwarding to your Mac, airplay and handoff on the way? yes, I also forgot switch off wifi and burned through my volume, but we shouldn’t dumb systems down. People need to understand cause and effect, especially in IT.
Aren't they randomized now?
Not saying it wasn't something similar, but it could have been pretty different.
1. https://en.wikipedia.org/wiki/FBI–Apple_encryption_dispute
He talked quite a bit about what you can get off the devices, but not much on the how to get into there. Apparently Android-encrypted phones are the safest though. They didn't have an exploit for them 2 months ago.
That's odd. I guess the implication is that iPhone hsm is broken (or they can get past a short pin via an exploit that allows brute forcing - typically an hsm should (be possible to configure to) permanently destroy the keys after N attempts).
I suppose it demonstrates that secure encryption requires the user to memorise something equivalent of 96-128 bits of entropy, that will be used for key derivation.
[ed: i suppose it's conceivable that there's an attack against how the iPhone generates symmetric encryption keys, but I would guess that's less likely]
In the Android case, often times you need to power off the device to really be protected as the key is just sitting in RAM. But if you've got a powered off Android device that's been encrypted, chances are you have a good challenge on your hands - there's nothing but the encrypted data on disk to work with unless you were to go to an active attack.
I don't think there's any truth to this - if the crypto were weakened you'd see it broken by that quite quickly - but it's quite strong and follows well accepted stands in the cryptography community, have a look yourself if you like. It's using dm-crypt and dm-crypt is fairly heavily tested and reviewed. Debian and likely Purism use the exact same, so certainly wouldn't be any better in that way.
The iPhone encryption from San Bernardino had a 4-digit pin + a long salt, and the long salt is in the iPhones secure enclave. However, the phone would erase itself (don't know if it's the salt or erase everything) after 10 tries. If they were able to image the phone and get the long salt, the keyspace is only 10000, which is trivla to do on a cheap computer today. I believe you can input a long passphrase for iPhone security, and them you'd be back to the problem of a complex passphrase.
Android gives you the option to input a secure passphrase for key derivation, but you can also use a 4 digit PIN/similar non-secure passphrase, and be just as vulnerable. I am not as familiar with additional security measures Android has (I think it does have a similar measure where too many incorrect passphrases will cause it to erase itself).
They also had jailbreaks/exploits for 10.2 (or the latest version at ~2 months ago)
But until then Broadcom still has the best WiFi Chip. Qualcomm Atheros is a big no no.
Sarcasm? If not, care to elaborate?
If you think about it, pointing out flaws in competitors' products is actually unusual for businesses, especially large ones. It raises questions of motives, of trust (are they drumming up business in a negative way? Can I trust what company X says about their chief rival? Are they exaggerating or spinning it?), and it looks unsavory: You don't win in the court of public opinion by insulting the competition, right or wrong; you just look like a jerk. Also, there's a liability risk, which adds legal costs to otherwise free blog posts - 'can't you guys just find Linux bugs?'.
On the other hand, it might improve security for everyone if Apple and Google started competing to publicize each other's flaws. :) (But I'd bet the noise of accusations and counter-accusations of errors in analysis, misleading statements, etc. would soon drown out the technical info, and then the lawsuits would begin ...).
1. The Google Project Zero guys are idealists and motivated by increasing security.
2. Google security is taken far more seriously than most other companies
3. If Apple and Google competed in publicizing exploits, Google would win [is winning].
I don't think Project Zero ever analyzed something that isn't used at Google (for example with the Apple stuff: somebody at Google has to build the Google iOS apps). Wanting to know what's going on on the corporate network is the job of a corporation's IT security unit.
The publications serve to force vendors to fix their mess. Microsoft already complained that the 90 days limit by Project Zero is unfair (and got a 14 days-to-next-patchday extension). And there are other experiences from researchers adhering to "responsible disclosure" schemes where the vendor only became active once publication was a real threat.