krypted.com

Tiny Deathstars of Foulness

As promised, here’s the slide deck from my talk at MacAD.UK in London. Enjoy!

MacADUK_MDM_2017

February 7th, 2017

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

The “What’s New in macOS” page for Sierra (10.12) lays out a little known change that a colleague at Jamf was working on the other day (hat tip to Brock):

Starting in macOS 10.12, you can no longer provide external code or data alongside your code-signed app in a zip archive or unsigned disk image. An app distributed outside the Mac App Store runs from a randomized path when it is launched and so cannot access such external resources. To provide secure execution, code sign your disk image itself using the codesign tool, or distribute your app through the Mac App Store. For more information, see the updated revision to macOS Code Signing In Depth.

This is further explained in the equally misnamed “OS X Code Signing In Depth“:

If using a disk image to ship an app, users should drag the app from the image to its desired installation location (usually /Applications) before launching it. This also applies to apps installed via ZIP or other archive formats or apps downloaded to the Downloads directory: ask the user to drag the app to /Applications and launch it from there.

This practice avoids an attack where a validly signed app launched from a disk image, ZIP archive, or ISO (CD/DVD) image can load malicious code or content from untrusted locations on the same image or archive. Starting with macOS Sierra, running a newly-downloaded app from a disk image, archive, or the Downloads directory will cause Gatekeeper to isolate that app at a unspecified read-only location in the filesystem. This will prevent the app from accessing code or content using relative paths.

The gist is, if an app isn’t signed via the Mac App Store, Gatekeeper is going to limit the ability of the app to launch via “Gatekeeper Path Randomization.” Basically, treat an app from a mounted drive as if it were coming from a Safari download. There are a few ways to distribute app bundles or binaries that do not violate this. One is to sign a disk image that contains such an app:

spctl -a -t open --context context:primary-signature -v /Volumes/MyApp/MyApp.dmg

If spctl runs properly, you should see the following:

/Volumes/MyApp/MyAppImage.dmg: accepted source=mydeveloperid

In the above spctl command, we use the following options:

  • -a assesses the file you indicate (basically required for this operation)
  • -t allows me to specify a type of execution to allow, in this case it’s ‘open’
  • –context
  • -v run verbosely so I can build error correction into any scripts
  • –status while I don’t use status, I could do a second operation to validate that the first worked and use the status option to check it
  • –remove I also don’t use remove, but I could undo what I just did by doing so (or just deleting the dmg

For more on managing Gatekeeper from the command line, see http://krypted.com/mac-security/manage-gatekeeper-from-the-command-line-in-mountain-lion/.

Another method is to remove the lsquarantine attribute, which is automagically applied, using xattr as follows:

xattr -r -d com.apple.quarantine /Volumes/MyApp/MyAppImage.app

The options in the above use of the xattr command:

  • -r run recursively so we catch binaries inside the app bundle
  • -d delete the com.apple.quarantine bit

Xattr has a lot of different uses; you can programmatically manage Finder tags with it, http://krypted.com/mac-os-x/command-line-finder-tags/. To see the full xattr dump on a given file, use the -l option as follows:

xattr -l com.apple.quarantine MyAppImage.dmg

The output is as follows:

xattr: No such file: com.apple.quarantine
MyAppImage.dmg: com.apple.metadata:kMDItemDownloadedDate:
00000000 62 70 6C 69 73 74 30 30 A1 01 33 41 BE 31 0B A5 |bplist00..3A.1..|
00000010 70 D4 56 08 0A 00 00 00 00 00 00 01 01 00 00 00 |p.V………….|
00000020 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 |…………….|
00000030 00 00 00 00 13 |…..|
00000035
MyAppImage.dmg: com.apple.metadata:kMDItemWhereFroms:
00000000 62 70 6C 69 73 74 30 30 A1 01 5F 10 22 63 69 64 |bplist00.._.”cid|
00000010 3A 69 6D 61 67 65 30 30 31 2E 70 6E 67 40 30 31 |:myappimage.dmg@01|
00000020 44 32 36 46 46 44 2E 35 37 31 30 37 30 46 30 08 |D26FFD.571070F0.|
00000030 0A 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 |…………….|
00000040 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
00000050 2F |/|
00000051

This could be helpful when troubleshooting and/or scripting (or just way too much informations!).

Finally, if you’re an application developer, check out new API for App Translocation in the 10.12 SDK for <Security/SecTranslocate.h>  I guess one way to think of this is… Apple doesn’t want you running software this way any more. And traditionally they lock things down further, not less, so probably best to find alternatives to running apps out of images, from a strategy standpoint.

January 25th, 2017

Posted In: Mac OS X, Mac Security

Tags: , , , , ,

The codesign command is used to sign apps and check the signature of apps. Apps need to be signed more and more and more these days. So, you might need to loop through your apps and verify that they’re signed. You might also choose to stop trusting given signing authorities if one is compromised. To check signing authorities, you can use

codesign -dv --verbose=4 /Applications/Firefox.app/ 2>&1 | sed -n '/Authority/p'

The options in the above command:

  • -d is used to display information about the app (as opposed to a -s which would actually sign the app)
  • -v increases the verbosity level (without the v’s we won’t see the signing “Authority”)
  • –verbose=4 indicates the level of verbosity
  • 2>&1 redirects stderr to stdout
  • /Applications/Firefox.app/ – the path to the app we’re checking (or signing if you’re signing)

Then we pipe the output into a simple sed and get the signing chain. Or don’t. For example, if you’re scripting don’t forget a sanity check for whether an object isn’t signed. For example, if we just run the following for a non-signed app:

codesign -dv --verbose=4 /Applications/Utilities/XQuartz.app/

The output would be as follows:

/Applications/Utilities/XQuartz.app/: code object is not signed at all

January 12th, 2017

Posted In: Apps, Mac OS X, Mac OS X Server

Tags: , , , , , , ,

Prepare for your network administrators to cringe… I’ve spoken on these commands but never really put them together in this way, exactly. So I wanted to find a coworker on a network. So one way to find people is to use a ping sweep. Here I’m going to royally piss off my switch admins and ping sweep the subnet:

ping 255.255.255.255

Next, I’m going to run arp to translate:

arp -a

Finally, if a machine is ipv6, it wouldn’t show up. So I’m going to run:

ndp -a

Now, I find the hostname, then look at the MAC address, copy that to my clipboard, find for that to get the IP and then I can flood that host with all the things. Or you could use nmap… :-/

January 7th, 2017

Posted In: Mac OS X, Network Infrastructure

Tags: , , , , , ,

OS X Server stores most logs in files that are in the /Library/Logs/ProfileManager directory. Logs are split up between php, devicemgrd.log, scep_helper.log, servermgr_devicemgr.log, profilemanager.log and others. In my experience, if there’s a lot of errors at first, or if the service doesn’t work, just reformat and start over. But, once a server is in production, you don’t want to re-enroll devices after you do that. So, as with all good error prodding, start with the logs to troubleshoot.

By default the logs can appear a bit anemic. You can enable more information by increasing the logging level. Here, we’ll shoot it up to 6, which can be done with the following command:

sudo debugDeviceMgr 6

Debug levels go all the way to 9, but at that point things get… Noisy. And to turn it back off, use:

sudo debugDeviceMgr 1

Basically, this command sets the required services in /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/ to debug mode as well as /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/config/com.apple.DeviceManagement.postgres-debug.plist and /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/config/com.apple.DeviceManagement.postgres.plist to configure debug mode. In other words, it touches a lot of services. And given how chatty some can be, only leave logging levels higher than I’d say 2 in the event of short-term troubleshooting.

December 29th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , ,

So fun!

December 28th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security, MacAdmins Podcast, public speaking

Apple recently introduced a laptop with the same fingerprint technology found in an iPhone as well as a T-1 chip to take the sapphire Touch ID sensor information and store it securely, non-reversibly(ish), on the machine. OS X 10.12 now comes with a tool that can manage the fingerprints, stored as keys, on the device. The bioutil command is simple to use, with a few options that are mostly useful for enabling different features of the new technology.

Let’s get started by enabling the unlock option, using the -r option to see if Touch ID is enabled for the current user and -s to check the system as well:

bioutil -r -s

Now let’s enable Touch ID to be able to unlock the system, with -u (provided it’s not already enabled):

bioutil -u

If you’ll be using ApplePay, also use -a (on a per-user basis):

bioutil -a

Next, let’s enables Touch ID to unlock the system for the current user:

bioutil -w -u 1

This user will obviously need to provide their fingerprint in order to use Touch ID. Once done, let’s see how many fingerprints they’ve registered using the -c option (which checks for the number of fingerprints registered by the currently enrolled user):

bioutil -c

Now let’s delete all fingerprints for the current user (note that they’re not reversible so you can’t actually look at the contents):

bioutil -p

Next, we’ll use sudo to remove all fingerprints for all users (since we’re crossing from user land, we’ll need to provide a password):

sudo bioutil -p -s

Instead, we could have targeted just deleting the fingerprints that had been registered for user 1024, using -s and -d together, followed by the actual UID (which also requires sudo – as with all -s option combos):

sudo bioutil -s -d 1024

Now let’s disable Touch ID for the computer, using -w to write a config, and that -u from earlier, setting it to 0 for off:

sudo bioutil -w -s -u 0

And viola, you’re managing the thing. Throw these in an Extension Attribute or in Munki and you’re managing/checking/knowing/reporting/all the thingsings! Enjoy!

December 16th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security

Tags: , , , , , ,

The last JamfNation User Conference, or JNUC for short, was far and away the biggest and best. It was packed though, and given the year-over-year increase in people attending, the conference is being moved to the Hyatt Regency in downtown Minneapolis.

For more information on or to early-bird register for JNUC 2017, visit the official JNUC page.

screen-shot-2016-12-14-at-9-59-38-am

I’ll certainly be there, and I look forward to seeing all of you again and meeting all the newcomers this year, as well as getting a recording going of the MacAdmins Podcast while we’re all together!

December 11th, 2016

Posted In: JAMF, Mac OS X, Mac OS X Server, Mac Security, MacAdmins Podcast

macOS has keychains. Sometimes they’re a thing. When they are you might want to delete them. Let’s say you have an admin account. You want to keep the keychains for that account, but remove all the others. For this, you could do a shell operator to extglob. Or you could do a quick while loop as follows:

ls /Users | grep -v "admin" | while read USERNAME do; rm -Rf "/Users/$USERNAME/Library/Keychains/*" done;

If you borrow this, be careful.

December 1st, 2016

Posted In: Mac OS X, Mac Security

Tags: , , , ,

The logs for Outlook are… Interesting… Diagnostics are difficult without logs. They used to be at ~/Library/Containers/com.microsoft.outlook/ Data/Library/Logs/ or

To enable logs, open Outlook and then click on Window and then click Sync Errors.

screen-shot-2016-11-29-at-2-37-56-pm

From there, click on the cogwheel and then check the box for “Turn on logging for troubleshooting”

screen-shot-2016-11-29-at-2-40-03-pm

Now go ahead and quit Outlook and open it again. When prompted, click “Leave Logging On” and then when you get errors, open the logs.

screen-shot-2016-11-28-at-11-30-45-am

Once enabled, you’ll see logs at ~/Library/Group Containers/UBF8T346G9.Office/OfficeLogging/. You can edit a maximum size for the log files using defaults to send a EWSMaxLogLength key to com.microsoft.Outlook using the following command:

defaults write ~/Library/Preferences/com.microsoft.Outlook EWSMaxLogLength 64

November 30th, 2016

Posted In: Mac OS X, Microsoft Exchange Server

« Previous PageNext Page »