I have tried this script on my own account to see what it looks like when it succeeds and all of that. While it does appear to succeed and not be rate limited. The outcome is that the account will have been disabled as a result running the script. Even if it succeeded and found the password it would be no good to the attacker anymore.<p>> This Apple ID has been locked for security reasons. Visit iForgot to reset your account (<a href="https://iforgot.apple.com" rel="nofollow">https://iforgot.apple.com</a>).<p>I'm no security expert but that must reduce at least some of the vulnerability.<p>Though it seems like this could be weaponized to be a hassle. I only point this out because I have 2-factor auth and have locked my account and cannot seem to find my recovery key. /facepalm
"Why?
This bug is painfully obvious and was only a matter of time before it was
privately used for malicious or nefarious activities, I publicly disclosed it so apple will patch it."<p>I'm not a security expert but that does not sound like responsible disclosure to me. Granted, Apple is not easy to communicate with, but still…<p>Edit: This does indeed look like a really bad thing. At the very least one would hope that login attempts were rate limited.
How is it not rate limited? I don't understand why this is not a thing in every login activity everywhere. can someone explain one reason you might choose to NOT rate limit auth attempts? I don't understand :S
A quick skim of the source shows that appears to be using the iCloud auth device setup workflow which does not have any rate limiting or account lockout guards in place.<p>I'm guessing the author noticed that, when setting up a new device for iCloud, that they didn't get locked out when authenticating their iCloud credentials. They then reverse engineered this authentication process and created a script to brute force it. Not an earth shattering attack, but an astute one.<p>Expect apple to add rate limiting soon. I'm not sure if they'd be able to implement lockout without breaking the login process with existing devices.
Slightly side note, I found it interesting looking through the HTML UI for the iCloud account creation (<a href="https://setup.icloud.com/setup/create_account_ui" rel="nofollow">https://setup.icloud.com/setup/create_account_ui</a>, sourced from a URL the brute forcer script hits).<p>One oddity I found is different length requirements for regular email and recovery email<p><pre><code> EmailTooLong: "Email address must be less than 320 characters.",
RecoveryEmailTooLong: "Email address must be less than 256 characters.",</code></pre>
... ... wait, wait, wait.<p>This is a tool which attempts to brute force a password by making HTTP POSTs to an API? And someone though the best way to write that was in in PHP, which is single threaded and thus cannot try multiple passwords in parallel?<p>Wow. Ok. Good luck with that.
Has anyone looked at the wordlist? It's over here: <a href="https://raw.githubusercontent.com/Pr0x13/iDict/master/files/wordlist.txt" rel="nofollow">https://raw.githubusercontent.com/Pr0x13/iDict/master/files/...</a><p>For those who don't want to bother clicking on that link, it's only 500 lines long. In other words, if your password is not one of the 500 listed in that file, you'll be fine. My password is not listed in the file, and the same goes for almost all of us. There are literally 500 passwords in that file! If you only use letters and numbers for your password and your password is 8 characters long, there are more than 2 * 10^14 possibilities<p>This thing has got to be a joke