
iOS 10: Security Weakness Discovered, Backup Passwords Much Easier to Break - cpach
http://blog.elcomsoft.com/2016/09/ios-10-security-weakness-discovered-backup-passwords-much-easier-to-break/
======
camillomiller
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 :)

~~~
brazzledazzle
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.

~~~
yladiz
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.

~~~
Goronmon
_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._

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.

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

~~~
dchest
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](https://twitter.com/thorsheim/status/779207177416351744)

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

Is it already possible?...

~~~
Quiark
If you only try the passwords that people are likely to use then... Yes

~~~
brazzledazzle
Would using a bunch of previous password leaks to create a rainbow table be
useful for programs that do this? With the number of leaks it seems like it
would be a pretty accurate depiction of how a lot of people choose passwords.

~~~
iancarroll
Yes. However, rainbow tables are trivially mitigated with a random salt, which
requires you to regenerate your table for every hash.

I don't know if iTunes uses a salt to encrypt the backup.

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

------
camillomiller
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?

~~~
acqq
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...](https://www.bitmaintech.com/productDetail.htm?pid=00020160912073506474G9tUPWlH069D)

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.

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

See [https://security.stackexchange.com/questions/62800/is-it-
pos...](https://security.stackexchange.com/questions/62800/is-it-possible-to-
use-bitcoin-miners-to-decrypt-files-communication), [https://rya.nc/asic-
cracking.html](https://rya.nc/asic-cracking.html)

~~~
acqq
If the hash is SHA256 they can, read your links.

~~~
ikeboy
Sorry, the second link has better info on exactly why it won't work directly.

~~~
acqq
Thanks. Yes, I agree completely, when it's "directly." The mining devices
aren't designed specifically to crack the passwords, but the solutions have
the raw processing power and use the same hash algorithm, it's just that
somebody would have to adapt the chips for that given task, and for that he
could keep most of what's already optimized, namely the fast SHA256
calculations in hardware. It won't be particularly hard to adapt some current
solution, and the known speed benefit and power use would approximately
remain.

~~~
ikeboy
I think you'd need to design your own hardware, since the algorithm is
hardcoded into these. And once you're doing that you'd lose the economy of
scale that bitmain has.

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

~~~
pfg
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.

------
pearjuice
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...](https://www.gnu.org/philosophy/free-software-even-more-
important.en.html)

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

~~~
pearjuice
[https://www.gnu.org/philosophy/free-software-for-
freedom.htm...](https://www.gnu.org/philosophy/free-software-for-freedom.html)

~~~
yoz-y
My bad, I should have said that "I think that history has proven that being
open source or free software does not render you immune from bugs and security
holes."

Free software is not some magical silver bullet that makes your software
impervious to bugs or mishandling.

------
djrogers
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?

------
kondro
Meh, my iTunes backups are stored encrypted at rest.

~~~
scott_karana
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.

------
robmcm
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
Why does everything have to be a conspiracy?

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

~~~
kalleboo
That doesn't work either because Apple would have to be complete dullards to
not realize that someone would found this obvious flaw within a week of the
release of the OS. Especially right after launching a bug bounty.

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

------
0x0
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?!

~~~
bsamuels
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
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?

~~~
tptacek
You do know that if you can run commands on someone's machine, FileVault has
already failed to protect them, right?

