Apple-id locking issue

[waqqas]

Hi,

I am using InflatableDonkey to periodically download specific files from icloud backup. The problem is that apple-id gets locked and I have to reset my password.

I call the iCloud API directly from my mobile app and get mmeAuthToken. I send this token to the server which pass this to the InflatableDonkey in a script (that runs once a day). In each script execution, I am running the InflatableDonkey command three times to download files from different domains.

The device that is calling the API to get mmeAuthToken and the server that is downloading the backup are in different geographical locations.

I am using iOS 10.3.1 but has experienced similar issue before this version too.

Any ideas why Apple locks the account?

Regard Waqqas

[AhsanWani]

+1

[horrorho]

Hi. Are you using the same mmeAuthToken every day or are you generating new ones?

[AhsanWani]

Were using the same mme auth token .

On 12-Apr-2017, at 5:53 PM, horrorho notifications@github.com wrote:

Hi. Are you using the same mmeAuthToken every day or are you generating new ones?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/horrorho/InflatableDonkey/issues/56#issuecomment-293566365, or mute the thread https://github.com/notifications/unsubscribe-auth/ARNYHmFMQFM0CgVO0_boD4FSJwd8BN_Bks5rvMlOgaJpZM4M688t.

[horrorho]

@AhsanWani Something is triggering a security flag. The exact flagging algorithm is not public and almost certainly changes over time. However there are a number of well known triggers, commonly:

• Multiple re-authentications via AppleID/ password as opposed to reusing an existing mmeAuthToken
• Downloading backups from multiple accounts from the same IP address over short time periods, particularly if this is a new download IP
• Blacked listed IPs/ proxies

If these conditions don't apply, please let me know. There are other potential factors at play that will allow Apple to identify atypical access patterns and lock accounts.

[waqqas]

When i was running multiple commands in parallel, I got "Too many SRP inits received" error I started calling the commands sequentially and it went away. Is it possible to make the "SRP init" requests common between different executions?

[AhsanWani]

Thank you for getting back. First two points you mentioned seem to be probable cause of error in my case .

• Multiple re-authentications via AppleID/ password as opposed to reusing an existing mmeAuthToken

• Downloading backups from multiple accounts from the same IP address over short time periods, particularly if this is a new download IP

I will test these cases, and will update ASAP

[horrorho]

@waqqas Yes it is possible to cache the values. It's been on the improvements list for a long while. I just haven't had the time to implement it.

@AhsanWani Thank you for the feedback.

[harshadpavasiya]

@horrorho First of all thanks for your effort and time, InflatableDonkey is a great piece of work and help many world wide. We have been using InflatableDonkey from last 6 month and never got the issue of "Iphone account block Status " , however after the latest version update of 28 feb where you have updated the code for new file system we are getting the issue of "Iphone account block status". As you mention surely iphone have updated their security parameter and algorithm which we need to consider to break it out. Hence request you to kindly check the same and do modify as per the requirement to work smoothly. Thanks for all your effort and time. God bless you .

[horrorho]

@hnpavasiya Hi. I need more information, are you restoring from a single account or from multiple accounts? Are you reusing an existing mmeAuthToken or re-authenticating via AppleID/ password pairs each time?

[harshadpavasiya]

@horrorho we are restoring from Multiple account and also we are re-authenticating via AppleID/ password pairs each time.

Regards

[horrorho]

@hnpavasiya Ok. You'll need to make adjustments to your usage. Please re-use mmeAuthTokens.

[asifmehmoood]

Hi, @horrorho we are facing the same issue and here are the scenarios we are using.

• Multiple re-authentications via existing mmeAuthToken
• Downloading backups from multiple accounts from the same IP address over 1 day interval
• IPs/ proxies are not Blacked listed

if you need any assistance related to this i would be happy to assist you :)

[horrorho]

@asifmehmoood and others. Hi again. I suspect the primary issue here is the volume of accounts being restored with a single/ limited IP address pool over a short time period, particularly if we are performing numerous authentications using AppleId/ password pairs.

Suspicious activity over an IP address will put it on a blacklist (initially short term + decay mechanics) that will likely lock other accounts accessed around the same time.

Toxic scenario: if you were to rapidly brute force accounts over an IP address, that address would soon become blacklisted and any further potentially valid authentications will lock that account immediately, additionally retrospective authentications will be rescinded and those accounts also locked. At some point the IP will recover if no further toxic behaviour is observed. Yes, I'm aware there are tricks available that allow a greater attack volume before locking but outside of potential zero-day exploits/ back doors the system does it's best to keep intruders out. This is Apple working to protect it's customers, a laudable goal.

There are numerous additional toxic patterns that will flag accounts and the algorithm is heuristic in nature. So a particular edge pattern with a non-2FA account that results in an account lock may not lock a 2FA account.

If any of you guys have implemented solutions that take customer authentication details to process locally, you may need consider a mechanism of safely authenticating/ acquiring an mmeAuthToken over the customer's IP and using that. That's probably going to be the single biggest reduction in threat.

That being said, there are additional factors at play that I won't discuss here that may assist. I do have another iCloud project in the pipeline that implements some of these measures but it's only half way tested and finished. Hopefully given enough spare time, I can introduce those measures into InflatableDonkey or move over InflatableDonkey's functionality to that project. However it won't solve the problem of hammering too many iCloud accounts over a single IP address.

Again, I make no claims to being an expert, if anyone else has any thoughts please feel free to chime in.

:crying_cat_face:

[waqqas]

@horrorho Is it possible to run InflatableDonkey via some proxy, so that IP is not blocked?

[horrorho]

@waqqas You can. However the proxy is subject to the same regulation and may itself become blacklisted if used aggressively. A pool of proxies would be an idea, just push accounts through the same proxy each time though.

[waqqas]

@horrorho I have added support for proxy and sent a pull request https://github.com/horrorho/InflatableDonkey/pull/58

[horrorho]

@waqqas Hi and thank you for the contribution. However InflatableDonkey already implements HTTPS/ SOCKS proxy support via [HttpClientBuilder#useSystemProperties](http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html#useSystemProperties()) and System Properties.

A HTTPS example is documented on the homepage. I understand it's easy to miss things sometimes as I do it all the time. I'll add in examples to the --help after work so the information is more accessible.

HTTPS proxy:

~/InflatableDonkey-master/target $ java -Dhttps.proxyHost=HOST -Dhttps.proxyPort=PORT -jar InflatableDonkey.jar myAppleID@example.com myPassword --token

Additionally we can pass https.proxyUser and https.proxyPassword.

Additionally SOCKS proxy:

~/InflatableDonkey-master/target $ java -DsocksProxyHost=HOST -DsocksProxyPort=PORT -jar InflatableDonkey.jar myAppleID@example.com myPassword --token

HTTPS system properties via code:

System.setProperty("https.proxyHost" , "host");
System.setProperty("https.proxyPort" , "port");
// System.setProperty("https.proxyUser" , "user");
// System.setProperty("https.proxyPassword" , "password");

SOCKS system properties via code:

System.setProperty("socksProxyHost" , "host");
System.setProperty("socksProxyPort" , "port");

HTTPS IP test patch:

HttpGet get = new HttpGet("https://api.ipify.org");
String ip = httpClient.execute(get, new BasicResponseHandler());
logger.info("-- ip() - ip: {}", ip);

[ItsASmallWorld]

@horrorho wow you've made great progress on this project, congrats!

If I am reusing my mmeAuthToken and only downloading backup data from my iCloud account what could be causing my account to be locked? For reference I'm downloading data from a few domains.

[horrorho]

@ItsASmallWorld Heya. There are a few additional factors that I won't go into too much detail about. I'll try and issue some patches next week but I can't make any promises. For May I'm overseas on a work assignment so things may get pushed to June.

[horrorho]

Ok! I've patched in limiting caching support that should tame our threat level and reduce locking. I'll test it over the next day or two and push over the weekend if all is well.

Cached data/ rationale:

• Escrowed key bag. Apple software caches escrowed data so InflatableDonkey constantly nagging the escrow servers probably isn't going down too well.
• Device hardware id/ uuid. Previously randomly generated on every application invocation, they do have the side effect of ramping up certain device access counters. I can observe these counters using another private tool and I suspect after a certain threshold things go bang.

The local cached data is encrypted using a key extracted from the mmeAuthToken. The mmeAuthToken is not cached by InflatableDonkey itself although traces may remain in various other locations (bash history files, NSA servers etc). If a new mmeAuthToken is generated the old cache is unusable at which point InflatableDonkey will rebuild it via another escrow exchange and newly generated device id/ uuid values.

There a few additional changes that need more work but their absence shouldn't be so problematic. I still suspect the largest contributor to threat is the rapid access of multiple accounts over a single/ limited IP pool. In this scenario the above measures are going to have limited impact.

[horrorho]

Ok. I've pushed the update along with others.

The caching mechanism only works when InflatableDonkey is used with mmeAuthTokens.

[horrorho]

Ok. I've had numerous complaints (now including one with threat of legal action sheesh) from certain developers who've implemented paid services using InflatableDonkey (often in combination with iLoot and PyiCloud scripts) and are struggling to understand why they are continually locking their customer accounts.

In all cases they've been hammering upwards of 1000 accounts a day through the same IP. They've not used mmeAuth tokens, so those accounts are going through Apple's authentication servers which don't take kindly to it. Combined with other services and poorly written scripts, some accounts are being repeatedly re-authenticated in excess of 20 times within a few minutes.

To avoid further confusion let me clarify that InflatableDonkey use is limited to users accessing their own backups. I will not be held accountable for developers implementing services with InflatableDonkey. It has had the label as proof of concept for the duration of it's existence.

Also please note the MIT license, in particular:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

I hate to sound bitter and this does only apply to a very small minority, most of you are entirely wonderful and lovely, but if you want to implement Reincubate style services then you'll need to bring the appropriate expertise to the table. Please do not underestimate the skill those guys have. Sending horrorho angry emails demanding she fix her 'broken' tool, for free mind you, is not the approach I suggest you take.

EDIT. Just to be clear, the offending developers are not represented in this (or other tickets). All here have been perfectly polite, understanding and supportive.

[macmade]

Thank you for your amazing work.
Love the MIT license quote. People should really pay more attention to license terms, and realise what OpenSource really means.

[zanaibshah]

We also are having a locking issue with our customer accounts as you describe. We are using InflatableDonkey and Pyicloud to deliver our services. Kindly inform us how we can resolve the matter of locking in it's entirety. Thank you and we are looking forward to your prompt reply.

[horrorho]

@zanaibshah Hi. I'm really sorry but as stated above InflatableDonkey is limited to users accessing their own backups. Please find alternative means of delivering your services.