iCloud Apple ID Brute Forcer
github.com
github.com
> 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
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'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.
Wow. Citation needed, please.
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?
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.
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'.
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?
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.
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.
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.
Nothing is, or should be, beyond the scope of Apple.
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.
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.",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.
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.
Also, PHP does have support for multiple threads and/or forking. It's just not commonly used.
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).
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