12 ms·

iCloud Apple ID Brute Forcer

68 points by evandrix 12y ago

sekasi 12y ago
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 12y ago
  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 12y ago
    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.
    - dogma1138 12y ago
      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.
      - 12y ago
    - madeofpalk 12y ago
      > but beyond scope for a lot of developers. Nothing is, or should be, beyond the scope of Apple.
      - neotek 12y ago
        Yes, I wasn't talking about Apple.
- baby 12y ago
  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.
  - pilfers 12y ago
    I agree. I tossed up a terrible drunk Python PoC on /r/netsec. https://github.com/Pilfer/iDictPy https://github.com/Pilfer/iDictPy
Y-bar 12y ago
"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 12y ago
  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 12y ago
    > 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 12y ago
      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?
billyhoffman 12y ago
... ... 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.
- mauz0r 12y ago
  You now know the payload and the endpoint, so feel feel to fork
- zuck9 12y ago
  This explains these days everyone and anyone is trying to find vulns even if their technical skills are limited to PHP.
- comeonnow 12y ago
  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.
- thaumaturgy 12y ago
  It's a proof-of-concept. Also, PHP does have support for multiple threads and/or forking. It's just not commonly used.
  - billyhoffman 12y ago
    [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).
SecurityAlert 12y ago
Skip the link, but know it's out there.
- Intermernet 12y ago
  Why skip the link? Is knowledge dangerous, or is it a case of offending sensibilities? I'm not sure what you're implying.
  - neotek 12y ago
    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.
madeofpalk 12y ago
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 12y ago
  Probably just different field lengths in the DB.
jamescostian 12y ago
Has anyone looked at the wordlist? It's over here: https://raw.githubusercontent.com/Pr0x13/iDict/master/files/wordlist.txt 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
- sp0rk 12y ago
  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.
- colinbartlett 12y ago
  It's just a proof of concept.
ZitchDog 12y ago
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.
lovelettr 12y ago
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 12y ago
  Could also be used to just grab the password and try it against other accounts. Most people have one password for everything.
  - lovelettr 12y ago
    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.
dudexxx 12y ago
Only good use for this is finding out if icloud usernames exist (checking the response body).

68 points by evandrix 12y ago

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 12y ago
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 12y ago
  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.
  - dogma1138 12y ago
    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.
    - 12y ago
  - madeofpalk 12y ago
    > but beyond scope for a lot of developers. Nothing is, or should be, beyond the scope of Apple.
    - neotek 12y ago
      Yes, I wasn't talking about Apple.
baby 12y ago
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.
- pilfers 12y ago
  I agree. I tossed up a terrible drunk Python PoC on /r/netsec. https://github.com/Pilfer/iDictPy https://github.com/Pilfer/iDictPy

Y-bar 12y ago

"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 12y ago
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 12y ago
  > 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 12y ago
    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?

billyhoffman 12y ago

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

mauz0r 12y ago
You now know the payload and the endpoint, so feel feel to fork
zuck9 12y ago
This explains these days everyone and anyone is trying to find vulns even if their technical skills are limited to PHP.
comeonnow 12y ago
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.
thaumaturgy 12y ago
It's a proof-of-concept. Also, PHP does have support for multiple threads and/or forking. It's just not commonly used.
- billyhoffman 12y ago
  [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).

SecurityAlert 12y ago

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

Intermernet 12y ago
Why skip the link? Is knowledge dangerous, or is it a case of offending sensibilities? I'm not sure what you're implying.
- neotek 12y ago
  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.

madeofpalk 12y ago

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 12y ago
Probably just different field lengths in the DB.

jamescostian 12y ago

Has anyone looked at the wordlist? It's over here: https://raw.githubusercontent.com/Pr0x13/iDict/master/files/wordlist.txt 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

sp0rk 12y ago
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.
colinbartlett 12y ago
It's just a proof of concept.

ZitchDog 12y ago

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.

lovelettr 12y ago

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 12y ago
Could also be used to just grab the password and try it against other accounts. Most people have one password for everything.
- lovelettr 12y ago
  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.

dudexxx 12y ago

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