Disable Keychain in iCloud on Mavericks

[mojo21221]

Hello all and thanks for taking the time to assist or be assisted from the response to this post. As we are moving toward rolling out Mavericks our security team has informed me that we need to disable the ability of our users to use Keychain in the Cloud feature of iCloud. I would like to be able to still allow our users to enable iCloud and use the other features that go along with it, just to disable the new keychain feature that is available in Mavericks. Has anyone else out there been tasked with this? I know multiple way to disable the use and or access to iCloud in Sys Prefs, but was hoping to keep some of the functionality that is still on the safer side of everyday functions.

[c0n0r]

I've brought this up with Apple, and sadly do not have a good solution. Both solutions they offered me, which I've used in the past and was dissatisfied with, aim to disable all of iCloud. As far as my investigation has uncovered, there is no way to perma-disable the one feature.

The first option, and the sloppier IMHO, is to use MDM to block access to the iCloud pane of System Preferences. This has several issues though:
- Users can still setup iCloud through the Internet Accounts pane of System Preferences, or through Mail, Messages, Contact, Calendars, Reminders, ... ... ...
- Since System Preferences restrictions via MDM is a white list, any 3rd party applications your users which to install, that have System Preferences panes (Box, Dropbox, Java, Flash, Flip4Mac, etc.) have to be pre approved by you in order to function fully (I suppose this could be an added benefit in some environments).
- As soon as you enable any MDM profiles around System Preferences, you likely will encounter odd issues. The show stopper for us was that non-bound users lost the ability to change their passwords.
- This doesn't block the feature, just access to the feature. Advanced users will find a way to circumvent it in the GUI, or can just import preferences from an unmanaged machine.

The other alternative Apple suggested would be to block all iCloud traffic at our firewall. The biggest issue I ahv eiwth this is that many of our users are remote employees and thus spend a lot of time outside the firewall.

Truth be told, I'm actually shocked that more enterprise installations are not more upset about this feature and making a huge stink about it.

[barnesaw]

@c0n0r

Truth be told, I'm actually shocked that more enterprise installations are not more upset about this feature and making a huge stink about it.

They are. Apple just doesn't care. Never has, never will.

The only answer, of course, is to make it an HR/Infosec/IT issue. If you are found to be using iCloud keychain, you are disciplined - up to or including termination.

[adkinsan]

Truth be told, I'm actually shocked that more enterprise installations are not more upset about this feature and making a huge stink about it.

Not making a big stink, but will not deploy Mavericks until we find a way to disable iCloud keychain.

[nessts]

if you disable iCloud don't you disable the keychain too?

[tkimpton]

Hi gus one way possibly may be to either use mcx or config profiles to control access the that preference pane. The only problem with that is every time you install a new preference pane in the system you have to update the management framework to allow it.

After a while it does become a bit of a pain

[nessts]

in 10.9 there is the choice of either allow pref panes or dont allow pref panes, new ones added when using the don't allow work now. of course you have to use 10.9 server, and it only works on 10.9 but it works.

[tkimpton]

@ nessts thanks thats good to know :)

[c0n0r]

Black-listing the iCloud pref pane doesn't block iCloud from being setup any one of a dozen different ways, including from applications like Mail, Messages, Reminders, ... ... ...

[tkimpton]

@c0n0r][/url Ah...bummer, didn't think of that. I think you guys are right, It will be a security concern and I've lamely ignored it up until now.

[nessts]

@c0n0r that is true, i suppose a good launch daemon to remove icloud preferences might be in order plus there is the don't save to iCloud profile the Mac Enterprise folks came up with.

[c0n0r]

@nessts I agree that a LaunchD process can undo SOME of the damage... but the moment the user turns on iCloud keychain, their domain name and password, not to mention pgp/gpg mail PRIVATE keys are uploaded to Apple. Sadly, by the time a process fires off to kill the settings, that worst of the damage is already done.

We've been working with Apple on this pretty heavily, but there remains no clear solution.

[c0n0r]

To make matters worse, Sam Keeley over at AFP548 just posted a security hole where you can easily get around System Preferences Panes blocked via Profiles.

http://www.afp548.com/2013/12/16/system-preferences-profiles-in-mavericks-plus-a-security-hole/

[mm2270]

I saw the other thread that mentioned this but hadn't had the chance to look until just now. Just FWIW, this vuln exists with the older MCX settings as well, presumably on all versions of OS X. I tested on 10.8.5 and was able to uncheck a greyed out Preference Pane (disabled with the EnabledPreferencePanes array in an MCX setting) and when I relaunched System Preferences I was able to select it from the View menu and it opened right up! Nice :(
So apparently this bug has existed for a long while now and was apparently just discovered.

I can't believe Apple doesn't see this as a security hole (according to Sam in the article). I knew about other easy workarounds if a user is an admin, but this seems to work even with a standard account. Oh boy… I see lots of school kids getting into any Preference Pane they want shortly.

The only good news if you can call it that, is Sam figured out a temporary workaround by managing the HiddenPreferencePanes key in the plist. That's at least something.

[evarona]

Forgive my ignorance as I haven't had a close enough look at this feature in Mavericks yet. And while I completely believe and empathize with you all about Apple's "this is how we do it, get on board or get out of the way" bravado, I did see the quote below from an Apple FAQ (http://support.apple.com/kb/HT5813?viewlocale=en_US)

Can I set up iCloud Keychain so that my data isn't backed up in the cloud? Yes. When setting up iCloud Keychain, you can skip the step for creating an iCloud Security Code. Your keychain data is then stored only locally on the device, and updates only across your approved devices. Important: If you choose to not create an iCloud Security Code, Apple will not be able to recover your iCloud Keychain.

I'm doubtful but I hope this somehow helps

[c0n0r]

@evarona It's not that the feature can't be disabled, it's a simple checkbox in the iCloud pane of System Preferences to disable it completely (or, through the process you outline). The problem is that there doesn't appear to be a way to ENFORCE it being disabled. I trust my users, but I also know that not all of them read everything I send, so I can't blindly trust that no one is going to enable this feature and thus undermine the security of the organization at large.

[mm2270]

@evarona][/url][/url, Yes, that can be done, but needs to be done by the user setting up iCloud. I don't believe there's any way to force that to happen in a management scenario. So now you're relying on your users, some which may have the attention span of a chipmunk, to pay attention to that and make the correct choice, assuming they even know they can make that choice.
I don't know, but, I doubt most security teams would get the warm and fuzzies knowing that.

I think in iOS profiles you can actually force data to not be backed up to iCloud. It would be real nice if Apple added a similar setting, via Profile say, that disabled syncing iCloud keychains to the cloud that can be pushed to OS X devices. But there is no such thing.

[evarona]

Ah, I see the point now. So we're back to all or nothing with iCloud. At our financial-based company we disabled iCloud completely, even blocked it at the proxy. It sucks because I love having my bookmarks synched across devices. (I tend to browse/bookmark on the iPad and then research more fully on the Mac.)

For us, it's a simple choice of convenience or "protect the brand". Sometimes it sucks but in this case choosing the latter is easier to for me manage and keeps the paychecks coming.

[mojo21221]

Perhaps someone else can get more creative than I with ~/Library/Preferences/MobileMeAccounts.plist I see it can be modified. Any thoughts on changing the Services Item 7 (Keychain_sync) report back url to 127.0.0.1? I tried just deleting it, however once I restarted it repopulated.

[MrP]

# Disable internet account plugins
##
if [ -e /System/Library/InternetAccounts ];
then echo Internet Plugins are enabled. Disabling sudo rm -rf /System/Library/InternetAccounts/*
fi

Might want to just delete the one for icloud, or move it, or whatever your management preference is.

[c0n0r]

iCloud accounts can be setup in any application that has native iCloud connectivity. Disabling the system pref only disables the most obvious route to set it up, and doesn't really increase security.

[adkinsan]

Early next year (at this point), I will be testing blocking or removal of /System/Library/CoreServices/Keychain Circle Notification.app, which seems to focus only on iCloud Keychain synchronization without affecting the other iCould apps. Of course, testing may tell another story. "Trust, but verify."

I'll post results here later this week.

[adkinsan]

So after removing the Keychain Circle Notification.app (compressed the app and left it on Desktop for the test), tried activating iCloud Keychain. The activation seemed to go well, but the console revealed a few entries to indicate :

1/2/14 8:35:40.318 AM secd[199] EnsureFreshParameters_block_invoke_2 SOSCloudKeychainSynchronizeAndWait: The operation couldn’t be completed. (SyncedDefaults error 1020 - Remote error : Network unreachable**)

1/2/14 9:52:05.450 AM secd[234] securityd_xpc_dictionary_handler WiFiKeychainProx[204] DeviceInCircle The operation couldn’t be completed. (com.apple.security.sos.error error 2 - Public Key not available - failed to register before call)

1/2/14 9:52:28.890 AM com.apple.launchd.peruser.502[151] (com.apple.security.keychain-circle-notification[286]) Job failed to exec(3) for weird reason: 2

We are also looking into the implications of blocking https://p-##-escrowproxy.icloud.com:443 (the ## indicates server numbers from 01 to 20, possibly higher) at the firewall level. As indicated in ~/Library/Preferences/MobileMeAcounts.plist, it is the listed ProxyURL for Keychain Sync.

[adkinsan]

Found it. Delete these files (we're doing it in the build with bash script):

#! /bin/bash

# Remove applications that allow iCloud Keychain synchronization
#Leave other iCloud services alone

sudo rm -rf /System/Library/CoreServices/Keychain Circle Notification.app
sudo rm -rf /usr/libexec/KeychainMigrator

This allowed iCloud Keychain to be activated on the local Mac, but did not pass any credentials across to other test devices, while Notes, Reminders, and Calendar items came through normally. It is important to run this script during the build, or at the least before a user logs onto the system. As C0n0r points out in this thread, once the keychain is synced, the damage is done.

We will be monitoring the building when 10.9.2 is introduced to see if the script needs to be added to remove the files once again.

[daniel_behan]

I see the two preference files in ~/Library/Preferences that indicate iCloud Keychain is in use: com.apple.security.cloudkeychain3.keysToRegister.plist has an UnlockedKeys string and MobileMeAccounts.plist has a true/false dictionary for KEYCHAIN_SYNC being enabled. I'm working on the correct PlistBuddy command to use in an Extension Attribute. I figure if I can correctly report on who turns it on, I'll just have InfoSec get the Smart Group notification and we'll put a policy in place that will have the end user contacted to turn it off and reset their password on the spot.

[daniel_behan]

I have an EA that checks to see if iCloud Keychain is enabled. I hope this helps:

#!/bin/sh

currUser=$( /usr/bin/who | /usr/bin/awk '/console/{ print $1 }' )

Keychain=$( /usr/libexec/PlistBuddy -c "Print Accounts:0:Services:7:Enabled" "/Users/$currUser/Library/Preferences/MobileMeAccounts.plist" )

echo "<result>$Keychain</result>"

[c0n0r]

An extension attribute to identify violators is fine and dandy, but at that point the damage is already done. Passwords can be changed easily enough, but certificates are a little harder to reissue and redistribute public keys for (especially when that can include email signing certs for both larger number of internal users and any external clients).

Contacts is in a similar state... sure, you can flag people that have violated policy, but they've already synced their contacts to the cloud, and smashed EU privacy law to dust.

[Bendelaat]

@daniel.behan][/url][/url i made a small change to the script so it tests for 10.9, otherwise there are false readings.

#!/bin/sh
OSVersion=$(sw_vers -productVersion)

if [ $OSVersion == 10.9 ]; then
    currUser=$( /usr/bin/who | /usr/bin/awk '/console/{ print $1 }' )
    Keychain=$( /usr/libexec/PlistBuddy -c "Print Accounts:0:Services:7:Enabled" "/Users/$currUser/Library/Preferences/MobileMeAccounts.plist" )
    echo "<result>$Keychain</result>"

else 
    echo "<result>False</result>"
fi

@adkinsan][/url][/url i'm seeing a broken keychain here when i delete the files you suggest. the keychain itself seems to work but the keychain.app won't open and eventually crashes. you see the same results?

[adkinsan]

@Bendelaat - Yes, we've noted that removal of the CloudKeychainProxy.bundle does not prevent the local keychain, but does prevent Keychain Access from launching. If this bundle is in place, iCloud Keychain seems to work fine with the other two removed (still testing on that).

Back to the lab.

[daniel_behan]

@Bendelaat Thanks for the update. I had a smart group scoped to the EA to only check for 10.9 machines, but that's a nice edit.

@adkinsan I tried your script and Keychain Access.app won't launch afterwards.

[Bendelaat]

as anyone tried something like Wireshark to determine if we can block it at the port it uses?

[krichterjr]

No expert here but it looks like the iCloud Keychain points to https://p04-escrowproxy.icloud.com:443. I'm not sure if/when this will change but you add an entry to the /etc/hosts file to point it back to 127.0.0.1.

This is one way of blocking it from syncing to the cloud. Obviously doesn't fix any damage that has already been done.

[adkinsan]

@krichterjr - You'll want to add entries for https://p01... through at least https://p20 (as many as we've seen), possibly more. Nice idea to edit the /etc/hosts file, thanks!

We have tested simply pulling out the iCloud Preference. This doesn't seem to have a ill effect, although more of a broadsword than a scalpel.

[krichterjr]

Here's a script I threw together that grabs the URL from that plist and the appends the hosts file. I'm sure the script could be cleaned up but this is what I put together.

#!/bin/sh

####################################################
#
# This script checks the url iCloud Keychain uses 
# and adds a record to the /etc/hosts file to point
# it back to itself.
#
# Written by: Kenny 1/17/14
#
#####################################################


# Get the current user.
currentUser=`ls -l /dev/console | cut -d " " -f4`
echo "$currentUser"

# Get the URL iCloud Keychain contacts 
iCloudKC=`defaults read /Users/$currentUser/Library/Preferences/MobileMeAccounts.plist | grep -A 4 "KEYCHAIN_SYNC" | grep "escrow" | cut -d ':' -f 2 | sed 's/[/]//g'`
echo "$iCloudKC"

# Append the /etc/hosts file
echo "127.0.0.1       $iCloudKC" >> /etc/hosts
echo "host file appended"

[c0n0r]

I seem to remember that /etc/hosts is no longer authoritative - if a fqdn can resolve by DNS but not etc/hosts it will still resolve.

Has anyone tried the /etc/hosts method and can confirm that iCloud is blocked? I also presume this will block all iCloud services, not just keychain, can anyone confirm?

[adkinsan]

Looking through ~/Library/Preferences/MobileMeAccounts.plist, each service resolves to a unique URL, making it potentially possible to manage individual services within iCloud assuming the proper .mobilemeconfig file can be crafted to specify some fields and allow others to be entered by the end-user.

[krichterjr]

After making this change, if I ping the url pulled from the plist file (in my case p04-escrowproxy.icloud.com) it responds from the IP (127.0.0.1) I assigned. It's my understanding that the computer would look to the /etc/hosts file before any DNS.

Now, I did read something about if it does not resolve with IPv4 it may try to resolve through IPv6. An additional entry could be added that looks something like this.

::1 XXXX-escrowproxy.icloud.com

[clrlmiller]

Probably not the best, but we've taken a more blunt approach. Our chief problem with iCloud is the KeyChain feature and DO NOT WANT user(s) passwords to be in escrow with Apple. Fellow JAMF/Casper admin adkinsan wire~sharked iCloud and found Apple's servers as using: https://p01-escrowproxy.icloud.com:443
The server(s) also appear to be clustered and using numbers running through at least p01...p20-escrowproxy.icloud.com:443

So far, Mavericks still refers to the /private/etc/hosts file and we've added several entries to the file to redirect network traffic going to Apple's escrow server(s), to instead go to IP# 0.0.0.0 Like this:

##
#Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost

# Block the following hosts
0.0.0.0 icloud.com
0.0.0.0 p01-escrowproxy.icloud.com
0.0.0.0 p02-escrowproxy.icloud.com
0.0.0.0 p03-escrowproxy.icloud.com
0.0.0.0 p04-escrowproxy.icloud.com
0.0.0.0 p05-escrowproxy.icloud.com
0.0.0.0 p06-escrowproxy.icloud.com
0.0.0.0 p07-escrowproxy.icloud.com
0.0.0.0 p08-escrowproxy.icloud.com
0.0.0.0 p09-escrowproxy.icloud.com
0.0.0.0 p10-escrowproxy.icloud.com
0.0.0.0 p11-escrowproxy.icloud.com
0.0.0.0 p12-escrowproxy.icloud.com
0.0.0.0 p13-escrowproxy.icloud.com
0.0.0.0 p14-escrowproxy.icloud.com
0.0.0.0 p15-escrowproxy.icloud.com
0.0.0.0 p16-escrowproxy.icloud.com
0.0.0.0 p17-escrowproxy.icloud.com
0.0.0.0 p18-escrowproxy.icloud.com
0.0.0.0 p19-escrowproxy.icloud.com
0.0.0.0 p20-escrowproxy.icloud.com
0.0.0.0 p21-escrowproxy.icloud.com
0.0.0.0 p22-escrowproxy.icloud.com
0.0.0.0 p23-escrowproxy.icloud.com
0.0.0.0 p24-escrowproxy.icloud.com

Unfortunately we can't use a wildcard entry like: *-escrowproxy.icloud.com in the /private/etc/hosts file, so listing two dozen servers is a crap shoot at hopefully blocking every server used we seen used so far and a few more. This should ~in theory~ work in the background to prevent the iCloud from connecting to escrow servers and uploading passwords. So, we've come up with a small .pkg with a "block.txt" file that contains the hostname(s) of Apple's servers as payload and a postflight script to append the text to the existing /private/etc/hosts file. Like this:

###################################
# Append a payload file (block.txt) # to the /private/etc/hosts file
###################################

# Make a copy of the original hosts file beforehand
cp /private/etc/hosts /private/etc/hosts.bkup

# Append the original hosts file with our hostname list in the block file
# Output the result to a new file titled newhosts
cat /private/etc/hosts - /private/etc/block.txt > /private/etc/newhosts

# Replace the original hosts file with our new appended version
mv /private/etc/newhosts /private/etc/hosts

# Remove the building files, but leave the bkup file alone
rm /private/etc/block.txt
rm /private/etc/newhosts

exit 0

Make sure to use Text Wrangler or something similar to ensure the block.txt file is in raw text with no extra formatting characters. Also make sure there is ONLY a carriage return after the last host-name entry. 10.7 and 10.8 don't seem to mind extra items after the list, but 10.9 is more picky. I'm sure somebody, somewhere has found a better solution than this. But it's all we've been able to scrap together so far. Comments welcome.

[c0n0r]

While you can't use wildcards in /private/etc/hosts, you can in your scripts... so why not, rather than backing uo the file and replacing it with your own, instead just insert the needed entries in a for loop. Without testing it, I would use something like:

#!/usr/bin/env bash

HostFile="/private/etc/hosts"
ditto -v "$HostFile" /private/etc/hosts.bkup
CurrentBlockHosts=$(cat "$HostsFile" | grep -c "icloud")
if [[ "$CurrentBlockHosts" -eq 25 ]]; then
    exit 0
elif [[ "$CurrentBlockHosts" -eq 0 ]]; then
    echo "##" >> "$HostFile"
    echo "# Block the following hosts" >> "$HostFile" 
    echo 127.0.0.1 icloud.com >> "$HostFile"
    for (( i = 1; i < 10; i++ )); do
        echo "127.0.0.1 p0$i-escrowproxy.icloud.com" >> "$HostFile"
    done
    for (( i = 10; i < 25; i++ )); do 
        echo "127.0.0.1 p$i-escrowproxy.icloud.com" >> "$HostFile"
    done
else
    logger "[iCloudBlocker] Found $CurrentBlockHosts iCloud entries"
fi
exit 0

[c0n0r]

Sorry, forgot to add... I would then set this to run via a Casper policy once a day/week/month/decade (the first logic branch ensures that once it's successfully modified a system it just exits gracefully, allowing you to scope to all systems). I would then make a second policy to look for entries in syslog containing "[iCloudBlocker]" to flag the machine for personal review as it's in some odd state that automation would have difficulty fixing.