iOS 10: Security Weakness Discovered, Backup Passwords Much Easier to Break

http://blog.elcomsoft.com/2016/09/ios-10-security-weakness-discovered-backup-passwords-much-easier-to-break/

by cpach • 10 years ago

220 91 10 years ago

blog.elcomsoft.com

0x04• 10 years ago

Why would apple implement a new weaker scheme in parallel to the existing old? Are the designers of the otherwise so secure enclave blundering? Or is this done on purpose?! (Hard to believe they would believe they would get away with it, so... amateur hour accident?)

Is this Apple's Bitlocker Elephant Diffuser?

Can I have some extrabacon with that?!

pervycreeper• 10 years ago

I think your second explanation goes a long way to explaining the whole San Bernadino iPhone 5c dog-and-pony-show that Apple put on early this year.

bsamuels• 10 years ago

yes, the company that went out of their way to fab their own soc JUST for encryption/improving device security purposefully degraded their password backup scheme to allow the government to break into their devices

i dont even like apple but come on, the hyperbole can only go so far

JohnStrange• 10 years ago

You do know that it was possible to get the FileVault password for other users with a simple grep command up until OS X 10.7, don't you?

jonathanstrange• 10 years ago

Probably just a secret deal with the DHS. Don't worry about it.

robmcm2• 10 years ago

Humm, a skeptical view of this would suggest deliberate weakening of security.

Perhaps not a full back door, but more of an open upstairs window?

sosborn• 10 years ago

Why does everything have to be a conspiracy?

croon• 10 years ago

Because people have faith in other people not being complete dullards.

robmcm2• 10 years ago

perhaps because the old API is still there? This appears to be a new less secure duplicate, with seemingly no benefit.

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.

shabbyrobe• 10 years ago

iOS 10 has felt pretty buggy to me. Lots of little glitches here and there. We are still trying to get some hard data on a sneaky problem with random dropouts when using BLE beacons. I'd say this is more likely to be more of the same than a conspiracy.

eklavya• 10 years ago

You could say that it's not as common a problem and could be missed. But what do you say when the push notification is not working well with the new hotness and there is no fix. You need to uninstall, restart, install until the next update of your app is released and then you have to repeat that.

https://forums.developer.apple.com/thread/49512

tetrep• 10 years ago

Some technical detail would be nice. At the moment, this is just an advertisement for their iPhone backup cracking software.

mkagenius2• 10 years ago

yup, literally anyone could claim that.. bad article

huhtenberg• 10 years ago

Elcomsoft is hardly "anyone" when it comes to this particular subject matter. You may want to look them up.

mrb2• 10 years ago

They did not just write an article, they also provide the brute forcing tool to prove their claims.

dchest• 10 years ago

Per Thorsheim says: "Apple have moved from pbkdf2(sha1) with 10K iterations to a plain sha256 hash with a single iteration only. Bruteforce with CPU!" https://twitter.com/thorsheim/status/779207177416351744

willvarfar• 10 years ago

Whaooo wtf? It is password 101 to use a password hash function to hash a password. This seems a very serious bug, by developers who ought know what they are doing :(

csydas• 10 years ago

Forgive my ignorance on the matter, but is this being handled by iTunes or by the Phone for encrypting the backups? Which element is actually at fault for the poorly protected backups?

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.

raverbashing2• 10 years ago

That will be a fun "git blame" (or equivalent) to make

Wonder how did that slip through

cvs268• 10 years ago

I didn't know we can brute-force SHA256 in a lifetime, yet.

Is it already possible?...

dunham2• 10 years ago

The PBKDF2 stuff is still there for the keybag, someone just added additional encryption (of the "file" column in that database - data that was previously unencrypted) with the same password using single iteration sha1.

(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.)

xnyhps2• 10 years ago

For me, Manifest.db inside the backup is a sqlite3 database containing a table Properties with two rows, salt and passwordHash, satisfying:

    passwordHash == SHA256(password || salt)

0x04• 10 years ago

If you are encrypting data, why would you store a hash of the key at all?

acqq5• 10 years ago

Until it get fixed (if), everybody who does the local backup and worries about its possible bruteforcing should

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.

pfg3• 10 years ago

The article seems to suggest that an attacker would be able to perform a (new) backup without unlocking the phone if they had access to a "pairing record from a trusted computer", which I assume means an iTunes installation that's paired with the phone. In other words, you might have to unpair the phone (or protect the iTunes installation with FDE) in addition to deleting any backups.

camillomiller6• 10 years ago

Ok, ELI5 for me please: how using a SHA256 function unsalted with 1 iteration - as suggested by Per Torsheim - would influence the fact that you can try more passwords per second? Isn't that a flaw of whatever kind of software password-trial limit more than a flaw of the algo used by iOS to encrypt the backup?

acqq5• 10 years ago

Because the SHA-generated value is available to any program which can employ all the cores of the CPU and all the cores of the GPU to try the generated passwords in parallel, and one try is very, very cheap for SHA, compared to the "serious" algorithms, plus, anybody can buy special SHA breaking devices which are built all the time.

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.

camillomiller6• 10 years ago

Geez... Thanks

ikeboy6• 10 years ago

AFAIK bitcoin miners can't be used to crack hashes.

See https://security.stackexchange.com/questions/62800/is-it-pos..., https://rya.nc/asic-cracking.html

koytch• 10 years ago

You can bruteforce unsalted hashes by using rainbow tables.

mikeash• 10 years ago

You can't (usually) force attackers to use your code when performing an attack on encrypted data they hold. You might try to rate-limit password attempts with something like:

    if time_since_last_attempt < 1 {
        sleep(1)
    }
    key = sha256(password)
    check(key)

But an attacker can just replicate the algorithm without the sleep call, since it's doesn't influence the actual process by which you obtain the encryption key from the password.

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)

Barring some breakthrough attack on SHA-256, an attacker must perform 10000 hashes for every attempt. If they don't, they won't derive the right key and they won't be able to decrypt the data.

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)

Since the attacker can't obtain hidden_data, they can't run this code on their own hardware. Since the hardware doesn't accept the attacker's code, the attacker can't remove the sleep. This is how the iPhone's Secure Enclave works, and a less sophisticated version of this is why the FBI had so much trouble getting into that iPhone a while back even though it only had a four-digit passcode set.

kondro• 10 years ago

Meh, my iTunes backups are stored encrypted at rest.

scott_karana• 10 years ago

Do you mean FDE?

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.

pearjuice2• 10 years ago

And this is something visible on the surface. Imagine what else they added. Or removed. This is exactly why you shouldn't trust proprietary software.

https://www.gnu.org/philosophy/free-software-even-more-impor...

yoz-y2• 10 years ago

I think that history has proven that being open source does not render you immune from bugs and security holes.

pearjuice2• 10 years ago

https://www.gnu.org/philosophy/free-software-for-freedom.htm...

coldcode• 10 years ago

Clearly they will tell Apple before publishing on their website. Then again they sell cracking software for money.

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.

joshstrange• 10 years ago

It will be interesting to see how they fix it, I'd guess it would have to be an iTunes and iOS fix because if it's only iTunes there is nothing stopping me from using an older version of iTunes to get a backup. You would need an iOS bump to force the user to upgrade to the newer iTunes before it would allow it backup.

camillomiller6• 10 years ago

Ok, I got it clearer: somebody at Apple fucked up and left a weak SHA256 Hash and salt inside a db table that shouldn't be there. Probably used in testing for the betas, then nobody remembered to comment it away before the public release. Some engineer and somebody in QA will get their ass kicked pretty badly. Next iOS public release will solve it, everybody's gonna be happy. Nothing to see here folks, we can move on :)

0x04• 10 years ago

That sounds maybe plausible, although what could they have possibly been debugging that required a weaker hash?

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 :)

camillomiller6• 10 years ago

Yeah, and hide it in plain sight. Plausible, yes. Although goto fail; had another vibe to it. It was really strangely placed and hardly explainable. Plus it made possible to perform some pretty nasty MiTM attacks over a network.

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.

brazzledazzle2• 10 years ago

I really wish the default response in dev and operations wasn't "somebody is going to get (yelled at|punished|fired|pile on layers of bureaucracy)". It would be so much better if the response was "how can we change automation in our release process to catch this and the engineer that did this is responsible for fixing it". Blameless post-mortems should be the industry standard.

camillomiller6• 10 years ago

Indeed, but this is a big "you should have gotten that in QA" kind of mistake. With the aggravating factor the the company markets security as one of iOS tentpoles... Accountability is a bitch, I guess, but in this case this was really in plain sight. I mean, it's not necessarily the dev's ass that's going to be kicked. There's a nice story about accountability at Apple once recalled in a profile by Adam Lashinski. It's from the Steve Jobs' era, but I guess this kind of policy is still enforced in Cupertino:

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.”

yladiz• 10 years ago

I want to preface this by saying that if this comes off as condescending that's not my intention.

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.

pkamb• 10 years ago

I've always thought that `git blame` was an overly negative / accusational term for the command.

AceJohnny22• 10 years ago

Reminds me of the story of a guy who makes a $50,000 mistake. He goes to his boss saying "So I expect you're going to fire me now" and the boss answers "Are you kidding? We just invested $50,000 in your training!"

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?

dunham2• 10 years ago

It's a little worse than that.

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.)

matco11• 10 years ago

Well... yes... just remember to securely delete that backup made with the current version of iOS10 from your computer, after you upgrade to next iOS public release... ;-)

blinkingled• 10 years ago

Reality continues to ruin Apple's marketing ;)

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.

djrogers• 10 years ago

The link makes it entirely unclear how this relates to decrypting the keychain. Yes, this makes it much easier to get access to the keychain, but isn't it also encrypted?

iOS 10: Security Weakness Discovered, Backup Passwords Much Easier to Break

Related Stories