macOS now comes with a vulnerability scanner called mrt. It’s installed within the MRT.app bundle in /System/Library/CoreServices/MRT.app/Contents/MacOS/ and while it doesn’t currently have a lot that it can do – it does protect against the various bad stuff that is actually available for the Mac. To use mrt, simply run the binary with a -a flag for agent and then a -r flag along with the path to run it against. For example, let’s say you run a launchctl command to list LaunchDaemons and LaunchAgents running:
And you see something that starts with com.abc. Let me assure you that nothing should ever start with that. So you can scan it using the following command:
sudo /System/Library/CoreServices/MRT.app/Contents/MacOS/mrt -a -r ~/Library/LaunchAgents/com.abc.123.c1e71c3d22039f57527c52d467e06612af4fdc9A.plist
What happens next is that the bad thing you’re scanning for will be checked to see if it matches a known hash from MRT or from /System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara and the file will be removed if so.
A clean output will look like the following:
2018-09-24 21:19:32.036 mrt[48924:4256323] Running as agent
So you might be saying “but a user would have had to a username and password for it to run.” And you would be correct. But XProtect protects against 247 file hashes that include about 90 variants of threats. Those are threats that APPLE has acknowledged. And most malware is a numbers game. Get enough people to click on that phishing email about their iTunes account or install that Safari extension or whatever and you can start sending things from their computers to further the cause. But since users have to accept things as they come in through Gatekeeper, let’s look at what was allowed.
To see a list of hashes that have been allowed:
When you allow an app via spctl the act of doing so is stored in a table in
sudo sqlite3 /var/db/SystemPolicy
Then run .schema to see the structure of tables, etc. These include feature, authority, sequence, and object which contains hashes.
On the flip side, you can search for the com.apple.quarantine attribute set to com.apple.quarantine:
xattr -d -r com.apple.quarantine ~/Downloads
And to view the signature used on an app, use codesign:
However, in my tests, codesign is used to manage signatures and sign, spctl only checks things with valid developer IDs and spctl checks items downloaded from the App Store. None of these allow for validating a file that has been brought into the computer otherwise (e.g. through a file share).
Additionally, I see people disable Gatekeeper frequently, which is done by disabling LSQuarantine directly:
defaults write com.apple.LaunchServices LSQuarantine -bool NO
And/or via spctl:
Likewise, mrt is running somewhat resource intensive at the moment and simply moving the binary out of the MRT.app directory will effectively disable it for now if you’re one of the people impacted.
As I’ve mentioned previously, spctl is the command line tool to manage signing for Gatekeeper. This file edits the information stored in /var/db/SystemPolicy. Regrettably, this information can become corrupted (like all information in a database. And when it does, Apple has done us a favor by making a hidden default database with this information in the same directory, called .SystemPolicy-default.
To restore the default database, we just copy it over the top of the old one. Here, we’ll rename the old one first:
mv /var/db/SystemPolicy /var/db/SystemPolicyOLD
And then we’ll copy the defaults to make it the production database:
cp /var/db/.SystemPolicy-default /var/db/SystemPolicy
Then reboot and you should be good to go.
Encrypting a volume in OS X Mountain Lion couldn’t be easier. In this article, we will look at three ways to encrypt OS X Lion volumes. The reason there are three ways is that booted volumes and non-booted volumes have different methods for enabling encryption. The third way to enable encryption on a volume is to do so through
Encrypting Attached Storage
For non-boot volumes, just control-click or right-click on them and then click on Encrypt “VOLUMENAME” where the name of the volume is in quotes.
When prompted, provide an encryption password for the volume, verify that password and if you so choose, provide a hint.
Once the encryption process has begun, the entry previously clicked on says Encrypting “VOLUMENAME” where the name of the volume is in quotes.
Before you can encrypt a volume from the command line you must first convert it to CoreStorage if it isn’t already. As volumes on external disks aren’t likely to be CoreStorage, let’s check using diskutil along with corestorage and then list:
diskutil corestorage list
Assuming your volume was already formatted with a non-corestorage format and isn’t listed, locate the volume and document the disk identifier (in this case disk2s3). Then, run diskutil corestorage along with the convert verb and the disk, as follows (no need to run this command if it’s already listed):
sudo diskutil corestorage convert disk2s3
The output should look similar to the following:
Started CoreStorage operation on disk2s3 Reco
Resizing disk to fit Core Storage headers
Creating Core Storage Logical Volume Group
Attempting to unmount disk2s3
Switching disk2s3 to Core Storage
Waiting for Logical Volume to appear
Mounting Logical Volume
Core Storage LVG UUID: 19D34AAA-498A-44FC-99A5-3E719D3DB6FB
Core Storage PV UUID: 2639E13A-250D-4510-889A-3EEB3B7F065C
Core Storage LV UUID: 4CC5881F-88B3-42DD-B540-24AA63952E31
Core Storage disk: disk4
Finished CoreStorage operation on disk2s3 Reco
Once converted, the LV UUID (LV is short for Logical Volume) can be used to encrypt the logical volume using a password of crowbar to unlock it:
sudo diskutil corestorage encryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase crowbar
The output is similar to the following:
Started CoreStorage operation on disk4 Reco
Scheduling encryption of Core Storage Logical Volume
Core Storage LV UUID: 4CC5881F-88B3-42DD-B540-24AA63952E31
Finished CoreStorage operation on disk4 Reco
According to the size, this process can take some time. Monitor the progress using the corestorage list option:
diskutil corestorage list
In all of these commands, replace core storage w/ cs for less typing. I’ll use the shortened version as I go. I know that we rarely change passwords, but sometimes it needs to happen. If it needs to happen on a core storage encrypted volume, this can be done from the command line or a script. To do so, use diskutil cs with the changevolumepassphrase option. We’ll use -oldpassphrase to provide the old password and -newpassphrase to provide the new passphrase.
diskutil cs changeVolumePassphrase FC6D57CD-15FC-4A9A-B9D7-F7CF26312E00 -oldpassphrase crowbar -newpassphrase hedeservedit
I continue to get prompted when I send the -newpassphrase, so I’ve taken to using stdin , using -stdinpassphrase. Once encrypted there will occasionally come a time for decrypting, or removing the encryption, from a volume. It’s worth noting that neither encrypting or decrypting requires erasing. To decrypt, use the decryptVolume verb, again with the -passphrase option:
diskutil cs decryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase crowbarFileVault 2: Encrypting Boot Volumes
Boot volumes are configured a bit differently. This is namely because the boot volume requires FileVault 2, which unifies usernames and passwords with the encryption so that users enter one username and password rather than unlocking drives. To configure FileVault 2, open the Security & Privacy System Preference pane and then click on the FileVault tab. Click on the lock to make changes and then provide the password for an administrative account of the system. Then, click on “Turn On FileVault…”
When prompted with the Recovery Key, document it and then click on
Choose whether to restore the recovery key with Apple. If you will be storing the key with Apple then provide the AppleID. Otherwise, simply click the bullet for “Do not store the recovery key with Apple” and then click on the Continue button.
When prompted, click on Restart to reboot and be prompted for the first account that can unlock the FileVaulted system.
Once encrypted, the FileVault tab in the Security & Privacy System Preference pane shows the encryption status, or percent during encryption.
Use the Enable Users… button to enable additional accounts to unlock the volume (note: by default accounts cannot login until their account has been added here).
That’s it. Managing FileVault 2 using the System Preferences is about as easy as it can get. But for those who require mass management, Apple has provided a tool called fdesetup for that as well.
Using fdesetup with FileVault 2
FileVault 2 now comes with a nifty configuration utility called fdesetup. To use fdesetup to encrypt the boot volume, first check FileVault’s status by entering the fdesetup command along with the –status option (wait, no — required any more!):
As with most other commands, read the help page before starting to use just in case there are any changes to it between the writing of this article and when you kick off your automated encryption. Done using the help verb:
After confirming FileVault is off, enable FileVault with the enable option, as follows:
sudo fdesetup enable
Unless additional parameters are specified, an interactive session prompts for the primary user’s short name and password. Once enabled, a Recovery key is returned by the fdesetup command. You can also cancel this by just hitting Control-C so we can look at more complicated iterations of the command. It should be recorded or otherwise stored, something easily done by mounting in a script (e.g. a write-only share in a script for key escrowing). If more complicated measures are needed, of course check out Cauliflower Vest at code.google.com. As fdesetup is in its first version, I find it amusing that it’s actually 1.3 as indicated using:
Now, if you run fdesetup and you’ve deployed a master keychain then you’re going to have a little more work to do; namely point the -keychain command at the actual keychain. For example:
sudo fdesetup enable -keychain /Library//Keychains/FileVaultMaster.keychain
To define a certificate:
sudo fdesetup enable -certificate /temp/filename.cer
Adding additional users other than the one who enabled fdesetup is a bit different than the first:
sudo fdesetup add -usertoadd robin
To remove users, just remove them with a remove verb followed by the -user option and the username:
sudo fdesetup remove -user robin
The remove and add options also offer using the -uuid rather than the username. Let’s look at Robin’s uid :
dscl . read /Users/robin GeneratedUID | cut -c 15-50
Yes, I used cut. If you have a problem with that then take your judgmental fuc… Nevermind. Take that GUID and plug it in as the uuid using the -uuid option. For example, to do so with the remove verb:
sudo fdesetup remove -uuid 31E609D5-39CF-4A42-9F24-CFA2B36F5532
Or for good measure, we can basically replicate -user w/ -uuid for a nice stupid human trick:
sudo fdesetup remove -uuid `dscl . read /Users/robin GeneratedUID | cut -c 15-50`
All of the fdesetup commands can be run interactively or using options to define the variables otherwise provided in the interactive prompt. These are defined well in the man page. Finally, let’s look at -defer. Using -defer, you can run the fdesetup tool at the next login, write the key to a plist and then grab it with a script of some sort later. At logout, the user will get prompted for a
sudo fdesetup enable -defer /temp/fdesetupescrow.plist
Or define users concurrently (continuing to use the robin test user):
sudo fdesetup enable -user robin -defer /temp/fdesetupescrow.plist
FileVault accounts can also use accounts from Directory Services automatically. These need to synchronize with the Directory Service routinely as data is cached. To do so:
sudo fdesetup sync
This is really just scratching the surface of what you can do with fdesetup. The definitive source for which is the man page as well as a nicely done article by Rich Trouton (who I think I will start calling Trouty-mouth after having watched the Glee episode where one of the girls says that).
Encrypting Time Machine Backups
The last full disk encryption to discuss is Time Machine. To encrypt Time Machine backups, use Time Machine’s System Preference pane. The reason for this being that doing so automatically maintains mounting information in the Operating System, rather than potentially having an encrypted drive’s password get lost or not entered and therefore not have backups run.
To enable disk encryption for Time Machine destinations, open the Time Machine System Preference pane and click on Select Backup Disk… From the backup disk selection screen, choose your backup target and then check the box for “Encrypt backups”. Then, click on Use Disk.
At the overlay screen, provide a backup password twice and if you would like, a hint as to what that password is. When you are satisfied with your passwords, click on the Encrypt Disk button.
Now, there are a couple of things to know here. 1. Don’t forget that password. 2. If you use an institutional FileVault Key then still don’t forget that password as it will not work. 3. Don’t forget that password…
Encrypting data in OS X can take on other forms as well. The keychains encrypt passwords and other objects. Additionally, you can still create encrypted dmgs and many file types have built in encryption as well. But the gist is that Apple encrypts a lot. They also sandbox a lot and with the addition of gatekeeper are code signing a lot. But encrypting volumes and disks is mostly about physical security, which these types of encryption provide a substantial solution for.
While all this security might seem like a lot, it’s been in Apple’s DNA for a long time and really security is about layers and the Mac Systems Administrator batbelt needs a lot of items to allow us to adapt to the changing landscape of security threats. OS X is becoming a little more like iOS as can be expected and so I would suspect that encryption will become more and more transparent as time goes on. Overall, the options allow encrypting every piece of data that goes anywhere near a system. The mechanisms with which data is now encrypted are secure, as is the data at rest. Once data is decrypted, features like Gatekeeper and the application layer firewall supplement traditional network encryption to keep well secured.
Gatekeeper is the new feature of OS X that controls what types of apps can be opened. To configure Gatekeeper, open the Security & Privacy System Preference pane. Click on the General tab and unlock to make changes. Here, you’ll see “Allow applications downloaded from:” along with the following 3 options:
Mac App Store: Only apps downloaded from the App Store can be opened.
“Mac App Store and identified developers”: Only apps downloaded from the App Store and those signed can be opened.
Anywhere: Any app can be opened.
Configuring Gatekeeper is as easy as selecting one of these options. Now, under the hood, the state of Gatekeeper is kept in /var/db/SystemPolicy-prefs.plist. There’s only one option there, though: enabled. So you could try and run defaults to disable Gatekeeper: defaults write /var/db/SystemPolicy-prefs enabled no. However, doing so is not really going to provide all the options available in the GUI. To configure the options, Apple has provided spctl, a command line tool used to manage Gatekeeper. In it’s simplest form, Gatekeeper can be enabled using the –master-enable and –master-disable options, which are pretty straight forward. Use –master-enable to enable Gatekeeper:
And then use –master-disable to disable Gatekeeper:
Whether Gatekeeper (assessments) is enabled or disabled can be returned using the –status option:
The -a option is used to assess an application to see if it will open or not:
spctl -a /Applications/GitHub.app
If an application passes and has a rule available then you’ll get no response. If there’s no rule for the application, you’ll get a response that:
/Applications/GarageBuy.app: unknown error 99999=1869f
You add rules about apps using the –add option. Each app gets a label, defined with the –label option. For example, to add GitHub:
spctl --add --label "GitHub" /Applications/GitHub.app
To then enable access to GitHub:
spctl --enable --label "GitHub"
spctl --disable --label "GitHub"
As with most things, there’s actually a rub. spctl doesn’t always work. I’ve had more than a few issues with getting the labels to apply just right. Sometimes the -a will report back that an app is rejected and it will still open. I think this is first gen technology and that prior to relying on it that it would be a really good idea to test very thoroughly before deploying.