Web Excursions 2021-06-21

How I Found A Vulnerability To Hack iCloud Accounts and How Apple Reacted To It - The Zero Hack

  • I found a vulnerability on Apple forgot password endpoint that allowed me to takeover an iCloud account.

    • The vulnerability is completely patched by Apple security team and it no longer works.

    • Apple Security Team rewarded me $18,000 USD as a part of their bounty program

    • but I refused to receive it.

  • The forgot password option of Apple ID allows us to change our password using 6 digit OTP

  • We need to know the trusted phone number as well as their email address to request OTP

  • Findings

    • iforgot.apple.com resolves to 6 IP addresses across the globe

    • two rate limits

      • more than 5 requests to forgot password endpoint (5 failed attempts = acct. locked)

      • across the apple server when we send more than 6 concurrent POST requests

    • specific to apple server IP

      • an still send requests (with in limits though) to another apple server IP.

      • i.e., up to 36 requests across the 6 apple IP address (6 x 6 = 36) from single IP address

      • i.e., 28K IP addresses to send up to 1 million requests to successfully verify the 6 digit code

    • Apple rejects the POST request with 502 Bad gateway without even checking the request URI or body when sending from cloud service providers like AWS, Google cloud, etc.

      • [The author] found a few service providers their network IPs are not blacklisted.

  • The author reported on 20200701; Apple triaged the issue with in few minutes; then no feedback until 20200909; then another 5-mon period of silence

    • Patched as of 20210401; the author contacted Apple again and was told to share a draft before publishing

    • Apple replied that their analysis revealed that the exploit only works against iCloud accounts that has not been used in passcode / password protected Apple devices.

      • changed the support page regarding forgot pw, "[In some cases,] you may be able to reset your password using a trusted phone number and trusted email."

      • 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.

  • Apple uses SRP (Secure Remote Password), a PAKE protocol to verify the user knows the right passcode without actually sending it to the server.

    • 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.

    • But, bruteforcing single user is enough to get into their iCloud account as well as finding their passcode.

  • When we enter the passcode in an iPhone / iPad during password reset,

    • the device initiates SRP authentication by sending the user session token obtained from the successful SMS verification.

    • The server responds back with the salt of the respective user.

    • The passcode and the salt are hashed to then derive the final key which is sent the server.


Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible | Hacker News

  • avalys: Can anyone comment on the significance of this accomplishment, and why it was hard to achieve before?

    • peterkelly: For some reason, many compilers and build scripts have traditionally been written in a way that's not referentially transparent (a pure function from input to output).

      • Unnecessary information like the time of the build, absolute path names of sources and intermediate files, usernames and hostnames often would find their way into build outputs.

      • Compiling the same source on different machines or at different times would yield different results.

      • Reproducible builds avoid all this and always produce the same outputs given the same inputs.

      • There's no good reason (that I can think of) why this shouldn't have been the case all along, but for a long time I guess it just wasn't seen as a priority.

      • The benefit of reproducible builds is that it's possible to verify that a distributed binary was definitely compiled from known source files and hasn't been tampered with,

      • because you can recompile the program yourself and check that the result matches the binary distribution.

    • danbst: There is Debian initiative to create bit-to-bit reproducible builds for all their software (well, all critical). https://reproducible-builds.org/

      • R13y is akin to "computer proofs" in math -- if you don't have it, that's fine, but if you have it, that's awesome.