iOS 10: Security Weakness Discovered, Backup Passwords Much Easier to Break
blog.elcomsoft.com
blog.elcomsoft.com
One such lesson could be called the “Difference Between the Janitor and the Vice President,” and it’s a sermon Jobs delivers every time an executive reaches the VP level. Jobs imagines his garbage regularly not being emptied in his office, and when he asks the janitor why, he gets an excuse: The locks have been changed, and the janitor doesn’t have a key. This is an acceptable excuse coming from someone who empties trash bins for a living. The janitor gets to explain why something went wrong. Senior people do not. “When you’re the janitor,” Jobs has repeatedly told incoming VPs, “reasons matter.” He continues: “Somewhere between the janitor and the CEO, reasons stop mattering.” That “Rubicon,” he has said, “is crossed when you become a VP.”
It depends what kind of infrastructure you have.
Ideally there should be NO MANUAL STEPS between dev and production. This should not be any need for a person to remember that this data should be inserted for dev and removed before prod. Instead there should be something like a documented way to insert the data or not based on a configuration file that is different for dev and production.
Of course reaching that keeping that ideal requires discipline. And when you slip, it becomes easy to say, "That's QA's job." Over time QA's job will get harder and harder, and that is a guarantee of periodic slip-ups.
Authority for fixing this situation really is the job of someone VP or above. They need to decide whether to fix the process and change what a lot of people do, or accept the inevitable screw-ups as the right choice to maintain the current rate of development.
> Blameless post-mortems should be the industry standard.
Sure, often times there are multiple reasons why something isn't accomplished, something is broken, or something doesn't work as intended. But generally there is someone that's primarily responsible for the piece of code, be it a manager, engineer, etc. It does suck to be on the receiving end of it and if it's major enough you can be out of a job, but blame should be given to the responsible party/parties and the issue should be handled appropriately as it's more direct than what alternatively happens which is to passive-aggesively handle the situation. Plus, how you handle crises like production going down and being blamed for it say just as much about you as an engineer as does your code.
Essentially, I'm against being coddled as an adult. We're adults, someone fucked up and is responsible for it, they should be blamed and handle it, and handle it like an adult. I do think that handling that kind of situation as person on the giving end definitely requires tact, though.
The problem is deciding what is the actual goal of a post-mortem. Is it to fix the problem (and prevent it from happening again)? Or is it to figure out who is the person most to blame so that they can be punished. Because, honestly, you can't have it both ways.
Plus, who makes the final judgement as to the party to be blamed and based on what criteria? Is it QA for not catching the issue, is it the engineer for forgetting to remove some debug code, the tech arch for not properly ensuring there were systems in place to prevent it from occurring in production, the program manager for not pushing back on deadlines that were too aggressive, or the CEO for constantly pushing employees to prioritize revenue over product quality?
Plus, how you handle crises like production going down and being blamed for it say just as much about you as an engineer as does your code.
Or your willingness/ability to find a suitable scapegoat.
Should I consider myself lucky that all my bosses have had this mentality? Is ass-kicking actually more prevalent in the industry than rational correction?
I was actually surprised by the change of mindset this simple substitution made. Power of positive thinking, I guess...
The "file" column of the database is a binary plist encrypted with AES128-CBC using the first 16 bytes of SHA1(password||salt) as a key and 0,1,2,...,15 as a salt. So those columns could be used as an oracle to break the password, even if the hash were removed.
The data in the file column doesn't really need to be encrypted. It was unencrypted previously, contains file metadata, and a properly wrapped key for the file.
The cryptography on this is pretty shabby. Much more amateur than the existing / previous stuff surrounding the keybag in the backup (which uses PBKDF2). Not sure what happened here. (Why it was added, and why it wasn't vetted by their more knowledgeable engineers.)
Of course, with the paranoid hat on, if your task was to subvert the mechanism, this is probably exactly how you'd go about it - make it seem like an accident. Just like gotofail :)
Here you have a method that security experts tinkering with the betas knew of since probably last July. Everybody expected Apple to fix it in the GM, but it didn't happen. Now the cat's out of the bag with some deservedly good (and harmless) publicity for Elcomsoft and it's gonna be fixed in no time.
If we even want to give credit to the malicious actor hypothesis, what's the benefit for them? Accessing iOS 10 beta backups more easily for three months? Nah, I don't see that, not this time.
The goto fail looked very much like a bad code merge. (I actually had a similar issue with a duplicated line when merging changes two days ago.) It's impossible to know without reviewing their full source control history, but it seemed like a plausible mistake to me.
(Data source: writing my own code to decrypt the backups about a month ago, or rather adapting my previous implementation to the new backup format.)
Wonder how did that slip through
Is it already possible?...
It's obviously much faster to brute force SHA256(dictionary_word) than a 128-bit key.
Apple was previously using 10,000 rounds of SHA-1 (with PBKDF1) as a KDF. This is much slower than one round of SHA-2 they've switched to by orders of magnitude.
To brute force successfully SHA256, you don't necessarily need to brute force 2^256 possibilities, you need to brute force a much smaller list of likely passwords, and this might just be enough.
I don't know if iTunes uses a salt to encrypt the backup.
If it's just iTunes being crappy with iOS 10 backups, then reasonably this is an easy patch, correct? And the change is perhaps a bit more understandable (trying to improve performance of actions from the already bloated iTunes); it's not a good reason at all to weaken the encryption method, but it at least provides a plausible explanation that doesn't have government interests as an impetus.
Maybe it is time to take a step back and question to what extent it is wise to trust iTunes. Could the encryption not be handled on the device? Then when the PC/Mac is compromised the backup would be still safe.
(Though perhaps it ought not to.)
The way the article is worded makes me think that you wouldn't normally be able to use the token to get the data without this bug, which means that it can't be an iTunes issue.
Also, the fact that it's only iOS 10 implies the same.
If it's only related to iTunes then why does it only apply to iOS10?
It's a bit annoying considering macOS can also use FileVault for full-disk encryption, which helps if the machine is locked/off. I guess it doesn't help against your macOS user account being compromised via a browser or anything.
Makes me wonder if anyone has taken a fresh new look at the FDE passphrase algorithms in macOS 10.12...
https://en.wikipedia.org/wiki/Intel_Active_Management_Techno...
and its potential.
passwordHash == SHA256(password || salt)> An argument from authority (Latin: argumentum ad verecundiam), also called an appeal to authority, is a common type of argument which can be fallacious, such as when an authority is cited on a topic outside their area of expertise or when the authority cited is not a true expert.
https://en.m.wikipedia.org/wiki/Argument_from_authority
Calling it a fallacy when there's an actual authority is the part that's incorrect. It's no longer a fallacy when the appeal to authority (argument from authority) involves an actual authority.
If I have to go google who has written that article to blindly believe in it - that certainly reflects poorly on the article itself.
Several reasons. One of which would be to avoid using the article author's background as part of an argument against the content of the article. Because that would be an ad hominem.
Appeal to authority means accepting what an authority says on the merit of the entity being an authority, and not on the validity of the statement itself.
Re-read your wikipedia article...
"It's no longer a fallacy when the appeal to authority (argument from authority) involves an actual authority."
is not true.
The right thing to say would have been "It is no longer a fallacy when the authority making the claim provides enough convincing evidence to make the claim valid, with or without an authority", if that's indeed what you meant to say.
But that's not what you said, and so I stand by my assertion that what you said is not true.
We have the original post in this thread of interest saying (paraphrasing): "The article has no substance, so the claim is it making could be made by anyone. The article is not useful and the claim is not substantiated".
Then we have a reply: "Elcomsoft is an authority on the topic so their claim should be stronger than if anyone else made it".
This is where I said it looks close to an appeal to authority.
But you then came in and said "when there's an actual authority there is no longer an appeal to authority".
Which is not true.
I mean, how can there be an appeal to authority with no authority? That's like saying there's a car accident with no car.
iTunes is done by a different team than the OS. At one point at least much of the iTunes web side was handled by remote contractors, not sure of the app itself. Given that Apple is releasing 4 new OSs every year its not surprising something gets screwed up.
It will be fixed within a week I bet.
if time_since_last_attempt < 1 {
sleep(1)
}
key = sha256(password)
check(key)
The standard way to solve this is to use an inherently expensive process to turn the password into a key. In this case, it's something like:
tmp = password
for i in 0 to 10000 {
tmp = sha256(tmp)
}
check(tmp)
Another approach is to use attack-resistant hardware which won't run the attacker's code and which has access to some hidden data which can be mixed in, and can't (easily) be extracted from the hardware. Then it looks like:
if time_since_last_attempt < 1 {
sleep(1)
}
hash = sha256(password)
key = encrypt(hidden_data, hash)
check(key)
For example, this device, which was priced just 1300 USD tries
https://www.bitmaintech.com/productDetail.htm?pid=0002016091...
11.85T hashes per second, that's 1 with 13 zeroes per second and that shows what today is possible to achieve so cheap. Elcomsoft's software for previous, non-weak algorithm, managed to try 150000 passwords per second using the GPU, that is, this weakening is like giving an attacker some tens of thousands of computers for free, or tens of millions of computers for $1000.
See https://security.stackexchange.com/questions/62800/is-it-pos..., https://rya.nc/asic-cracking.html
1. wipe his previous ios10 backups
2. if the backup password is not significantly long, increase the length of his backup password with some random enough material.
And, of course, never forget that "$5 wrench" comics.
I still hope Apple will publicly respond on this. It simply doesn't fit with the other steps they did at least starting with iPhone 5s.
https://www.gnu.org/philosophy/free-software-even-more-impor...
Free software is not some magical silver bullet that makes your software impervious to bugs or mishandling.
Because an unprivileged account compromise could still get access to your backups in that case.
GPG or TrueCrypt-like would be the way to go there.
Perhaps not a full back door, but more of an open upstairs window?
Also Apple took a lot of heat from the FBI case, perhaps this was part of the deal for them to drop the suit, which isn't a blatant back door.
The proof will be in their response to the issue.
Given the other crap[1], relatively speaking they still shine though - at least a patch will be out soon to everyone that turns on their device.
[1] FCC should really look into making security updates for mobile devices mandatory with a time limit, in absence of which OEM or the Carrier must replace the device free of charge with one that doesn't have the vulnerability. It's criminal what OEMs and carriers are getting away with while making ton of profits.
Is this Apple's Bitlocker Elephant Diffuser?
Can I have some extrabacon with that?!
i dont even like apple but come on, the hyperbole can only go so far