Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CryptoCat iOS Application Penetration Test [pdf]

isecpartners.github.io

Post reply on HN
Print view View original

51–60 of 137 posts

Re: CryptoCat iOS Application Penetration Test [pdf]

#51

Post by tptacek »

dfc wrote: post #46
tptacek wrote: post #26

Earlier quoted context omitted.

Was it commissioned by you? The audit I saw had the Open Technology Fund's logo on it. OTF is a US Government effort driven by Radio Free Asia and the Broadcast Board of Governors. OTF, again (smartly) using US taxpayer dollars, funds audits of a variety of privacy technologies. For instance, they also funded a good-sized chunk of the Truecrypt audit.

It is nice that OTF is funding audits and releasing the reports. It is too bad we can not find out more info on the mythic SJCL audit.

I agree; the work Dan Meredith at OTF is doing is truly impressive.

Re: CryptoCat iOS Application Penetration Test [pdf]

#52

Post by anologwintermut »

kaeporan wrote: post #14
primitivesuave wrote: post #12

This is most alarming. CryptoCat's OTR implementation on all platforms allows a chat peer to change their OTR key during a chat session without user notification. An attacker performing a man-in-the-middle attack against the client's XMPP or HTTPS stream can inject their own OTR key in the discussion after a user has authenticated their peer's OTR fingerprint. This permits the attacker to decrypt all messages that foll…

Fixes and improvements to this, and more, are covered in our blog post. I strongly urge you to read it. This audit alone doesn't give enough context. https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp...

What's your fix for the man-in-the-middle attack on all platforms (including deployed ones) the audit identifies and your blog acknowledges?

In your blog post there seems to be little context that can excuse such a mistake and nothing that explains how you fix it? Am I correct in reading your blog post that right now there isn't a fix? I.e. it's an open attack assuming someone compromises a CA or a cryptocat server?

Isn't this a rather big issue since the only point of cryptocat is to protect against that kind of an attack. If you just wanted security only against eavesdroppers(i.e. you trusted the chat server), xmpp over TLS would work fine.

Re: CryptoCat iOS Application Penetration Test [pdf]

#54

Post by tptacek »

kaeporan wrote: post #8
natdempk wrote: post #5

Also of interest is their blog post about how they plan to handle the issues described in this report: https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp... Reading that, I still am not sure why anyone would use CryptoCat especially with things like TextSecure on the market that seem to take crypto far more seriously. The only reason I can see for that is that they have clients on more platforms, but if thi…

Thanks for linking to the blog post. This audit concerns a pre-release version of Cryptocat for iPhone. Many of the bugs were due to debugging code and were fixed before release.

Which of the bugs were due to debugging code?

Re: CryptoCat iOS Application Penetration Test [pdf]

#55

Post by tptacek »

schoen wrote: post #41
scott_s wrote: post #17

Earlier quoted context omitted.

Long-time HN member tptacek's company has a challenge set that many praise highly: http://www.matasano.com/articles/crypto-challenges/

Are the Matasano crypto challenges currently stuck in some way, like with a grading backlog? I signed up some months ago, sent my first set of answers just after the new year, and have never heard back about the second challenge set.

We are way. way. way. backlogged.

If anyone has any idea on how to help a hapless team of security researchers manage many thousands of people looking to get through the crypto challenges, we'd be t-h-r-i-l-l-e-d.

We were able to keep up last summer, but then Microcorruption happened, we got into a hole, and we're only slowly digging ourselves out of it.

Alex, Sean, and I are turning the challenges into a book, which we're going to release "choose-your-price" with all funds directly going to a charity (I like Watsi, but who knows); that book will also include Set 8, which is all ECC.

I'm hoping we'll be done with that by August.

Re: CryptoCat iOS Application Penetration Test [pdf]

#56

Post by ris »

Wintamute wrote: post #38

@secalex Dumb post man. Way to de-contextualise something, cause a drama and damage reputations needlessly.

Reputations? What reputations, exactly? The only reputation CryptoCat developers have is for writing incredibly poorly thought out software full of holes. Combined with their taste for publicity I would rather call them a public menace.

Re: CryptoCat iOS Application Penetration Test [pdf]

#57

Post by jnbiche »

Wow, remind me to never have an audit done by iSec. "Extremely thorough" would have been tough but appropriate, but "brutal" seems just gratuitously provocative. Was that what you were going for?

Edit: OK, apologies to iSec for my mistake. I thought he was still affiliated with them. In any case, it looks like a top-notch report, so it would have been a shame to detract from that accomplishment.

Re: CryptoCat iOS Application Penetration Test [pdf]

#59

Post by tptacek »

jnbiche wrote: post #57

Wow, remind me to never have an audit done by iSec. "Extremely thorough" would have been tough but appropriate, but "brutal" seems just gratuitously provocative. Was that what you were going for? Edit: OK, apologies to iSec for my mistake. I thought he was still affiliated with them. In any case, it looks like a top-notch report, so it would have been a shame to detract from that accomplishment.

Alex (the submitter) doesn't work for iSEC; he's the CISO of Yahoo now. He left iSEC last year to start Artemis.

I agree that the title is bad, and (belatedly) asked 'dang to revert it.

Re: CryptoCat iOS Application Penetration Test [pdf]

#60

Post by pilif »

teacup50 wrote: post #40
smcgregor wrote: post #30

Earlier quoted context omitted.

I don't think CryptoCat has been distributed as a traditional web app for at least a year (probably more). The browser code is distributed as an extension, which does not have the properties you describe. edit for sub-comment: A traditional web app updates every time you hit the URL. In a browser extension your code is not necessarily tied to any remote origin, including the Chrome/Firefox stores. It is a user's choi…

> The browser code is distributed as an extension, which does not have the properties you describe. Actually, browser extensions have the exact same properties except for being code signed. That's not enough: http://arstechnica.com/security/2014/01/malware-vendors-buy-... > I don't think CryptoCat has been distributed as a traditional web app for at least a year (probably more). That they ever shipped in-browser cryp…

Malicious people buying extensions and then malwareing it is as likely or not as malicious people buying the vendor of whatever tool you are using on the desktop once its auto-updating feature is good enough (that would actually be slightly worse, because in the case if the extension you at least get to read what's actually executed).

What you are saying is that you don't trust any kind of application to do crypto unless you have previously audited it. That's a reasonable stance to take but it's irrelevant whether you distrust a third-party browser extension or a third-party native app.

The main argument against crypto in JS extensions is that getting crypto correct in regards to timing based side-channel attacks is very hard to impossible.

But if you are dealing with a specific browser in an extension context, this might be somewhat mitigated which would bring us back to the trust issue, which, again, IMHO is not dependent on the platform you use

Post reply on HN