How the FBI Managed To Get Into the San Bernardino Shooter's iPhone (theverge.com) 94
A new report from The Washington Post reveals how the FBI gained access to an iPhone linked to the 2015 San Bernardino shooting. Apple refused to build a backdoor into the phone, citing the potential to undermine the security of hundreds of millions of Apple users, which kicked off a legal battle that only ended after the FBI successfully hacked the phone. Thanks to the Washington Post's report, we now know the methods the FBI used to get into the iPhone. Mitchell Clark summarizes the key findings via The Verge: The phone at the center of the fight was seized after its owner, Syed Rizwan Farook, perpetrated an attack that killed 14 people. The FBI attempted to get into the phone but was unable to due to the iOS 9 feature that would erase the phone after a certain number of failed password attempts. Apple attempted to help the FBI in other ways but refused to build a passcode bypass system for the bureau, saying that such a backdoor would permanently decrease the security of its phones. After the FBI announced that it had gained access to the phone, there were concerns that Apple's security could have been deeply compromised. But according to The Washington Post, the exploit was simple: [An Australian security firm called Azimuth Security] basically found a way to guess the passcode as many times as it wanted without erasing the phone, allowing the bureau to get into the phone in a matter of hours.
The technical details of how the auto-erase feature was bypassed are fascinating. The actual hacking was reportedly done by two Azimuth employees who gained access to the phone by exploiting a vulnerability in an upstream software module written by Mozilla. That code was reportedly used by Apple in iPhones to enable the use of accessories with the Lightning port. Once the hackers gained initial access, they were able to chain together two more exploits, which gave them full control over the main processor, allowing them to run their own code. After they had this power, they were able to write and test software that guessed every passcode combination, ignoring any other systems that would lock out or erase the phone. The exploit chain, from Lightning port to processor control, was named Condor. As with many exploits, though, it didn't last long. Mozilla reportedly fixed the Lightning port exploit a month or two later as part of a standard update, which was then adopted by the companies using the code, including Apple.
The technical details of how the auto-erase feature was bypassed are fascinating. The actual hacking was reportedly done by two Azimuth employees who gained access to the phone by exploiting a vulnerability in an upstream software module written by Mozilla. That code was reportedly used by Apple in iPhones to enable the use of accessories with the Lightning port. Once the hackers gained initial access, they were able to chain together two more exploits, which gave them full control over the main processor, allowing them to run their own code. After they had this power, they were able to write and test software that guessed every passcode combination, ignoring any other systems that would lock out or erase the phone. The exploit chain, from Lightning port to processor control, was named Condor. As with many exploits, though, it didn't last long. Mozilla reportedly fixed the Lightning port exploit a month or two later as part of a standard update, which was then adopted by the companies using the code, including Apple.
Apple and Privacy (Score:5, Interesting)
This story why I still favor Apple and iPhones over Android. One of the reasons anyway.
The FBI didn't just want Apple to unlock the phone as they and their lapdog press claimed. They wanted Apple to create a version of iOS that would bypass all security of all iPhones forever. Not even the media howling about Terrorism and how Apple was the bad guy for helping the Terrorist got them to cave, and I was impressed.
Re: (Score:3, Interesting)
So is this an older iPhone or are Apple lying?
For a number of years they are supposed to have been using a secure sub processor for the passcode, which should not be vulnerable to this kind of attack.
Re: (Score:3)
It's an iPhone 5C. As TFS notes, the shooting was in 2015. The shooter and his wife tossed their phones into a pond (IIRC, maybe it was a ditch or lake), committed their murders, and were shot to death by police in a shootout when the police tried to arrest them.
Re:Apple and Privacy (Score:5, Interesting)
The shooter and his wife tossed their phones into a pond
As far as I remember, he (didn't read about his wife) destroyed two Samsung phones, the hard drive of his Mac disappeared and was never found, and the iPhone, owned by his employer, was left untouched. Apple could have recovered some data in iCloud, but the FBI made a clumsy attempt to change the iCloud password which destroyed all access that Apple would have had.
The fact that the shooter left this iPhone untouched should have indicated that there was nothing of value on it, and that turned out to be the case in the end. So all the money that the FBI spent was wasted in the end.
Re: (Score:3)
The fact that the shooter left this iPhone untouched should have indicated that there was nothing of value on it, and that turned out to be the case in the end. So all the money that the FBI spent was wasted in the end.
And since the phone was owned by the Inland Regional Center, the Center should have had the phone properly managed, which would have given them admin control of the phone.
Re: Apple and Privacy (Score:2)
Re:Apple and Privacy (Score:5, Interesting)
Basically that. But it was a convenient omission by the FBI and President Trump in order to exert pressure on Apple. After all, the FBI has been complaining a lot about not being able to decrypt iPhones. Something they didn't have many problems with on Android which is why they never complained.
But the fact that the guy destroyed all the things that had real data on it, but not the iPhone (which belonged to his employer) indicates at least the guy was obeying proper OpSec - the iPhone was employer provided and not trusted, so it should not contain any data on it. Use it for work and that's it.
Of course, the FBI played it up like it could've had everything on it, even though destroyed hard drives and destroyed phones would've pointed to the fact that there was nothing valuable on it. At best, to a naive investigator, they'd spend all their time on breaking the phone and getting nothing while any other evidence rots away. It's like, destroyed phones, destroyed laptop, perfectly intact phone. Red herring material.
Considering you can securely erase an iPhone from the OS itself (it dumps the encryption key and regenerates a new one, as well as forces a reboot which would reset the memory encryption key and re-scramble both memory addresses and data), all evidence points to it not having any useful data on it.
Re: (Score:3)
Re: (Score:1)
The passcode on an iPhone is a numeric key of 4 to 6 digits.
If you can get past the limited attempt hurdle, a brute-force search is easy.
Many people use dates such as "200769" which have a much smaller search space than random attempts. At one attempt per second, you can often crack a code in a few hours.
Re: (Score:1)
The default passcode on an iPhone is a 6 digit number, I think (it's either 6 or 8). Back in 2015, it may have been 4. However, even back then you had the option of choosing to use a custom alphanumeric passcode of arbitrary length - which is what I've always done.
Re: (Score:2, Informative)
Actually, the passcode option has been around since iPhone OS 1.0 or so, and I think even then there was the option to use a password.
It's a really old option.
In fact, the encryption key used by the iPhone is easily crackable with a 4 digit PIN, w
Re: (Score:1)
Wonder what it was? 4321 LOL
Re: Apple and Privacy (Score:2)
Re:Apple and Privacy (Score:5, Informative)
Secure enclave was introduced on the iPhone 5S. Farook's phone was a 5C which was one generation older than that.
Re: (Score:2)
Thanks, that explains it. Good to know that so far the secure enclave seems to have remained fairly secure. I'm sure that will be of great comfort to the idiot who modded my post "flamebait" because the thought of Apple being less than magical upset them.
Re: (Score:2)
Re: (Score:1)
So is this an older iPhone or are Apple lying?
Obviously flamebait.
They have had the "Secure Enclave" processor for a while. As designed, it is unrelated to this kind of attack. There is a security feature on all newer iPhones that will erase the phone after ten unsuccessful attempts. The user can turn this on or off. With the feature turned off, the FBI could always do a million attempts if they wanted. And if you are very clumsy, or sometimes try to unlock your phone while drunk, you shouldn't turn this on.
This feature needs a _counter_ to erase
Re: (Score:1)
And it's 8 bit, so it would be impossible for Apple to implement "erase after 300 wrong passwords" using the counter in the Secure Enclave.
Even the original SEP was an ARMv7-A which was a 32-bit processor. Perhaps you're referring to the 2nd generation Secure Storage Component's counter lockboxes that have a 128-bit salt, a 128-bit passcode verifier, an 8-bit counter, and an 8-bit maximum attempt value? There's nothing preventing Apple from applying a signed firmware update to the SEP that expands and rewrites those values. But what would be the point? That's decreasing security.
Re:Apple and Privacy (Score:4, Interesting)
This feature needs a _counter_ to erase the content after 10 attempts. That counter wasn't sufficiently protected.
Yes, that's the point. In a reasonable implementation the counter would be in the secure enclave. But, as others have pointed out, the iPhone 5C didn't have a secure enclave processor; that was added in the 5S. Prior iPhones probably had a secure enclave in TrustZone, but they apparently didn't use RPMB (or similar) to protect the counter.
FWIW, Android devices have been required to have a sort of secure enclave since 2015 (many did earlier, but it wasn't mandatory), and to implement password checking with an RPMB-based counter -- and to increment the counter before checking the password, not after. Note that he result of too many consecutive failures on Android devices isn't to wipe the device (in most cases), but to require exponentially-increasing delays between allowed attempts, and the delay timing is also done in the secure environment, not by the main system. Many Android devices with a secure element do this in the secure element, including the delays. All Pixels have done so since the PIxel 2, and all Pixels since Pixel 2 have also implemented "insider attack resistance", which makes it impossible for Google to retroactively backdoor them the way the FBI wanted Apple to.
Re: (Score:1)
Re: (Score:2)
Alas, Android didn't require flash memory encryption until much later. If you wanted access to the data, the counter was useless - you'd just desolder the flash (around the time, eMMC) and then mount it in a jig and read it out.
Er... RPMB [westerndigital.com] has nothing to do with general device encryption. RPMB content isn't necessarily even encrypted, and there's absolutely no reason for the authn failure counter to be encrypted. The important thing about RPMB flash is that all reads and writes are authenticated. And, no, you can't work around it by desoldering and reading it out, because the eMMC/UFS chip with RPMB does the authentication checking itself. You can desolder it and try to read data out, but it won't respond if you can't apply the co
Re: Apple and Privacy (Score:1)
Besides the fact that it's an older model, the security processor itself can't a) wipe the whole phone and b) verify that it has actually been wiped (the memory module isn't lying to the processor).
Given physical access, skill, lots of time, and resources, any system can be hacked. For a skilled attacker with physical access and plenty of time, you can only make it *inconvenient* to access the data. You can't make it impossible.
For example, one could physically cut the Trace to the erase pin on the flash c
Re: (Score:1)
Given physical access, skill, lots of time, and resources, any system can be hacked.
Any system? Have you found a way to crack OTP encryption? If so, your Nobel Prize awaits. If not, maybe you shouldn't speak in absolutes.
Re: (Score:1)
For iPhones accepting updates, Apple has a bypass for all security on iPhones forever.
Re:Apple and Privacy (Score:4, Informative)
For iPhones accepting updates, Apple has a bypass for all security on iPhones forever.
I haven't seen an update yet that would be performed without me unlocking the phone and allowing it. And they couldn't unlock the phone without the passcode.
Re: (Score:3)
Re: Apple and Privacy (Score:2)
Which doesn't contradict my statement.
Re:Apple and Privacy (Score:5, Informative)
Firmware updates require user consent (with passcode), or DFU mode which wipes the device. USB access requires user consent for trust, or DFU mode which wipes the device. After the phone has been idle for a while, the USB port is disabled for accessories, and requires user consent to enable, except for DFU mode that wipes the device.
Plus, MDMs can disable USB access. Our corporate network does for anything that is missing a specific certificate that has to be installed on a computer running Apple Configurator 2.
If I want to update the firmware, I either have to do it online and provide user consent ... or enter DFU mode which wipes the device.
Re: Apple and Privacy (Score:1)
Re: (Score:3)
This story why I still favor Apple and iPhones over Android. One of the reasons anyway.
Google would have taken the same position as Apple, I think, had it been a Nexus/Pixel device. Of course, Google wouldn't have had any say if it were a non-Google device.
Also, this [googleblog.com].
Re: (Score:2)
Plus a president. You have to remember President Candidate Trump making a big deal about it, and
Re: (Score:2)
They wanted Apple to create a version of iOS that would bypass all security of all iPhones forever.
This statement is quite deceptive. While I have no doubt there were (and are) many high ranking people in the government that "want" that, but the actual lawsuit was to have the software locked just to the specific phone in question [link below].
It also sound like you might want to replace your media sources, I don't recall any news I saw try to paint Apple as the bad guy. Everything I saw either presented arguments for both sides, or favored Apple.
https://en.m.wikipedia.org/wik... [wikipedia.org]
Is there a reason they can't.. (Score:1)
Re: (Score:2)
Re: (Score:2)
By design biometrics time out after a while. You can change the setting under "Settings, Face ID and Passcode, Require Passcode..."
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Apple essentially requires a passcode, and requires the passcode to re-enable biometrics. Biometrics are useful in that if you are keeping your phone on you it will generally unlock the phone, but after a while (like an hour) you need the PIN again.
The whole idea is that if someone gets their hands on your device while its out of your control, they can't use cloned biometrics to break into it. It just happens that the same thing applies when the FBI dredges a lake. The odds of them finding the phone, and
Re: (Score:1)
Apple's Face ID requires you to actively look at the phone to unlock it. It won't work if the person is dead or asleep, or even looking in a different direction.
Re: (Score:1)
The TouchID sensor requires the skin touching it to have residual electricity that only exists while the person's alive. If that isn't actually a problem then the next issue is that once unlocked it has to be re-unlocked at least once an hour. Not terribly practical.
PIN usage has almost certainly gone up in light of the pandemic and masks obscuring the face.
Re: (Score:2)
The TouchID sensor requires the skin touching it to have residual electricity that only exists while the person's alive.
Not to get too ghoulish, but wouldn't a 9-volt battery (or similar, with appropriate modulation) be able to supply the appropriate amount of residual electricity as necessary?
Re: (Score:2)
How far you gonna go?
Re: (Score:1)
Re: (Score:2)
Dr. Frankenstein scoffs at your 9-volt battery. Puny!
Was it worth it? (Score:3, Interesting)
Re: (Score:1, Informative)
Per the report, nothing of relevance was found.
Re: (Score:2)
There wasn't.
Re: Was it worth it? (Score:3)
Wasn't it "Sieg Heil Trump"?
Re: (Score:3, Interesting)
They were crying wolf before they got it unlocked. They fumbled the iCloud unlock, which cut them off from a source of information Apple would have assisted them with, then tried a PR'ish stunt to shame Apple into doing their dirty work.
Since nobody seems to remember that, I'm worried it worked.
Re: (Score:2)
Re: Was it worth it? (Score:2)
Re: (Score:2)
Apple remembers. Slashdot remembers. The FBI remembers, too, but that don't mean diddly to them.
Re: (Score:2)
You didn't mean "decried", you meant "insisted".
Re:Bad Apple (Score:4, Interesting)
Again, as has been posted many times already, iOS is designed to not accept updates until the phone is unlocked. Even Apple themselves CAN'T push an update to an iPhone unless it is unlocked.
You're completely ignorant of how iOS works, so you automatically conclude that Apple is evil.
Re: Bad Apple (Score:2)
Well then the FBI willl push an update *before* catching a suspect the next time.
The suspet will do the unlocking and updating job for them.
Re: Bad Apple (Score:1)
Re: (Score:3)
So the FBI was asking Apple to push out an unlimited-retries update to all phones. So what?
No.
The FBI tried to compel Apple to use their expertise with the iPhone to write a software package to bypass the self-erase system.
Apple's response was that the FBI did not have the authority to compel them to work for the government. https://www.cbsnews.com/news/a... [cbsnews.com]
What the heck? (Score:3)
" After the FBI announced that it had gained access to the phone, there were concerns that Apple's security could have been deeply compromised."
Oh, is it not a deep compromise of how the phone works? Lets look at the next line:
"Azimuth Security basically found a way to guess the passcode as many times as it wanted without erasing the phone"
Ok, that is the deepest possible compromise. The security model of the iPhone uses all this fancy encryption, but it has a weakpoint: it needs to be accessible via a password. You can set a very secure passcode, but almost no one does, because your 50 character poem would take awhile to type every time you want access to the phone. Anything less than that is completely inadequate.
If you don't use a password of arbitrary length, then you have a 6 or 4 digit passcode. A 50+ character passphrase is actually secure against brute force. A 6 or 4 digit passcode is not.
So Apple's ENTIRE security model is to use hardware to prevent the mapping from "4 digit code" to "256 bit private key" to be undiscoverable to the attacker, while using software and hardware to fix the number of attempts allowed before the phone will destroy the private key.
So this means that Apple's security HAS been "deeply compromised".
Now, they've had time to fix this vulnerability. But this was high profile, and Apple took it on the chin. Most Apple fans are just happy that they tried, but honestly, why would anyone assume these are private? You'd need like 10 years of them actually working before you can assume you have a functional product.
Re: What the heck? (Score:2)
Re: (Score:2)
So eight digits takes about 3 months
Eight digits of what character set? Alpha? Alphanumeric?
I'm not coming up with the numbers you are, but I think it might be my maths. Can you show your calculations?
Re: (Score:3)
Get this into your ignorant clueless head: Apple COULD NOT unlock the phone.. They also COULD NOT push an update to gain access to the phone because any updates on iOS requires that the phone be unlocked, which defeats the purpose.
You're clearly just an Apple hater who, like most haters, as never used, never held in his hand, heck, probably never even SEEN an iPhone, or any other Apple product. There are many legitimate reasons to hate Apple as a company. No need to make up fake ones.
Re: (Score:2)
Please also explain how Apple can backup your supposedly totally un-decryptable by anything but your iPhone data.... but they can restore all your data to a new phone for you if your phone is stolen or destroyed...
I don't think they claim that iCloud storage adheres to the same protection as the handset. The device can (I'm not saying that it does) only protect data stored on itself.
Re: OK, then please explain... (Score:2)
Re: (Score:2)
Re: (Score:2)
Please also explain how Apple can backup your supposedly totally un-decryptable by anything but your iPhone data.... but they can restore all your data to a new phone for you if your phone is stolen or destroyed...
You mean IF you use iCloud backups? Otherwise 1) Apple cannot restore any data, and 2) the restore does not include anything that was only on the phone and not in the cloud. In this case, Apple instructed the FBI how to get the phone to backup to the cloud if it was turned on; the FBI royally screwed up by having one of their techs reset the iCloud password before syncing up with the phone.
Re: (Score:3, Insightful)
Actually, for people with some understanding of human history, that makes what Apple did even more moral, not less. You have obviously never heard of a slippery slope.
Re: (Score:2)
Grayshift tools (Score:4, Informative)
https://blog.malwarebytes.com/... [malwarebytes.com]
Theyre still selling this product. For the San bernadino tool the fbi payed 900,000.
IOS history (Score:4, Informative)
https://www.aimspress.com/file... [aimspress.com]
Morale: Do not trust guessable passwortds (Score:2)
As nobody competent will call hardware "tamper proof" these days (if somebody does, do not trust them), tamper resistance is all you get. And then it is essentially a question of effort invested. Eventually that may change, but at this time a password long enough to not be guessable and encryption with a key derived from that is the only somewhat secure solution.
Wich Mozilla library exactly? (Score:2)
Anyone got the name?
Re: (Score:2)
This iPhone was a 5c and therefore didn't contain all the fancy protection.
Essentially true (Score:2)
After the FBI announced that it had gained access to the phone, there were concerns that Apple's security could have been deeply compromised. But according to The Washington Post, the exploit was simple: [An Australian security firm called Azimuth Security] basically found a way to guess the passcode as many times as it wanted without erasing the phone, allowing the bureau to get into the phone in a matter of hours.
That really is a deep compromise of Apple's security. Reducing password guess attempts is a key part of that.
There is ALWAYS a weak point (Score:2)
Some security mechanisms are more secure than others. But security is complex, there is always some weakness somewhere, if the attacker is determined enough. If the FBI wants into your device badly enough, they'll get in.
Still, this does not make securing your device useless. The FBI (or nation states, or other wealthy attackers) is rarely interested in spending the kind of money and time it takes to defeat a secured system. Even minimal security is better than none.
simulators (Score:2)
consider.
make a digital copy of the iphone.
simulate entering password input using a rainbow file.
profit
Re: simulators (Score:2)