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.