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.
iCloud Apple ID Brute Forcer
11–20 of 42 posts
Re: iCloud Apple ID Brute Forcer
#12... ... 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 explains these days everyone and anyone is trying to find vulns even if their technical skills are limited to PHP.
Re: iCloud Apple ID Brute Forcer
#13... ... 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.
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.
Re: iCloud Apple ID Brute Forcer
#14... ... 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.
It's a proof-of-concept.
Also, PHP does have support for multiple threads and/or forking. It's just not commonly used.
Re: iCloud Apple ID Brute Forcer
#15Skip 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.
Re: iCloud Apple ID Brute Forcer
#16How 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 u…
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.
Re: iCloud Apple ID Brute Forcer
#17... ... 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.
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.
Re: iCloud Apple ID Brute Forcer
#18Earlier quoted context omitted.
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 u…
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 li…
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.
Re: iCloud Apple ID Brute Forcer
#19... ... 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.
It's a proof-of-concept. 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).
Re: iCloud Apple ID Brute Forcer
#20... ... 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.
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 ;)