Many people mistook this vulnerability as typical brute force attack but it isn’t. Here we are sending multiple concurrent requests to the server to exploit the race condition vulnerability present in the rate limits making it possible to bypass it - Muthiyah words for Race hazard-based brute forcing.
To exploit the bug, the attacker needs a trusted phone number along with an email address to request OTP.
Of course the attack isn’t easy to do, we need to have a proper setup to successfully exploit this vulnerability. First we need to bypass the SMS 6 digit code then 6 digit code received in the email address. Both bypasses are based on same method and environment so we need not change anything while trying the second bypass. Even if the user has two factor authentication enabled, we will still be able to access their account, because 2FA endpoint also shares the rate limit and was vulnerable. The same vulnerability was also present in the password validation endpoint. - Muthiyah explained
On successful exploiting the bug, Muthiyah shares the information with detailed reproduction steps and a video demonstrating the bypass to Apple security team on July 1st, 2020. Apple security team acknowledged and triaged the issue with in few minutes of the report.
After multiple follow-ups with Apple Security team, Muthiyah said his findings were patched on April 1st 2021. He also shared his blog post regarding his founding with Apple team, but Apple team denied the report (iCloud account takeover bug) of Muthiyah with a claim saying that this vulnerability does not allow to takeover majority of the iCloud accounts. As Apple team analysis revealed that it only works against iCloud accounts that have not been used in passcode/password protected Apple devices.
Later on, Apple representative says (regarding Muthiyah findings), that the passcode is not being sent to any server endpoint and is verified in the device itself. After Laxman point on that, there is no way for a random apple device to know another device’s passcode without contacting the Apple server. Apple said it is true that the data is sent to the server but it is verified using a cryptographic operation and they cannot reveal more than that due to security concerns.
I asked what if we find out the encryption process through reverse engineering to replicate it and brute force the Apple server with concurrent requests. I didn’t get any definite answer for that question. They concluded that the only way to brute force the passcode is through brute-forcing the Apple device which is not possible due to the local system rate limits. - Muthiyah wrote
Deep-dive into Apple for Security Workflow.
After the words with Apple representative, Muthiyah get deeper with his finding. In his research he found that Apple uses SRP (Secure Remote Password), a PAKE protocol to verify the user knows the right passcode without actually sending it to the server. Apple isn’t sending the passcode directly to the server. Instead, both server and client do some mathematical calculations using the previously known data to derive a key (more like diffie-hellman key exchange).
SRP is known to prevent bruteforce attacks as it has user-specific salt and a verifier, so even if someone steals our database, they will still need to perform a CPU intensive bruteforce for each user to discover the password one by one. That gives enough time for the affected vendor to react to it. Read more about the detailed calculations of SRP-6a here.
With the detail in his research, Muthiyah found -
- Bypassed the two-factor authentication. It is literally like 2FA doesn’t exist due to the bypass. People who are all relying on 2FA are vulnerable. This itself is a major vulnerability.
- Bypassed the password validation rate limits. All the Apple ID accounts that use common / weak / hacked passwords are vulnerable even if they have two factor authentication enabled. Once hacked, the attacker can track the location of the device as well as wipe the device remotely. 2014 celebrities iCloud hack is majorly because of weak passwords.
- Bypassed the SMS verification. If we know the passcode or password of the device associated with the iCloud account. Lets say any of your friends or relatives knows your device passcode, using this vulnerability, they can takeover your iCloud account and also can erase your entire device remotely over the internet without having physical access to it.
- We can takeover all Apple IDs that are not associated with a passcode protected Apple device due to both SMS and email verification code bypass, which means
- Any apple device without passcode or password, like anyone who turned off or didn’t set the passcode / password.
- Any Apple ID created without apple device, like in browsers or in an android app and not been used in password protected apple devices
- For example, 50 Million+ android users have downloaded Apple music app. In those, the majority of them may not have used Apple devices. They are still Apple users and their information like credit cards, billing address, subscription details, etc could be exposed.
Selling these kind of vulnerabilities to government agencies or private bounty programs like zerodium could have made a lot more money. But I chose the ethical way