Figured out how to take over iCloud, but Apple's behavior made this hacker depressed and gave up the whole 18,000 USD in bounty

Like every other online service, Apple has an option for people who forget the password to their iCloud account to reset the password when they enter the correct 6-digit OTP number sent to the mobile number and their email address. To be on the safe side, Apple is also careful to remind users to get that OTP on a phone number and email address they trust.

However, a white hat hacker named Laxman Muthiyah has found a way to bypass Apple's protection to change the password for any iCloud account he wants. But what is even more remarkable is how Apple behaves when it receives that information.

Simple way to reset iCloud password

Without resorting to complicated tricks, Laxman applies the simplest solution to finding this OTP: trial and error one at a time. Laxman will try all possible 6 digit codes to see which will give the correct result.

Of course, it's not easy to do that. With 6 digits in the OTP, there will be about 1 million different possibilities. The number of times to enter the OTP code is limited to 6 failed attempts, if exceeded, the account will be temporarily locked for a few hours, even after changing the IP address. Not giving up, Laxman tried to send OTP code queries to Apple servers in bulk. But just like above, you can't send more than 6 queries at the same time to the Apple server if you don't want to have your IP address blocked.

However, Laxman discovered that Apple has 6 IP addresses for servers that handle OTP queries globally. Because of Apple's limits on the number of requests sent to a particular server IP, it is still possible to send further queries to the rest of Apple's server IPs – as long as it remains within limits permission.

For each IP address for Apple's servers, only 6 OTP code queries will be able to be sent simultaneously. This also means that at the same time, from each IP address you can send up to 36 OTP code queries to 6 Apple servers. Therefore, if an attacker has mobilized 28,000 different IP addresses, he can send 1 million queries to the Apple server at the same time and there will definitely be a correct result returned by the Apple server. .

28,000 IP addresses is not a problem for cloud providers, but Apple blocks POST queries from providers like Amazon, Google Cloud or Microsoft Azure. But Laxman discovered, Apple only blocked queries from certain cloud service providers, and the hacker eventually found a number of cloud service providers that were not blocked by Apple.

And surprisingly, this approach worked. This Laxman can now change the password of any Apple ID if he wants. Of course, this kind of attack is not easy to execute. To access an iCloud account, Laxman also has to pass the iPhone's 6-character encryption key associated with that account. However, the way to bypass this security layer is similar to iCloud.

With a vulnerability this serious, a hacker could make a lot of money on the black market, but Laxman decided to tell Apple - even though the reward would be much less.

Apple's suspicious silence with this vulnerability

On June 1, 2020, Laxman reported the vulnerability along with a demonstration video to Apple's security team. Apple's security team acknowledges the issue and says it will fix it soon.

But after 3 months, then another 5 months of waiting, Laxman still has not received an update from Apple about this vulnerability that he considers critical. Every time he asked Apple's security team again, he received an answer that they were still working on repairs and still had no new information to share with him.

It's a pretty serious flaw, but Apple hasn't made any updates on it for months

By April 1, 2021, when re-examining the above vulnerability, Laxman realized it had been patched with no information from Apple. A month later, he emailed Apple again, saying that this loophole was patched on April 1, but why hasn't Apple updated on this. He even shared with them an article about how to find this vulnerability.

But now is where things get weird.

After receiving an article about how to exploit the vulnerability, Apple's security team denied that this vulnerability could be used to hijack iCloud accounts. They think that this method only works with iCloud attached to iPhones and iPads that do not use a password or passcode protection layer.

Apple's email says this attack only works with iCloud attached to iPhones, iPads and Macs that don't have password protection.

Laxman countered Apple's argument. He thinks that with the same limit of trial and error on the server, even if an Apple device uses a password or passcode or even two-factor authentication, it can still be bypassed thanks to this method. code above.

Theory of Apple's security method

But Apple persisted with its argument. During the call to Laxman, Apple explained that the company's servers do not send authentication codes to the device and that the authentication process takes place on the device. Although Apple did not explain in detail, but with some tools like checkra1n and SSL Kill Switch, Laxman partially confirmed the company's claims.

According to Laxman, Apple seems to use the SRP protocol to authenticate users without having to send authentication codes directly to the device.

According to this protocol, when authentication is requested, the Apple server just sends a random parameter (called a salt) to the device. The device will use this salt to calculate the key based on the available formula. The Apple server also uses this salt, combined with another verification code, to calculate the same formula as on the device. If both the server and the device give the same results, then the login process will take place.

Therefore, Apple is confident that the only way to detect the iCloud authentication code is to unlock the iPhone or iPad attached to it, but this is not possible due to the limit on the number of failed attempts on the device.

However, Laxman believes that his approach is to target the weakness when Apple's server allows to receive a series of authentication code queries from an iCloud account at the same time, not a way to attack the password. account.

To prove his argument, Laxman decided to test by attacking the password reset of any iPhone. After the first attempt to enter the authentication code, he intercepted the data (including the salt and authentication code) sent from the Apple servers to the device.

However, to his astonishment, he discovered that this weak point had been blocked. Of the 30 queries he sent simultaneously to an Apple device, only one was received and the other 29 were rejected. This meant that his attack method was no longer usable.

According to Laxman, considering that this vulnerability appears in Apple's security layers that he has tested before, including SMS authentication, email authentication code, two-factor authentication, password authentication, very It's highly unlikely that it didn't appear on Apple devices, as it was patched before Laxman's report was sent to the company.

And if it is true that Apple has quietly patched that vulnerability after Laxman reported it, it means that this vulnerability is much more serious than he initially thought. So if his assumption is correct, this vulnerability not only helps to capture any iCloud account but also the Apple device keycode attached to it. Even if the way to perform this attack is quite complicated, this vulnerability still allows to hack any iPhone/iPad using 4 or 6 digits.

However, now that this vulnerability has been closed, the concurrent query attack is no longer effective, Laxman has no way to verify his claim anymore. The last hope was confirmation from Apple, but they also did not respond to Laxman's emails anymore.

Totally disappointed in Apple's behavior

Even so, Apple still sent Laxman a bonus email for discovering a security flaw for the company. But it doesn't make Laxman any less disappointed in Apple's behavior.

The amount of bonus that Laxman received from Apple was 18,000 USD. Meanwhile, on Apple's website, the bounty for hijacking an iCloud account is $ 100,000, extracting data from a locked iPhone is $ 250,000. Whereas Laxman's report involved both of these scenarios (before the vulnerability was patched), the bounty could be as high as $350,000.

Even if Laxman chooses to sell these vulnerabilities to exploit-buying companies like Zerodium, the bounty could be even greater. But Laxman chose to do it more ethically, which was to inform Apple, but it turned out that the company's behavior and bonuses disappointed him. Not only was it not worthy of its discovery, but it was also not worth the hard work and waiting that had been spent the past year.

Therefore, Laxman decided to refuse this undeserved bounty and publish his full findings without waiting for a response from Apple anymore.