iCloud Apple ID Brute Forcer(github.com)
github.com
iCloud Apple ID Brute Forcer
https://github.com/Pr0x13/iDict
41 comments
Could also be used to just grab the password and try it against other accounts. Most people have one password for everything.
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.
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.
"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.
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.
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.
> 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.
Wow. Citation needed, please.
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?
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?
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.
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.
Apple is notorious for not accepting certain discovered vulnerabilities at best, and at worst ciminilizing people who do try and report an issue.
I don't think this is accurate, is it? I'm not aware of any security issue where Apple has tried to criminalise the reporter. I'm not even aware of an issue that hasn't been 'accepted'.
I don't think this is accurate, is it? I'm not aware of any security issue where Apple has tried to criminalise the reporter. I'm not even aware of an issue that hasn't been 'accepted'.
I'm guessing you're mixing up Apple with AT&T. http://arstechnica.com/tech-policy/2013/07/internet-troll-we...
I've never once had difficulty reporting a security vulnerability to Apple.
For that matter, I've never seen any of my friends in /r/netsec have difficulty either.
Slow to respond? Perhaps, if they receive many reports. Outright ignore or invalidate real flaws? Never seen it.
Do you have a data point to back this up?
For that matter, I've never seen any of my friends in /r/netsec have difficulty either.
Slow to respond? Perhaps, if they receive many reports. Outright ignore or invalidate real flaws? Never seen it.
Do you have a data point to back this up?
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
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.
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.
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.
> but beyond scope for a lot of developers.
Nothing is, or should be, beyond the scope of Apple.
Nothing is, or should be, beyond the scope of Apple.
Yes, I wasn't talking about Apple.
I would think Apple is more than capable of doing progressive challenges and heuristic analysis for the login.
And while it's true that it's not as easy as simple rate limiting for developers that develope their own simple services there are plenty of login providers and frameworks that handle it well.
Honestly today i see very little reason to develope your own login mechanism and not use many of the available SSO's out there unless you are big enough for it to matter, and then you have no resource limitation.
The problem with rate limiting is that it's very hard to do it properly and scale it.
For example how do you do rate limiting? are you doing it per "session" e.g. increase the login proccessing time for each individual IP address? if so then distributed attacks will still be effective.
And if you are simply doing it for each sessions (by cookie or some other identifier) then it doesn't help against scripting attacks what so ever since they can be adapted to request a new session every time.
Where do you set the limit flag? is it handled by the authentication front end? If so you'll have issues enforcing this if you have a distributed solution which a service with as many users as iCloud will have.
If you are doing it on your main identity DB then you also might have scalability issues since you will have to sync these values accross all of your instances.
Also don't forget that every time you do this "rate limit" it means that there will be a "proccess" on your authentication server idling for the duration of the limit, this means that there will be halted login attempts on your authentication servers, enough of them and you might get into some serious resource issues.
A 10 second pause might be acceptable on your laptop after you type your password wrong 3 times, but doing it on the server means that it allocates resources then puts limitations on how fast these resources can be cleared which isn't a very good design.
As for the UX issues the problem is that it's not always as simple as some username and password, especially for services such as iCloud where a simple missbihaving app can cause accounts to be effectively locked out, and when you count in the amount of users such services has then it becomes quite a frequent event.
So yes while i do agree rate limiting does effectively prevent brute forcing, i don't see it as being a viable strategy for an online service. Rate limiting should be left for closed enviornments where you have full control over your clients and where users can be serviced in a reasonable manner.
Putting it on distributed open services that service millions of users where you might have various types of clients that you have no control over making authentication requests will just cause trouble.
Honestly today i see very little reason to develope your own login mechanism and not use many of the available SSO's out there unless you are big enough for it to matter, and then you have no resource limitation.
The problem with rate limiting is that it's very hard to do it properly and scale it.
For example how do you do rate limiting? are you doing it per "session" e.g. increase the login proccessing time for each individual IP address? if so then distributed attacks will still be effective.
And if you are simply doing it for each sessions (by cookie or some other identifier) then it doesn't help against scripting attacks what so ever since they can be adapted to request a new session every time.
Where do you set the limit flag? is it handled by the authentication front end? If so you'll have issues enforcing this if you have a distributed solution which a service with as many users as iCloud will have.
If you are doing it on your main identity DB then you also might have scalability issues since you will have to sync these values accross all of your instances.
Also don't forget that every time you do this "rate limit" it means that there will be a "proccess" on your authentication server idling for the duration of the limit, this means that there will be halted login attempts on your authentication servers, enough of them and you might get into some serious resource issues.
A 10 second pause might be acceptable on your laptop after you type your password wrong 3 times, but doing it on the server means that it allocates resources then puts limitations on how fast these resources can be cleared which isn't a very good design.
As for the UX issues the problem is that it's not always as simple as some username and password, especially for services such as iCloud where a simple missbihaving app can cause accounts to be effectively locked out, and when you count in the amount of users such services has then it becomes quite a frequent event.
So yes while i do agree rate limiting does effectively prevent brute forcing, i don't see it as being a viable strategy for an online service. Rate limiting should be left for closed enviornments where you have full control over your clients and where users can be serviced in a reasonable manner.
Putting it on distributed open services that service millions of users where you might have various types of clients that you have no control over making authentication requests will just cause trouble.
>Honestly today i see very little reason to develope your own login mechanism and not use many of the available SSO's out there unless you are big enough for it to matter, and then you have no resource limitation.
On the contrary, I see very little reason to use someone else's authentication infrastructure (Facebook, Google+, et al) without at least also providing the option to register using plain old email, unless you're developing an app that is intimately tied to that service. You lose so much control over your users, and you risk everything on your SSO provider not changing their minds about how you can use their service (see Twitter.)
Regarding your other points about rate limiting, I think you're overcomplicating the situation. It doesn't require a process on your authentication server that sits around and waits for one particular client to be allowed to try again (why would it?), and db sync issues are largely irrelevant unless you're at serious scale, which 99.9999% of web apps never will be, and if they are at serious scale, chances are syncing a "last_login_attempt" field in a login table is the least of their difficulties.
In Apple's case, of course rate limiting isn't the only solution they should be using, but it's a perfectly fine solution in the vast majority of cases where building a heuristic engine to protect a cat forum login page is overkill.
On the contrary, I see very little reason to use someone else's authentication infrastructure (Facebook, Google+, et al) without at least also providing the option to register using plain old email, unless you're developing an app that is intimately tied to that service. You lose so much control over your users, and you risk everything on your SSO provider not changing their minds about how you can use their service (see Twitter.)
Regarding your other points about rate limiting, I think you're overcomplicating the situation. It doesn't require a process on your authentication server that sits around and waits for one particular client to be allowed to try again (why would it?), and db sync issues are largely irrelevant unless you're at serious scale, which 99.9999% of web apps never will be, and if they are at serious scale, chances are syncing a "last_login_attempt" field in a login table is the least of their difficulties.
In Apple's case, of course rate limiting isn't the only solution they should be using, but it's a perfectly fine solution in the vast majority of cases where building a heuristic engine to protect a cat forum login page is overkill.
Because if you want to limit the number of attempts you have to code it into the login module. If you want to save time... By the way, if you're attempting a bruteforce don't use PHP.
I agree. I tossed up a terrible drunk Python PoC on /r/netsec. https://github.com/Pilfer/iDictPy
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.
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.
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, sourced from a URL the brute forcer script hits).
One oddity I found is different length requirements for regular email and recovery email
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.",Probably just different field lengths in the DB.
Only good use for this is finding out if icloud usernames exist (checking the response body).
Skip the link, but know it's out there.
Why skip the link? Is knowledge dangerous, or is it a case of offending sensibilities? I'm not sure what you're implying.
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.
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.
... ... 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.
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.
Totally, but in terms of readability for proof on concept, I can see why the author chose PHP. I think the repo was more for showing the vulnerability rather than an actual tool that could be used right out the box.
He is probably a relatively inexperienced programmer. But who cares? The main accomplishment / item on display here is the identification of a vulnerability in a high-value target (supposedly - I haven't verified it), not the PoC.
It's a proof-of-concept.
Also, PHP does have support for multiple threads and/or forking. It's just not commonly used.
Also, PHP does have support for multiple threads and/or forking. It's just not commonly used.
[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).
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).
I really think you are missing the point here. And why are you so exasperated? Take a break man.
pthreads. You know them?
You now know the payload and the endpoint, so feel feel to fork
POC's tend to be very spartan, the simplest thing that works is enough, the goal was to show that is possible not to release an effective burteforcing platform.
Also last time I've checked nothing stopping you from running multiple PHP instances on the same server, or say load this to you 300,000 strong bot net ;)
This explains these days everyone and anyone is trying to find vulns even if their technical skills are limited to PHP.
Oh man, it's a PoC, not something to actively help script-kiddies crack Apple authentication! This isn't MEANT to be polished. This is meant to shame Apple into fixing their glaring security vulnerability.
Has anyone looked at the wordlist? It's over here: https://raw.githubusercontent.com/Pr0x13/iDict/master/files/...
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
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
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.
It's just a proof of concept.
> This Apple ID has been locked for security reasons. Visit iForgot to reset your account (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