4 ms·

In the second half of the post he suggests remotely determining an iDevice passcode was possible with his rate limit bypass. Essentially a salted version of the

by stirlo 5y ago

In the second half of the post he suggests remotely determining an iDevice passcode was possible with his rate limit bypass. Essentially a salted version of the devices passcode is uploaded to the apple server which he could then bypass the rate limit to brute force it. Isn't this a backdoor that would enable passcode bypass like was requested for the San Bernardino and Pensacola shooters phones? This vulnerability is a massive deal. With the passcode determined there's nothing stopping bad actors surreptitiously access your data. After all this a $2,180,000,000,000 market cap company offers a reward of $18,000. What a disgrace!

rubatuga 5y ago
Yeah, the “Your password is encrypted and cannot be read by Apple” is a bold faced lie. This can definitely be used to crack a passcode. Log out of iCloud if possible. I made a mini series on self hosting my cloud services here: https://www.naut.ca/blog/tag/shs/ https://www.naut.ca/blog/tag/shs/
- kevin_nisbet 5y ago
  I'm not sure it's really fair to say it's a bold faced lie. It's been awhile since I looked at SRP, but it looks like server side only require storage of Username, Salt, Verifier in it's database according to http://srp.stanford.edu/design.html http://srp.stanford.edu/design.html Unless I'm missing something this is really an artifact of allowing a user to use a short pin on the device, but also because this short pin is allowed to be used somehow as part of the password recovery flow which as such requires properties to prevent brute force. Unless I'm missing something, choosing an alphanumeric pin of sufficient length would avoid this and be difficult to brute force. So it would seem the guarentee's are weaker than expected due to this, but I doubt it's a bold faced lie. Unless I'm missing something of course.
  - marcan_42 5y ago
    The point is SRP is no different, in this context, from storing a standard password hash. You can brute force the passcode if you have access to the verification material on the server. Apple's device security model relies on rate- and attempt-limiting unlock attempts, so that people can in fact use short numeric passcodes. Their on-device model is carefully designed to make it very hard to bypass this. The problem is now they have extended that model and attack surface to their HSM clusters. That's 1) not Apple hardware (I trust Apple hardware more than I trust the third-party HSMs they use), 2) not (only) Apple code (again I have less trust in HSM frameworks than Apple's), 3) shared for many users, so break one HSM cluster and you get to bruteforce a lot of passcodes, 4) strangely not documented in Apple's Platform Security Guide, which is very suspicious.
  - aj3 5y ago
    I was expecting iPhones to generate public/private key pair and upload public part to the cloud during provisioning. That way you can securely prove you own the device but there’s no need to send password or anything derived from it to Apple.
    - kevin_nisbet 5y ago
      Yea, I think this missed expectation is valid, I certainly wouldn't have expected the pin code to be used as an authenticator on an internet facing API.
  - rorykoehler 5y ago
    I wish they allowed more technically proficient users to disable password recovery and manage iCloud backups off cloud.
marcan_42 5y ago
He is assuming that, because all the other endpoints had buggy rate-limits, this one would too, and they also fixed it. This is a bad assumption to make, because the device passcode recovery flow is going through an iCloud Keychain HSM cluster, which is a completely different implementation from everything else (which are just web services). In fact, it is well-documented that Apple cannot update the underlying code of their HSM clusters, as they destroy the management cards after initial provisioning. So they can't have actually fixed this bug if it existed prior to his report. That code was surely audited much more carefully, and depends on a much smaller technology stack, than all the web service stuff, and certainly handles rate-limiting within the HSM itself. So I have no reason to believe that this flow was vulnerable to the rate limit bypass race condition like the others. However, we have a different problem now. I called it the iCloud Keychain HSM cluster because, as documented, that whole thing is used for iCloud Keychain escrow (i.e. password store in the cloud). That's an opt-in feature. More info here: https://support.apple.com/guide/security/escrow-security-for-icloud-keychain-sec3e341e75d/web https://support.apple.com/guide/security/escrow-security-for... I did not know this, but apparently if your account has 2FA, the code used for this is indeed your device passcode, which smells dodgy to me: https://support.apple.com/en-am/guide/security/secdeb202947/1/web/1 https://support.apple.com/en-am/guide/security/secdeb202947/... But still, the context is iCloud Keychain. But now Apple are claiming this flow, which does not have the problem OP discovered, is used for all Apple accounts that have logged in from a passcode-protected iOS device. This implies that they are re-using this system, originally designed for the very narrow use case of (and trade-offs that necessarily come with) iCloud Keychain, as a general account recovery mechanism for all Apple accounts. That does, in fact, mean that they have (the ability to brute-force) the device passcode of everyone who has ever logged in their device. That's bad. The HSM cluster stuff makes this hard, but it is a huge change in attack surface. It means that your device data security now not only depends on on-device software and hardware design (and Apple are famously good at this), but also the security of an HSM cluster at Apple HQ. It means that if you manage to break into a given HSM cluster, you can then brute force the passcodes for all users managed by it. And it means that if the HSMs have a vulnerability, that is a massive liability. The HSMs are third-party, and I honestly trust HSM manufacturers much less than Apple themselves when it comes to building secure systems. So I would very much like to know what's going on here, whether that flow really does work on all accounts regardless of whether you use iCloud Keychain or not, and why none of this is documented in the Platform Security Guide. Does the hard 10-attempt limit used for iCloud Keychain escrow recovery also apply here, or can you continue trying PIN codes forever subject only to rate-limiting? Is this the same codebase or a different one? There are many questions here, and Apple's vague answers and lack of documentation for this make it sound like something very fishy is going on here.

by stirlo 5y ago

rubatuga 5y ago

Yeah, the “Your password is encrypted and cannot be read by Apple” is a bold faced lie. This can definitely be used to crack a passcode. Log out of iCloud if possible. I made a mini series on self hosting my cloud services here: https://www.naut.ca/blog/tag/shs/ https://www.naut.ca/blog/tag/shs/

kevin_nisbet 5y ago
I'm not sure it's really fair to say it's a bold faced lie. It's been awhile since I looked at SRP, but it looks like server side only require storage of Username, Salt, Verifier in it's database according to http://srp.stanford.edu/design.html http://srp.stanford.edu/design.html Unless I'm missing something this is really an artifact of allowing a user to use a short pin on the device, but also because this short pin is allowed to be used somehow as part of the password recovery flow which as such requires properties to prevent brute force. Unless I'm missing something, choosing an alphanumeric pin of sufficient length would avoid this and be difficult to brute force. So it would seem the guarentee's are weaker than expected due to this, but I doubt it's a bold faced lie. Unless I'm missing something of course.
- marcan_42 5y ago
  The point is SRP is no different, in this context, from storing a standard password hash. You can brute force the passcode if you have access to the verification material on the server. Apple's device security model relies on rate- and attempt-limiting unlock attempts, so that people can in fact use short numeric passcodes. Their on-device model is carefully designed to make it very hard to bypass this. The problem is now they have extended that model and attack surface to their HSM clusters. That's 1) not Apple hardware (I trust Apple hardware more than I trust the third-party HSMs they use), 2) not (only) Apple code (again I have less trust in HSM frameworks than Apple's), 3) shared for many users, so break one HSM cluster and you get to bruteforce a lot of passcodes, 4) strangely not documented in Apple's Platform Security Guide, which is very suspicious.
- aj3 5y ago
  I was expecting iPhones to generate public/private key pair and upload public part to the cloud during provisioning. That way you can securely prove you own the device but there’s no need to send password or anything derived from it to Apple.
  - kevin_nisbet 5y ago
    Yea, I think this missed expectation is valid, I certainly wouldn't have expected the pin code to be used as an authenticator on an internet facing API.
- rorykoehler 5y ago
  I wish they allowed more technically proficient users to disable password recovery and manage iCloud backups off cloud.

marcan_42 5y ago

He is assuming that, because all the other endpoints had buggy rate-limits, this one would too, and they also fixed it. This is a bad assumption to make, because the device passcode recovery flow is going through an iCloud Keychain HSM cluster, which is a completely different implementation from everything else (which are just web services). In fact, it is well-documented that Apple cannot update the underlying code of their HSM clusters, as they destroy the management cards after initial provisioning. So they can't have actually fixed this bug if it existed prior to his report. That code was surely audited much more carefully, and depends on a much smaller technology stack, than all the web service stuff, and certainly handles rate-limiting within the HSM itself. So I have no reason to believe that this flow was vulnerable to the rate limit bypass race condition like the others. However, we have a different problem now. I called it the iCloud Keychain HSM cluster because, as documented, that whole thing is used for iCloud Keychain escrow (i.e. password store in the cloud). That's an opt-in feature. More info here: https://support.apple.com/guide/security/escrow-security-for-icloud-keychain-sec3e341e75d/web https://support.apple.com/guide/security/escrow-security-for... I did not know this, but apparently if your account has 2FA, the code used for this is indeed your device passcode, which smells dodgy to me: https://support.apple.com/en-am/guide/security/secdeb202947/1/web/1 https://support.apple.com/en-am/guide/security/secdeb202947/... But still, the context is iCloud Keychain. But now Apple are claiming this flow, which does not have the problem OP discovered, is used for all Apple accounts that have logged in from a passcode-protected iOS device. This implies that they are re-using this system, originally designed for the very narrow use case of (and trade-offs that necessarily come with) iCloud Keychain, as a general account recovery mechanism for all Apple accounts. That does, in fact, mean that they have (the ability to brute-force) the device passcode of everyone who has ever logged in their device. That's bad. The HSM cluster stuff makes this hard, but it is a huge change in attack surface. It means that your device data security now not only depends on on-device software and hardware design (and Apple are famously good at this), but also the security of an HSM cluster at Apple HQ. It means that if you manage to break into a given HSM cluster, you can then brute force the passcodes for all users managed by it. And it means that if the HSMs have a vulnerability, that is a massive liability. The HSMs are third-party, and I honestly trust HSM manufacturers much less than Apple themselves when it comes to building secure systems. So I would very much like to know what's going on here, whether that flow really does work on all accounts regardless of whether you use iCloud Keychain or not, and why none of this is documented in the Platform Security Guide. Does the hard 10-attempt limit used for iCloud Keychain escrow recovery also apply here, or can you continue trying PIN codes forever subject only to rate-limiting? Is this the same codebase or a different one? There are many questions here, and Apple's vague answers and lack of documentation for this make it sound like something very fishy is going on here.