[marcan_42]

He claims the vulnerability as originally reported could take over any iCloud account. Apple claimed otherwise. We do not have hard evidence from either side.

However, given the implementation involved, I think Apple's claims are more likely, as I detail here; OP is assuming the stack used for the passcode recovery is likely vulnerable because the others were, while we know it is a completely different validation technology and, given how it works, I would expect it not to be vulnerable (unlike the web service stuff): https://news.ycombinator.com/item?id=27567730

My take on this is:

1) Apple are probably not lying when they say this wouldn't have worked on most accounts.

2) The author is likely wrong in his assumption that the passcode flow was vulnerable like the others were.

3) $18k is still way too low for an account takeover exploit that only affected a subset of accounts.

4) Apple are not being open about how this system works, and if I'm not mistaken, this is a new system/flow.

5) The author's discoveries aside, Apple need to document how this works, because as far as I can tell they are massively increasing the attack surface for the data security of iOS users who log in to their Apple accounts on-device, using a new, undocumented mechanism/use case.

[cantsingh]

You seem to have a lot of knowledge on this, so apologies if I am misunderstanding, but aren't you still overlooking the fact that that for iCloud accounts that hadn't been used on Apple devices (even if it was a small subset of devices), he was able to reset the provided password via concurrent brute-forcing the OTP endpoint?

Isn't that alone sufficient to demonstrate complete iCloud account takeover?

Agreed that this should not be taken as proof that the other reset flow was not vulnerable, but to me it seems like two separate issues.

[marcan_42]

It is two separate issues; as I said, I think $18k is way too low for a subset of accounts takeover. Personally, I'd have awarded the full amount.

[Terretta]

In each disputed area you suggest it’s “likely” Apple is right.

In my experience, security engineers, even Apple security engineers, have the same very human kind of “can’t see my own typos” bias as the rest of us.

In my experience, fresh eyes looking from a different perspective are more likely to be right. (Part of why pen testing and security researchers are a thing.)

[marcan_42]

I watched the Apple presentation on the iCloud Keychain implementation. They explicitly mentioned concurrency and having a consensus algorithm that forbids conflicting mutations on an escrow record.

I've written web apps, and I've written embedded security code. It's a lot easier to screw up and have a race condition in rate limiting code in a web stack than in a carefully designed HSM consensus algorithm (especially since the latter kind of depends on this being handled properly for data correctness, not just defending against attacks).