

iCloud Apple ID Brute Forcer - evandrix
https://github.com/Pr0x13/iDict

======
lovelettr
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.

> This Apple ID has been locked for security reasons. Visit iForgot to reset
> your account ([https://iforgot.apple.com](https://iforgot.apple.com)).

I'm no security expert but that must reduce at least some of the
vulnerability.

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

~~~
EC1
Could also be used to just grab the password and try it against other
accounts. Most people have one password for everything.

~~~
lovelettr
That is a valid point that I didn't think about.

I forget that not everyone uses something like 1password generate random
passwords for all sites. Therefore, compromising one doesn't compromise them
all. I recognize that is not common behavior.

------
sekasi
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

~~~
dogma1138
Any effective rate limiting tends to cause major UX issues under many
circumstances and opens the system to denial of service under some. Probably
the best way of dealing with such attacks these days is what Google and many
other companies do and that's use huristics and progressive challenges, while
not perfect these tend to be usually even more effective than rate limiting.
If the auth requests are comming for an unknown device, a foriegn IP address,
at a suspicious time/rate etc. the user is challenged for additional
information than just their passwords this can be some random secret question
a secondary authentication (via phone, SMS, email etc) or even some anti
scripting stuff.

~~~
neotek
Heuristics and progressive challenges are definitely the best option, but
beyond scope for a lot of developers. Rate limiting is the simplest option,
and the only real "major UX issue" I can think of is locking someone out of
their account after three password attempts, which can definitely be a pain in
the arse if you're trying to log into a site you don't frequently visit.

But the solution is pretty simple: rate limit to one attempt every few
seconds, and if you want to lock the account, only do so after a lot of
unsuccessful attempts. For example, bruteforcing is impractical if you can
only try one password every five seconds, and essentially impossible if you
only get 100 bites at the apple before you get locked out.

~~~
madeofpalk
> but beyond scope for a lot of developers.

Nothing is, or should be, beyond the scope of Apple.

~~~
neotek
Yes, I wasn't talking about Apple.

------
Y-bar
"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."

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…

Edit: This does indeed look like a really bad thing. At the very least one
would hope that login attempts were rate limited.

~~~
dogma1138
Having had to deal with apple and knowing quite a few other people who had a
simmilar exprience i have a feeling that this was the only way of doing so.
Apple is notorious for not accepting certain discovered vulnerabilities at
best, and at worst ciminilizing people who do try and report an issue. This
for some reason is much more prevelant for their services and mobile platform
(especially when it comes to "design" flaws rather than a simple software bug)
than the OSX team which while might simply not reply unless it gets enough
traction on the the mailing list will atleast not send you threatening letters
from their lawyers.

~~~
Y-bar
> at worst ciminilizing people who do try and report an issue […] will atleast
> not send you threatening letters from their lawyers

Wow. Citation needed, please.

~~~
Y-bar
So, I've been googling but can't find any single instance where Apple seems to
have threatened a security researcher. I'm new here on HN, but I don't
understand why I was down voted. Was it seen as passive-agressive to ask, I
could understand that, but any actual source would be appreciated.

We all know that anything that paints Apple in a bad light travels faster than
the speed of said light and generally gets picked up by a dozen news outlets,
no matter how rumour-esque it is. So it ought to be some traces of Apple
taking legal actions against people reporting security issues against them,
no?

~~~
josephlord
In general "citation needed" on its own is frowned on as it is lazy and
negative adding little to the discussion. My guess is that this is the reason
for downvotes.

Some claims do have to be called out and this might have be one of them. An
indication that it doesn't match your experience and that you have done at
least a cursory search before requesting the citation would be less likely to
be downvoted.

------
madeofpalk
Slightly side note, I found it interesting looking through the HTML UI for the
iCloud account creation
([https://setup.icloud.com/setup/create_account_ui](https://setup.icloud.com/setup/create_account_ui),
sourced from a URL the brute forcer script hits).

One oddity I found is different length requirements for regular email and
recovery email

    
    
        EmailTooLong:         "Email address must be less than 320 characters.",
        RecoveryEmailTooLong: "Email address must be less than 256 characters.",

~~~
ZitchDog
Probably just different field lengths in the DB.

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

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.

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.

------
dudexxx
Only good use for this is finding out if icloud usernames exist (checking the
response body).

------
SecurityAlert
Skip the link, but know it's out there.

~~~
Intermernet
Why skip the link? Is knowledge dangerous, or is it a case of offending
sensibilities? I'm not sure what you're implying.

~~~
neotek
I think what SecurityAlert is saying is that there isn't really any value in
the repo: as others have pointed out, it's just a simple PHP script that
iterates through a dictionary.

It's just meant to bring attention to the fact that Apple doesn't rate limit
an endpoint that absolutely should be rate limited, and you don't actually
need to see the repo to understand that.

------
billyhoffman
... ... wait, wait, wait.

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?

Wow. Ok. Good luck with that.

~~~
thaumaturgy
It's a proof-of-concept.

Also, PHP does have support for multiple threads and/or forking. It's just not
commonly used.

~~~
billyhoffman
[sigh]

Yes, I know PHP can use a standard fork() call. But if you fork, then you need
to shard the attack space into different sections, and then pull all the
results back together again. Or you manually use `split` on the wordlist and
run them as parallel processes. Either way, you are going to have to go
through that trouble to re-combining everything. At which point, you might as
well use an actual threaded language.

(The only other way I know to do threading in PHP is with curl's multi-request
feature, which is hacky and leads to several problems, in addition to head-of-
line blocking).

~~~
cryowaffle
I really think you are missing the point here. And why are you so exasperated?
Take a break man.

------
jamescostian
Has anyone looked at the wordlist? It's over here:
[https://raw.githubusercontent.com/Pr0x13/iDict/master/files/...](https://raw.githubusercontent.com/Pr0x13/iDict/master/files/wordlist.txt)

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

This thing has got to be a joke

~~~
sp0rk
Small wordlists are generally used with long username lists to get the low-
hanging fruit. Obviously somebody using this tool to target a specific account
is going to swap out the default wordlist for something much larger and
potentially customized.

