What I’m reading is that you did the right thing and tried to responsibly disclose, and you were screwed out of your rightful bounty.
Hopefully, you’ll reconsider using Zerodium or other private bugreporting, since they will make those offers and do so in good faith.
Well, you know, Apple is a small mom-and-pop operation and it’d be really hard to afford to honor their commitments…
The second vulnerability is particularly curious because someone obviously thought a lot about how to implement this crypto scheme, but for some reason didn’t use the Secure Element. Every supported iOS device and more recent Macs have a separate chip that can handle secure key storage and operations and provides functionality similar to a TPM to the OS. If any step of that process had a mechanism that required signing the result with a per-device key owned by the Secure Element, to authenticate that it really did come from the claimed device, then they’d have had a mechanism for doing rate limiting even with a fully compromised OS. Given that the user needs to type their PIN and you need a server round trip, limiting this to 10 seconds per try with exponential back-off, using the same policy as local PIN brute forcing protection, would have prevented this vulnerability entirely for iOS users. Mac users with older machines would still have been vulnerable to the attack by a compromised OS.
The really surprising thing to me is that Apple has made a mechanism that depends on entering the same PIN as the one that unlocks the device without providing the same protections. The reason that you’re told not to share passwords between services is that any system using that password becomes as vulnerable as the least secure one. Apple has forced iOS users to share their PIN between the device and the iCloud unlock service and has not put the same protections on the PIN when used in the different contexts. That’s not the kind of mistake I’d expect Apple’s security team to make - they have a bunch of really smart people and this is a rookie mistake.
Given that Apple’s threat model for iOS PINs is that it should protect the users against Apple trying to attack the PIN, the correct way of implementing this is akin to WebAuthn: The Secure Element should provide a public key that the device uploads to Apple, the device should use the PIN to authorise the Secure Element to sign a nonce with this key. This reuses the same infrastructure that already exists for device unlock, installing software updates, and so on, where the Secure Element rate limits the number of PIN attempts.