
If You Can’t Break Crypto, Break the Client: Recovery of Plaintext iMessage Data - cgtyoder
http://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/
======
endymi0n
For the depressing truth on the crypto wars:
[https://news.ycombinator.com/item?id=7757978](https://news.ycombinator.com/item?id=7757978)
(Crypto won't save you either [PDF])

...or to paraphrase Jeff Atwood: "I love crypto, it tells me what part of the
system not to bother attacking"

~~~
egyptiankarim
That's my favorite quote from Atwood! People are so prone to forget that while
cryptographic algorithms are provably secure (under practical constraints) in
a mathematically rigorous way, their implementations are subject to all of the
shortcomings of any engineering practice. Makes quick work for an attacker
trying to figure out where to start.

~~~
adenadel
It's my understanding that most (all?) public key cryptographic algorithms
aren't provably secure, but are conjectured to be. They are reliant on some
problem being hard to solve (factoring of large integers, discrete log, etc.).

Something like a one time pad is provably secure, however.

~~~
swordswinger12
This is a common misconception. The _algorithm_ itself is provably secure, in
the sense that violating the stated security guarantees of the algorithm is
equivalent to solving a problem that's considered to be computationally
intractable. The only part that isn't 'provable' is the basic assumption that
the problem is intractable in the first place.

~~~
ZoF
Didn't you just agree with him but substitute 'hard to solve' with
'computationally intractable'?

Yes based on our understanding today these things are computationally
expensive (e.g not feasible), but they could theoretically be easy to crack
given a mathematical breakthrough.

Am I misunderstanding?

As the field of mathematics advances there's a chance that current crypto will
be broken. Why is this a misconception to point out?

Why is it not, on some level, conjecture to say these systems are secure?

~~~
thomasahle
What you are saying was true until this February when this paper came out
[https://eprint.iacr.org/2016/170](https://eprint.iacr.org/2016/170)

It hadn't been implemented yet I'm any practical crypto system that I know of,
buy it certainly seems like we are finally going to have actually, provably
hard problems to build out security om.

~~~
LeifCarrotson
I believe you made an unfortunate typo, substituting "probably" when you meant
"provably".

~~~
thomasahle
Even auto correct finds it surprising :-)

------
tlrobinson
The fake URL in a JavaScript comment in the the JavaScript URI is a hilarious
and neat trick.

    
    
        javascript://bishopfox.com/research?%0d%0aalert(1)
    

gets interpreted as:

    
    
        //bishopfox.com/research?
        alert(1)
    

Fortunately most browsers prevent you from pasting JavaScript URIs in the URL
bar these days.

It's a little surprising Apple overlooked not one but two fairly obvious major
holes: allowing JavaScript URIs, and the lack of same-origin policy. I wonder
how many other applications are similarly vulnerable.

~~~
moloch
Well the lack of SOP is by design, since it's not a browser visiting multiple
sites the idea of an "origin" doesn't always make sense. This is part of a
larger body of work we've been researching, we found much more than this one
(all known bugs have been patched, that's why we've been waiting to release
this). We'll be submitting the full body of work to DEFCON/Blackhat, and a few
other cons, hopefully we'll get accepted, be on the lookout if we do!

------
theseatoms
This is the article that years ago convinced me it's not worth obsessing about
my own technological privacy:
[http://www.gaudior.net/alma/johnny.pdf](http://www.gaudior.net/alma/johnny.pdf)

I despise the "if you have nothing to hide..." argument for the surveillance
state. And I argue against it every chance I get.

But, practically speaking, I _don 't_ have much to hide. I also realized that
one can draw _more_ attention to oneself by taking drastic measures to
preserve one's own privacy.

I know, citation needed... I believe FB (or a related party) released some
research about detecting "holes in the social network". Browser fingerprinting
is another front on which I've probably made myself more unique to trackers.

~~~
hockley
Don't we all want to hide our payment information when we buy stuff online?
Modern commerce is built on identity assertion and securing payments between
two parties over the wire.

~~~
theseatoms
No doubt. I'd prefer my information stay private. But that liability lies with
the party that loses my data.

------
TazeTSchnitzel
Apple use a web view for messages? I would've thought they'd use native UI. I
guess it's easier to handle text properly with HTML.

~~~
atomwaffel
Yes, surprisingly the OS X Messages app doesn't seem to share a lot of UI code
with the iOS version. You can easily tell that it's a simple WebView from the
way text selections behave.

~~~
91bananas
Meaning how you can select text across messages?

~~~
atomwaffel
Yes, that and how some of the whitespace between the messages gets selected as
well.

------
bengotow
Man, that's depressing. It's fairly easy to prevent this particular kind of
injection—you just have to add a Content Security Policy to the HTML page. The
appropriate value for web pages running from file://, with no expectation of
downloading and executing remote JavaScript is: `script-src 'self';`

Really sad to see that Apple is using embedded web views without these sort of
basic protections. I bet worse exploits than this are possible, given that
they probably expose parts of the ObjectiveC layer through the JavaScriptCore
bridge.

~~~
moloch
It gets even scarier with frameworks like nw.js where you can just execute
native code directly from the DOM.

------
tibbon
It looks like the code was pulled from Github

[https://github.com/BishopFox/cve-2016-1764](https://github.com/BishopFox/cve-2016-1764)

~~~
moloch
Sorry about the mix up, the code available here:
[https://github.com/moloch--/cve-2016-1764](https://github.com/moloch--/cve-2016-1764)

and here:
[https://github.com/BishopFox/cve-2016-1764](https://github.com/BishopFox/cve-2016-1764)

------
Capira
Simplified POC:

    
    
      javascript://%0aprompt()

~~~
moloch
You need the full a://a.a/%0a to match the URL pattern, but that's the jist of
it.

~~~
lukashed
I thought so too but a quick test showed that the code from Capira does indeed
work

~~~
zuck9
Where did you test it? In a VM?

If you have a Mac that's on OS X 10.11.3-, then you shouldn't be running
unpatched systems.

------
lukashed
Does anyone know how they managed to open the console / inspector inside
iMessage.app?

~~~
moloch
We used JSConsole and Weinre

JSConsole -[http://jsconsole.com/](http://jsconsole.com/) Weinre -
[https://people.apache.org/~pmuellr/weinre/docs/1.x/1.5.0/](https://people.apache.org/~pmuellr/weinre/docs/1.x/1.5.0/)

------
kuschku
We’ll see a lot more of this soon, considering more and more software is
moving to webkit UIs, often with similar flaws.

~~~
dmix
Implementing CSP and other mitigations for these types of same origin bypass
attacks is relatively easy. I'm shocked that Apple didn't check this. I
couldn't imagine Google ever making this mistake, their web security teams are
solid.

Apple really needs to invest heavily in bug bounties and internal security
audits. This is 101 type of stuff when implementing any user-controllable
embedded web content.

The bar should never be this low for critical OS apps like iMessage.

~~~
kuschku
> I couldn't imagine Google ever making this mistake, their web security teams
> are solid.

You haven’t seen their XML bugs in Google Toolbar’s web gallery in 2013, have
you? Full access to the whole file system _of their servers_ via XML includes.

A bunch of security researchers managed to dump /etc/passwd as a sample to get
the bug bounty.

Google’s security isn’t that much better either...

------
haddr
In case of Android what you only need is that your application can read
notifications (and has notifications/accessibility permissions). E.g. all
whatsapp messages go through it...

~~~
Mafana0
A typical fanboyism argument when one's favorite company screws up. Just
mention the other rivals and add zero insight into the original idea being
discussed.

> In case of Android what you only need is that your application can read
> notifications

This "only" is much harder to do than sending a Javascript URL.

------
dmh2000
that's pretty much the approach on all crypto. crack the implementation, not
the algorithm.

~~~
haddr
It's rather "steal the message after decrypted" scenario, rather than cracking
the implementation.

~~~
CiPHPerCoder
I think they were referencing, "Most crypto is bypassed rather than broken."

~~~
haddr
exactly

------
known
"Never do anything against conscience even if the state demands it."
\--Einstein

------
yalooze
I had a similar thought with WhatsApp's Signal announcement. I believe that on
iOS, by default all WhatsApp messages are backed up to iCloud Drive. So that
would seem to be an easier attack vector.

~~~
endymi0n
Not just the messages - the key too. Just imagine the outcry from someone
breaking his iPhone not being able to restore his messages because of the
introduction of end-to-end.

That way, you don't even have to attack WhatsApp itself and they have all the
plausible deniability they needed.

~~~
mtgx
Why would the key be backed up to iCloud? Do you have a source for this?

~~~
wyldfire
Does iOS have a way to designate parts of app data as
secret/transient/do_not_back_up? I suspect not.

EDIT: It appears that I was incorrect.

~~~
ctz
Yes, the NSURLIsExcludedFromBackupKey file property.

------
gravypod
This isn't the only thing you can do without breaking crypto. If exploits are
too hard because you are lazy like me: check out CreepyDOL.

