Securing the Platform

Compliance is a thing. In this book, we have covered (and continue to cover) how to get devices into a compliant state. But compliance means different things for different teams and different platforms. While the Apple platforms are similar, what you can do on iOS is much more limited and so the security threats are as well. As an example, this means you don’t use antivirus on iOS but can on macOS. In general, mobile devices are treated differently in organizations: you don’t assume they’re always on your network, you don’t expect access to the filesystem on the device so you plan workflows that are app driven, and on Apple platforms, you leverage MDM to do much of the heavy lifting to secure devices.

The Mac is very different. You can do practically anything you want on the device. In many ways, the Mac is becoming more iOS-like, but you can still disable SIP (System Integration Protection), which has been covered throughout this book, and do anything you want on a device. Apple produces a great guide to macOS security at www.apple.com/business/resources/docs/macOS_Security_Overview.pdf, and this chapter is meant as a technical journey through the basic security measures required by most organizations. This starts with the operating system but quickly becomes as much about apps and content as hardened systems that follow guidelines, like those issued by the National Institute of Standards and Technology in the United States, or NIST. NIST has made their compliance work open source at https://github.com/usnistgov/macos_security with assistance from agencies like NASA and the Pentagon.

With both Mac and iOS, many assume any software that goes through the App Store is safe. This is because Apple scans software to indicate that it is indeed safe. Now with App Notarization, Apple is scanning apps for security flaws. This service is currently optional (except for kernel extensions, or kexts), and if an app has been certified by Apple and signing matches Apple’s database, then Gatekeeper (described further later in this chapter) provides a special icon that the software is clean. As we cover later in the chapter, this is good for many, but not all, organizations.

Security is a trade-off. In general, the more secure a fleet of devices becomes, the less features are available on devices and/or the slower the device will run. For example, removing the ability to use iCloud is interpreted as some environments as improving security; however, without iCloud, many services work suboptimally. Most classic Apple users and administrators think “Apple has me covered” when it comes to security. Most classic IT departments think “we must lock down everything that makes anything cool.” And according to the type of data being stored on a computer, they may be correct. The answer for how much security is required to protect a device is somewhere in the middle and is entirely based on the security posture of any given organization.

Many organizations have anywhere between three and eight LaunchAgents and/or LaunchDaemons that run on a Mac. Given the types and number of vulnerabilities on the Mac as well as what frameworks are allowed to touch on the Mac, it is unimaginable that a customer would actually need to deploy all of those agents given that each can have an expensive load on system resources, with some taking up 10–30% of the CPU or memory on a computer. One is usually too few, four is too many. None should touch the kernel (and therefore should not be kernel extensions) because doing so can lead to unbootable devices, and most existing products do not provide for zero-day support.

Mac Security

The Mac includes a number of built-in security features, on both the system level and the user level. Two major components of these security features are the signed system volume and System Integrity Protection (SIP).

System Integrity Protection

Once the Mac is booted and running, System Integrity Protection (SIP) provides a security layer designed to limit the power of the root account on macOS.

The root account is the superuser for a Unix system, and the Unix permissions model is designed around the assumption that the root account has access to everything. To limit what the superuser can do and add another layer to the macOS security model, Apple developed System Integrity Protection (SIP) and first deployed it as part of OS X El Capitan. SIP is designed to limit the power of root and to protect the system, even from its own root user.

SIP is an overall security policy with the goal of preventing system files and processes from being modified by third parties. To achieve this, it has the following concepts:

• Filesystem protection

• Runtime protection

• Kernel extension protection

SIP prevents parties other than Apple from adding, deleting, or modifying directories and files stored in certain directories, including the following:

• /bin

• /sbin

• /usr

• /System

The preceding directories are required for the computer to boot properly, and not allowing users to alter them keeps the operating system safe. Because the software you install needs to go somewhere on the system, Apple has indicated that the following directories are available for developers to access:

• /usr/local

• /Applications

• /Library

• ~/Library

All directories in /usr except for /usr/local are protected by SIP, and third-party developers should not write to protected locations. It is possible to add, remove, or change SIP-protected files and directories via an installer package which is signed by Apple’s own certificate authority. This allows Apple to make changes to SIP-protected parts of the OS without needing to change the existing SIP protections (Figure 8-1).

A screenshot of a pop-up. It has a lock icon at the top left. There is a checkbox with the text, always trust software updates. There is an image of a certificate with the text, software update, issued by, apple software update certification authority. There are options for hiding the certificate and ok at the bottom.

The certificate authority in question is reserved by Apple for their own use; Developer ID–signed installer packages are not able to alter SIP-protected files or directories. To define which directories are protected, Apple has currently defined a configuration file, which is /System/Library/Sandbox/rootless.conf. This file is controlled exclusively by Apple and lists all the applications and top-level directories which SIP is protecting (Figure 8-2).

A screenshot of the listed pathways. The names are on the left and the location is on the right.

SIP-Protected Directories

SIP is also protecting a number of directories and symlinks outside of /Applications. Many of those directories contain frameworks, binaries brought in from other projects, and binaries that have always been a part of the Mac, since the inception of Mac OS X.

Some of those directories contain files that administrators need to access. So Apple has also defined some exceptions to SIP’s protection in the rootless.conf file (Figure 8-3), with those exceptions marked with asterisks. These exemptions from SIP’s protection mean that it is possible to add, remove, or change files and directories within those locations.

A screenshot of listed exceptions to S I Ps protection. Four of them are highlighted. Each has an asterisk on the left side and a location on the right.

Among those exceptions are the following, which many administrators or third-party software developers need access to:

• /System/Library/User Template: Where macOS stores the files and directories it uses when creating home folders for new accounts.

• /usr/libexec/cups: Where macOS stores printer configuration information.

• /usr/share/man: A number of third-party software developers and open source projects will write a man file so you can have a manual of what the software does.

View SIP Protections Interactively

To see which files and directories have been protected by SIP, use the ls command with the capital O flag in Terminal:

ls -O

As you can see in Figure 8-4, the output will list SIP-protected files and directories as restricted. This is a common troubleshooting step you’ll get used to if you have a lot of scripts that touch these folders, and you need to resolve issues that come up with them due to not being able to write to objects in those directories or remove them.

A screenshot of listed directories with highlighted S I P protected root level directories. The highlighted directories have the labels, restricted and restricted, hidden. They contain date and time.

An important thing to note is that even if a symlink (a symbolic link acts as a shortcut of sorts) is protected by SIP, that does not necessarily mean that the directory it’s linking to is being protected by SIP. For example, the root level of a macOS boot drive contains several SIP-protected symlinks pointing to directories inside the root-level directory named private. Usually, this means that if one of those symlinks were removed, it would cause problems with the device.

However, when the contents of the private directory are examined (Figure 8-5), the directories to which those SIP-protected symlinks point are not themselves protected by SIP, meaning those directories and their included files can indeed be moved, edited, or changed by processes using root privileges.

A screenshot of listed directories inside the private directory. The listed directories have the date and time on the right.

Managing System Integrity Protection

Because SIP’s configuration is stored in NVRAM, these settings will apply to the entire machine and will persist even if the OS is reinstalled. SIP can be managed to the extent of turning it on, turning it off, adding and removing IP addresses into a NetBoot whitelist, and reporting on whether SIP is enabled or disabled. All changes to SIP’s configuration settings also require a reboot before they take effect, and performing the changes without physically touching the computers will not be possible (and so you won’t be doing this en masse).

The response to the command includes the com.apple.private.iokit.nvram-csr key as shown in Figure 8-6.

A screenshot of the listed csrutil's application entitlement. One of the entitlements has been highlighted. It is, com dot apple dot private dot i o kit dot n v r a m dash c s r.

When you run csrutil without any associated commands, Terminal will respond with the help page. Here, you’ll see any options get guidance on how to use the available commands, as you can see in Figure 8-7.

A screenshot of csrutil's help page. It has the commands, clear, disable, enable, and status.

When run, you’ll receive a message that SIP was enabled, as seen in Figure 8-8.

A screenshot of terminal bash, csrutil enable. It has the text, system integrity protection is on. Restart the machine for the changes to take effect.

The message is almost identical, but states disabled instead of enabled (Figure 8-9).

A screenshot for terminal bash, csrutil disable. It has the text, system integrity protection is off. Restart the machine for the changes to take effect.

The resultant message doesn’t indicate that SIP is disabled or enabled, only that the state was cleared, as you can see in Figure 8-10.

A screenshot for terminal bash, csrutil clear. It has the text, successfully cleared system integrity configuration. Restart the machine for the changes to take effect.

When csrutil clear is run, SIP goes back to its factory-default settings. That means SIP is enabled if it was disabled previously and any custom configuration is cleared out.

Signed System Volume and csrutil

As of macOS Big Sur and later, Apple has moved the parts of the OS it can make immutable by moving them to the system volume of the boot drive. As discussed earlier, this volume is cryptographically sealed, and the seal is verified against tampering every time the Mac starts up. The csrutil command can report whether this seal verification process is enabled or not and also turn this verification process on or off from the Recovery environment.

To enable the seal verification, run the following command as seen in Figure 8-11:

csrutil authenticated-root enable

A screenshot for terminal bash, csrutil authenticated-root enable. It has the text, successfully enabled authenticated root. Restart the machine for the changes to take effect.

To disable the seal verification, run the following command as seen in Figure 8-12:

csrutil authenticated-root disable

A screenshot for terminal bash, csrutil authenticated-root disable. It has the text, successfully disabled authenticated root. Restart the machine for the changes to take effect.

Running csrutil Outside of the Recovery Environment

If you run the csrutil enable and csrutil disable commands when you aren’t booted into the Recovery OS environment, you will receive a message that these commands need to be run from the Recovery OS. The current SIP configuration will remain unchanged, as you can see in Figure 8-13.

A screenshot of username, % csrutil enable. It has the text, this tool needs to be executed from Recovery O S.

Likewise, if you try to run the csrutil authenticated-root enable and csrutil authenticated-root disable commands while booted from a regular boot drive, you will receive a message that these commands need to be run from the Recovery OS (Figure 8-14).

A screenshot of username, % csrutil authenticated-root enable. It has the text, this tool needs to be executed from Recovery O S.

What can be run while outside the Recovery environment are csrutil’s reporting functions. For example, to learn if SIP is enabled or disabled, run the following command:

csrutil status

This command can be run without root privileges and will display if SIP is enabled or disabled, as you’ll note in Figure 8-15.

A screenshot of username, % csrutil status. It has the text, System Integrity Protection status, enabled.

Similarly, csrutil authenticated-root status can be run to report on the status of the system volume seal’s verification check, as you can see in Figure 8-16.

A screenshot of username, % csrutil authenticated-root status. It has the text, Authenticated Root status, enabled.

So you can programmatically derive information about SIP, but you can’t augment SIP when booted to the standard operating system. Now that we’ve covered getting SIP turned on and off, it’s worth noting that the enable options have more granular settings, usually invoked with a -- in the command.

Custom System Integrity Protection Configuration Options

It is possible to enable SIP protections and selectively disable aspects of it, by adding one or more flags to the csrutil enable command. All the following examples require being booted from Recovery in order to successfully configure.

To enable SIP and allow installation of unsigned kernel extensions, run the csrutil command with the enable verb, but then use the --without option and use the kext selection for what to disable:

csrutil enable --without kext

When this option is enabled, running csrutil status outside the Recovery environment should produce output similar to this, indicating that Kext Signing is disabled, as you can see in Figure 8-17. This isn’t to say that signed kexts can’t be run but instead that forcing signed kexts in order to run a kext has been disabled.

A screenshot of username, % csrutil status. It has the text, System Integrity Protection status, unknown. The configuration has apple internal and kext signing disabled with the rest enabled.

If you need to write to those protected directories we reviewed earlier in the chapter (whether you need to is very arguable), then you’ll need to disable Filesystem Protection. To enable SIP and disable Filesystem Protections, run the enable option for csrutil, with the --without option again, and then indicate fs instead of kext:

csrutil enable --without fs

When this option is enabled, running csrutil status should produce output similar to Figure 8-17 but with the Filesystem Protections set to disabled. You can also disable the debugging restrictions. To keep SIP enabled but disable debugging restrictions, run the same command as before but use debug as your option:

csrutil enable --without debug

When this option is enabled, running csrutil status will show Debugging Restrictions set to disabled. A common task is to disable DTrace restrictions so you can run dtrace commands and scripts. To leave SIP enabled but disable the DTrace enforcement, run the same command but use dtrace as the option to start SIP without, as follows:

csrutil enable --without dtrace

When this option is enabled, running csrutil status should produce a similar output but with the DTrace Restrictions listed as disabled. Many administrators will want to customize NVRAM options (e.g., to bless NetBoot servers). To enable SIP and disable restrictions on writing to NVRAM, run the same command but use the nvram option:

csrutil enable --without nvram

When this option is enabled, running csrutil status should produce output similar to the previous few iterations of the command, but with NVRAM Protections showing as Disabled. To enable SIP and disable basesystem verification, which will allow the use of a modified disk image to install macOS, run the command again but use basesystem as the exclusion:

csrutil enable --without basesystem

When this option is enabled, running csrutil status should produce a similar output but showing BaseSystem Verification set to disabled. These commands allow you to access specific options while still leaving SIP enabled. If you have to access those, try to do so granularly so the deployment still makes use of the added security features from running with SIP enabled on the fleet, and do so only for machines you have to. For example, try to only disable the nvram protections if you have a lab that you’d like to run with the option to boot into a NetBoot environment.

System Integrity Protection and Resetting NVRAM

As mentioned previously, SIP stores its active security configuration in NVRAM. This allows SIP’s configuration to persist across OS installs, but this design choice also means that resetting NVRAM will cause SIP’s configuration to reset as well. In my testing, a NVRAM reset will result in the following SIP configuration:

• SIP will be enabled with all protections in place.

• No entries will be set in the NetBoot whitelist.

Resetting the NVRAM, otherwise known as a PRAM reset or PRAM zap, has been a standard part of the Mac troubleshooting toolkit for a long time, but the process is different depending on if you’re using an Intel Mac or an Apple Silicon Mac.

For Intel Macs, a PRAM reset is performed by pressing and holding down the Option, Command (⌘), P, and R keyboard keys at startup (Figure 8-18). You can verify this worked because the startup tone will change.

An illustration of an Apple keyboard. The keys, R, P, Option, and Command have been highlighted.

For Apple Silicon Macs, you will need to boot to the Recovery environment. When booted from the Recovery environment, run the following command as shown in Figure 8-19.

nvram -c

A screenshot of terminal bash. It has n v r a m dash c command.

For environments that do not plan to change SIP’s default configuration, NVRAM resets should not affect normal operations. However, for those environments where custom SIP configurations need to be maintained, be advised how this change affects SIP configuration in your environment.

User-Level Protections

The final type of protection we’ll cover is user-level protections. Introduced as a part of the entitlement framework in macOS Mojave, these protections are managed by Apple’s expanded security framework, Transparency Consent and Control (TCC). These new protections are primarily focused on protecting data within a user’s home folder, but also affect access to the Mac’s built-in camera and microphone.

In order for applications to be able to access those protected areas, they must be approved either manually or by using a management profile. For more information on using a profile to manage privacy protections, please see Chapter 4. To show an example of an application which would legitimately need access to protected areas would be a backup solution. To manually approve a backup application to access all data stored in an account’s home folder, including protected data, the following procedure is used on macOS Mojave:

1. 1.

   Open System Settings.

    
2. 2.

   Select the Privacy & Security preferences.

    
3. 3.

   Click the Full Disk Access settings.

    
4. 4.

   Add the application to the Full Disk Access section as you can see in Figure 8-20.

    

A screenshot of a window. It has a search bar at the top left with several tabs below it. The tab for privacy and security has been selected. The right side has full disk access. It has the Terminal option with the toggle button turned on.

The Location Services, Contacts, Calendars, Photos, Camera, Microsoft, and other items that are covered by the privacy controls are configured in the same manner and represent the most likely places where a third-party developer will want to access information that an end user should be prompted to allow.

Privacy is an increasingly visible aspect of security, but there are a number of things that the industry has been doing for a long time. Many administrators are accustomed to scanning software on a computer for vulnerabilities. We’ll move on to doing so in the next section of this chapter.

Detect Common Vulnerabilities

Rather than typing all of that should you need this, copy it from https://github.com/krypted/maccvecheck.

Adding a bit more logic, you could then build a similar script that checks all items in /Applications. Ultimately, Apple has a number of products that are tracked in the cve database, and a library of each could easily be built and parsed to produce all cve hits encountered on a Mac. The number of products you would need to scan seems to go down every year. Obviously, you might not want to trust some random site from Luxembourg, and you can do this directly against the zip from Mitre or create your own microservice that responds similarly to this site. For the purposes of this book, we used the public-facing API, so we didn’t need to parse the json files distributed by Mitre. Now that we’ve looked into vulnerability scanning, another common practice (and therefore a checkbox in your security assessment forms) is managing the firewall.

Manage the macOS Firewall

To see a list of apps the firewall has been configured to work with, use the –listapps option. You can also use the socketfilterfw command to sign applications, verify signatures, and enable debugging. Finally, there are a number of global preferences for the firewall that can be configured using the /usr/libexec/ApplicationFirewall/com.apple.alf.plist preferences file. You might be looking at the path to this file and think that it looks odd and it should really be in /Library/Preferences. And you might be right. Some keys in this file that might be of interest include globalstate (0 disables the firewall, 1 configs for specific services, and 2 is for essential services – as in the GUI), stealthenabled, and loggingenabled. All are integers and fairly self-explanatory vs. GUI settings from the System Preference pane.

Firewalls are one layer of security; the next we’ll cover is malware.

Combat Malware on macOS

One of the security requirements handed down by many an information security team that has seemed controversial since before macOS even is antivirus. In previous books, we tried to explore what the difference is between a virus, trojan, logic bomb, worm, backdoor, zombie, retrovirus, macrovirus, rootkits, etc. But here, we’ll just call it all malware. It’s something bad on the computer, and we need to scan for it routinely and correct it when found. Most malware that gets on an Apple device can’t actually hurt the device; instead, the device ends up sending infected files to other computers that the malware can actually affect. Or at least that was the perception in previous decades and is mostly still true for iOS.

Mac malware can be dangerous though. When it is, you’ll need a way to limit the impact and remediate. There are tons of great options to buy mature antivirus tools on the market. Apple has also provided a number of built-in tools, and for some, those will suffice to satisfy a CISO. We’ll start by covering XProtect.

XProtect and Gatekeeper

Gatekeeper is often used as a term to cover a number of different technologies. The first we’ll cover is XProtect, a tool built into macOS that is meant to protect the operating system by detecting various viral signatures and reacting to them by blacklisting that signature. Apple doesn’t add items to this list often, as there aren’t a lot of things that need to be added. If your organization requires the use of an antivirus tool, the first question you should answer is “will XProtect be sufficient?” The answer will often be no, but it’s worth understanding what XProtect is and how it works.

The signatures that are installed by default can be found in the /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Xprotect.plist property list, which includes a wonderful list of malware items that Apple has automatically decided you should not run on your computer. This allows other developers to extend signatures by adding more items into the XProtect.plist in Security Updates, or Apple may choose to deploy more items in subsequent software updates.

The great thing about XProtect is that it’s already running on the Mac and covers a number of different threats to the system by scanning files as they’re opened and then identifying those deemed dangerous. This means you’re not creating additional load on a computer during traditional antivirus scans, and you’re not going to hold up the deployment of new operating systems while testing if something works. XProtect is configured using Gatekeeper, a System Preference used to configure a few basic security options. To view and configure Gatekeeper settings, use the Privacy & Security System Settings pane, scroll down to the Security section, and choose whether your device will only allow App Store apps or whether to allow those from the “App Store and identified developers” as seen in Figure 8-21.

A screenshot of a window. It has a search bar at the top left. There are several tabs below it. The tab for privacy and security has been selected. The right side has the sub-tab for security. It has the selected option for app store and identified developers.

Gatekeeper is enabled by default, and configuring Gatekeeper is as easy as selecting one of these options. There’s much more that can be done under the hood. The state of Gatekeeper is kept in /var/db/SystemPolicy-prefs.plist. There’s only one option there, though: enabled. You can run defaults to manage the status of Gatekeeper with the command line via the spctl binary. To enable:

sudo spctl –master-enable

Or to use --master-disable to disable Gatekeeper:

spctl --master-disable

Whether Gatekeeper (assessments) is enabled or disabled can be returned using the --status option:

spctl --status

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 don’t want users to just start clicking to accept screens, so, when possible, add the rules on behalf of users. To add rules about apps, use 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"

Or to disable an app:

spctl --disable --label "GitHub"

As with most things, there’s actually a rub: spctl doesn’t always work. There have been more than a few issues with getting the labels to apply properly. Sometimes, the -a will report back that an app is rejected and yet the app will still open, so build some sanity checking into any scripts when managing app labels. When you encounter problems with spctl, file a radar with Apple. Gatekeeper is more fully documented at https://support.apple.com/en-us/HT201940. To understand some of the underpinnings though, we’ll look at lsquarantine in the next section of this chapter.

lsquarantine

Gatekeeper works by scanning files that have been downloaded from the Internet, as we mentioned in the previous section. Deciding what files are allowed to be opened and what aren’t, as well as prompting users is handled using lsquarantine, Spotlight works very quickly because it maintains an index of metadata attributes. The lsquarantine tool works similarly. There is a set of attributes attached to any files downloaded from the Internet, and on opening a special screen appears, which can be seen in Figure 8-22.

A screenshot of a pop-up for quarantined apps. It has text, Google Chrome is an app downloaded from the Internet. Are you sure you want to open it? There are buttons for cancel and open at the bottom.

Any file downloaded from external sources (such as email attachments) attaches quarantine attributes, including Safari, Messages, HipChat, etc. These attributes include date, time, and a record of where the file was downloaded from. When you open a file received through a quarantine-aware application, macOS warns you where the file came from. You receive an alert asking, “Are you sure you want to open it?”

For more on how lsquarantine works under the hood, see https://developer.apple.com/documentation/foundation/urlresourcevalues/1792021-quarantineproperties. But let’s look at those attributes, given how important they are.

If you have multiple user accounts on your Mac, the user account that downloaded the file is the only user account that can remove the quarantine attribute on a file. All other user accounts can open a quarantined file, but they are still presented with an alert asking, “Are you sure you want to open it?” every time they open the file.

While a lot of focus is put on malware and privacy, the most substantial risk to most computers is a binary running persistently. Most malware will want to run in such a way. A lot of services run on a Mac and most are built by Apple, so can be identified as com.apple.something. We cover kexts, LaunchAgents, and LaunchDaemons in this book. But in the next section, we’ll look at manipulating the Launch Services database to find and isolate a foreign persistent service based on it being registered to open a given file type.

Changing File Handlers

To set a specific application to open a file type, use the Get Info dialog (Command-I when clicked on the file type). This dialog has a section for “Open with:” as seen in Figure 8-23.

A screenshot of dump dot t x t info window. It has a tab to add tags at the top with a tab for comments at the center. There is a table for name and privilege at the bottom.

Click the option list for opening the file and then use the Change All button to set the behavior from just that instance of the file type to all instances of the file type. You can also set the default application for a network protocol (e.g., smb://, rdp://, vnc://, http://, and https://). Because the options for lsregister leave one wanting in some ways (the commands to set file types to a specific application are a bit overly complicated one could argue), there is an awesome front-end app for older operating systems from Andrew Mortensen, aptly called duti, available at http://duti.sourceforge.net/index.php. With duti installed, the command to set the default browser for http would be

/usr/local/bin/duti -s com.apple.safari http

Finally, there’s a lot that Launch Services does and is involved in. For more information on Launch Services, check out the Apple developer library entry for Launch Services at https://developer.apple.com/library/archive/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCIntro/LSCIntro.html.

MRT

macOS also comes with a vulnerability scanner called mrt. The mrt binary is installed inside 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. The mrt binary is based on Yara, an open source tool that searches for complex patterns, perfect for finding files that meet a known signature or other condition, such as malware.

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:

launchctl list

The list is a long listing of every LaunchAgent and LaunchDaemon running. Let’s say there’s something that starts with com.abc. Be assured that nothing should ever start with that. So it can easily be scanned with the following command:

/Library/Apple/System/Library/CoreServices/MRT.app/Contents/MacOS/MRT -a -r ~/Library/LaunchAgents/com.abc.123.c1e71c3d22039f57527c52d467e06612af4fdc9A.plist

The preceding command works for Big Sur and above, but previous versions might use

sudo /System/Library/CoreServices/MRT.app/Contents/MacOS/mrt -a -r ~/Library/LaunchAgents/com.abc.123.c1e71c3d22039f57527c52d467e06612af4fdc9A.plist

What happens next is that the potentially bad thing to scan will be checked to see if it matches a known hash from MRT or from /private/var/db/SystemPolicyConfiguration/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

2018.09-24 21:19:32.136 mrt[48924:4256323] Agent finished.

2018.09-24 21:19:32.136 mrt[48924:4256323] Finished MRT run

Yara rules are documented at https://yara.readthedocs.io/en/v3.8.0/. For a brief explanation of the json you see in those yara rules, see https://yara.readthedocs.io/en/v3.5.0/writingrules.html. Apple can update the yara rules silently.

A user would have had a username and password for most malware to run properly. XProtect with mrt protects against hundreds of file hashes that include over 100 variants of threats. Those are threats that Apple has effectively publicly acknowledged for the Mac based on their inclusion in Apple-supplied files. Most malware is a numbers game. The attacker needs to get enough people to click on a phishing email (e.g., one that looks very legitimate about their iTunes account), and the attacker can start sending things from their computers to further the cause provided they can make the message seem credible enough to accept.

The mrt binary runs somewhat resource intensive at the moment, and a common troubleshooting step is simply moving the binary out of the MRT.app directory, a heavy-handed way to disable mrt. All of this leads to Gatekeeper, XProtect, and mrt not covering the possible threats a third-party tool might cover. However, there are some tools that wrap mrt into graphical interfaces. One is DetectX from Phil Stokes of SentinelOne (Figure 8-24).

A screenshot of the detect X window. There is the logo of detect X swift at the top with a status bar below it. There are 3 boxes for the options, search, profile, and history.

The XProtect and bundle information is stored in the CFBundleShortVersionString field in /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Info.plist and can be checked with the defaults command as follows:

defaults read /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Info.plist CFBundleShortVersionString

This can be used with an agent to make sure the XProtect information is up to date. MRT can also be checked with the same key but in the /Library/Apple/System/Library/CoreServices/MRT.app/Contents/Info.plist file as follows:

defaults read /Library/Apple/System/Library/CoreServices/MRT.app/Contents/Info.plist CFBundleShortVersionString

These tools are not sufficient for most compliance needs, and so third-party tools like Symantec, Sophos, SentinelOne, Jamf Protect, and others are often employed instead. Another default protection on the Mac that we’ve covered is the fact that all apps need to be signed (and many notarized).

Threat Management on iOS

There are plenty of threats of any kind of device; however, iOS is more secure than most. As with securing a Mac, start with the Apple security guide at www.apple.com/business/resources/docs/iOS_Security_Overview.pdf and determine what gaps your organization might have. For the most part, keeping devices running the latest operating system, make sure to have a passcode on devices (or Touch ID or Face ID) and make sure your servers encrypt communication to and from devices. Some organizations will also look to containerization technologies and restricting features of devices. Make sure to go through each restriction available with an information security team and check which correspond to an organization’s security posture. This will keep you from starting to think that iOS is immune from any external threats.

YiSpecter was the first iOS malware to infect jailbroken and nonjailbroken phones by abusing private APIs in the iOS system. The malware spread via hijacked traffic from nationwide ISPs within China and Taiwan, an SNS worm on Windows, and an offline app installation and community promotion. YiSpecter contains four components signed with enterprise certificates. Abusing the APIs allows these components to download from a server and install on a targeted iOS device. Three of these components hide their icons, preventing the user from finding and deleting them. After infection occurs, iOS apps can be downloaded, installed, and launched; existing apps can be replaced with other apps; apps can be hijacked to display advertisements; Safari’s default search engine can be changed; and device information can be sent to the C2 server. YiSpecter is capable of maintaining persistence on the device and can defeat attempts to delete it. Abusing private APIs allows even iOS users who only download apps from the official App Store to be infected with YiSpecter.

All of these are basically about intercepting communication and not attacking an actual device. There have been small attacks that involved brute forcing the device when plugged into a computer, but nothing very successful. Many organizations will not need a tool for their iOS deployments. If you do, start the hunt for a vendor that does real things at Zimperium and Cylance and do a thorough review of what protections each provider offers as compared to those your organizational security posture requires. Things to look for might be a demo of them blocking a real-world example of an exploit.

Additionally, phishing is one of the top threats for the iOS and iPadOS devices. This is where ZTNA and other zero-trust solutions become important for most environments. These are often provided by companies like Palo Alto, the Citrix Zscalar, and Cisco. There are some that are fairly Apple-centric, like Jamf Private Access and Jamf Threat Defense, which was built based on Jamf’s acquisition of Wandera. All of these tools require routing data from a device to a server like how proxies and VPNs work. These protect network access but don’t typically help with binaries that can run on devices, which is more an issue with the Mac.

macOS Binary Whitelisting

By default, only binaries loaded through the App Store or installed via an ipsw can be opened on an iOS device and Apple TV. The Mac is much more open, even though it has been closing down more and more in the past few years. Of the binaries that can be opened on a Mac, you can limit them using what is known as binary whitelisting or binary blacklisting.

There are a few techniques for managing which binaries can be opened on Apple devices. The original technique to manage binaries, which still mostly works, but is actively being deprecated, was using MCX, or Managed Client Extensions. The easiest way to describe how this worked was with the now defunct Workgroup Manager, seen in Figure 8-25. More modern techniques include

• Gatekeeper, which was covered earlier in this chapter, which can be managed through the command line, through a Privacy & Security configuration profile manually, or via MDM

• Editing the permissions to remove access to an app either manually through the Finder or using a script

• Using a Restrictions profile through MDM or installed manually (only covers certain Apple apps)

• Using a third-party LaunchDaemon or agent that can terminate apps which have been blacklisted

• Blocking the installation of a given application, as is done with Munki (https://github.com/munki/munki/wiki/Blocking-Applications)

A screenshot of the workgroup manager local window. The left section has a search bar with the group name below it. The section to the right has the selected applications option. It contains a list of applications with the text, always allow these applications, at the top.

As seen in the preceding screen, it’s possible to whitelist only the Applications a given user should be able to launch. If this is something you need to do and you want to do so sanely, then consider Google Santa. Available at https://github.com/google/santa, Santa is a project that uses a kernel extension to monitor for the execution of a blocked binary and then terminates it.

A screenshot of Google Santa. It has the name of the application, path, publisher, identifier, parent, and user. There are buttons for the next steps and dismiss at the bottom.

This is one of those rare places where a kernel extension is necessary to shut down a binary before it could potentially do harm to a system or the network environment a system is in. As can be seen in Figure 8-26, Santa reacts so quickly that a notice can be displayed indicating that access to an application has been blocked.

The reason we said “sanely” is because a large user base is likely to run a lot of software you don’t know about. So prior to deploying a tool like Santa, you’ll likely define all of the software allowed to be run on your fleet only to end up having to pull back your spiffy new whitelisting solution because users are angry about it. Upvote is another Google tool available at https://github.com/google/upvote that allows users to submit apps to be whitelisted, and then when an app has had enough votes, the app is whitelisted. This allows users to self-manage what software is allowed en masse.

Reverse Engineering

The documentation provided by any vendor about their software only goes so far. Apple has some pretty solid documentation, but when it comes to security research, the ability to decompile, disassemble, and trace signals sent by software is important. There are entire books on these topics – and most of the techniques are similar enough between Windows, Linux, and macOS. And therefore, some of the tools are easily used, or ported, between the platforms, especially the open source tools.

As an example of these low-level similarities, most computers use a 64-bit version of x86 architecture, and most mobile devices use a variation of ARMv8. Different implementations of ARM and x86 have their own modes and formats, but in general reverse engineering is done using similar tools (if not the same tools). macOS seems more and more built for software developers with every passing year.

There are a number of these tools that are well documented, including the following:

• Class-dump is a tool used to view Objective-C runtime information stored in Mach-O files. Seeing class declarations and headers provides you with a lot of information about what a file is doing. Class-dump can be found at http://stevenygard.com/projects/class-dump/ and represents one of the better tools to locate private APIs in macOS.

• codesign: Command-line tool built into macOS that outputs extremely granular information about signatures used to sign code and installation packages.

• dtrace: Short for dynamic tracing, dtrace (built into macOS) can show anything you can build a program to access using the D programming language. For example, you can get as finely grained as a script that outputs the arguments used calling a function. You can only do this with SIP disabled, but then, you can only do reverse engineering on an iOS device if you’ve jailbroken the device.

• Hopper Disassembler (Figure 8-27) is a solid tool for translating machine language into assembly. Hopper isn’t going to show you the raw code for compiled files, but can help you find files and information that points you in the right direction during research.

• IDA is short for Interactive Disassembler and should be reserved for highly complex research tasks. IDA is available at www.hex-rays.com/products/ida/.

• lldb: Built-in macOS lldb debugger library interface (if you call one of these tools a debugger or a reverse engineering tool is really determined based on your profession).

• Lulu (https://objective-see.com/products/lulu.html) and Little Snitch (www.obdev.at/products/littlesnitch) both prompt and provide information about egress and ingress network connections.

• MachOView provides a view into Mach-O files using a GUI but hasn’t been updated for some time so suffers from stability issues. To download the latest version, see https://github.com/gdbinit/MachOView.

• nm: Built-in tool for viewing names and symbols in Mach-O executables.

• otool: Command-line tool built into macOS that shows dependencies (based on what frameworks were included in a piece of software which can be seen using the -L option) and allows you to view raw Mach-O executables. To find all apps dependent on a given binary, see https://github.com/krypted/looto.

• Task Explorer: Free tool to receive really detailed information about processes running on a Mac, https://objective-see.com/products/taskexplorer.html.

A screenshot of Firefox dot h o p window. The left section has a search bar with address, type, and name below it. The right section has the file information, address information, navigation information, navigation history, instruction encoding, graphic views, format, and comment.

Perhaps we’ll write a book about reverse engineering someday because we used so many more tools and products to write this book, but the best way to get started would be to download some of these tools and start playing around or try to answer a specific question, like installing some malware (you can find plenty of samples to play with at https://objective-see.com/malware.html) on a virtual machine and start trying to figure out what it’s trying to do, by reading source code, taking it apart, and watching signals.

Beyond reverse engineering, there’s an emerging discipline for iOS known as threat hunting. This is the act of looking for malware or other threats on the Mac. MonitorKit, from Digita Security (https://digitasecurity.com) is an event-driven macOS monitoring framework, written in Swift (compatible with Objective-C), that gives developers easy-to-use access to a wide array of native macOS monitoring capabilities.

MonitorKit minimizes the complexity of using the native macOS APIs while maximizing event details with its comprehensive data model. Underlying the MonitorKit framework are OpenBSM, FSEvents, Spotlight Notifications, Event Taps, IOKit, and CoreMedia. It builds upon code samples and proven techniques for accessing system event streams from experts such as Jonathan Levin (http://technologeeks.com/course.jl?course=OSXRE) and Patrick Wardle (https://Objective-See.com). As you can see in Figure 8-28, MonitorKit has a number of options for events it can track out of the box.

A screenshot of the Monitor Kit. The bar at the top has the icons for process, file, download, screen capture, webcam, mic, keylogging, login, U S B, and synthetic clicks.

Jamf Protect is Endpoint Detection and Response (EDR) tailor-made for macOS, built on top of MonitorKit, among other tools. Through on-device analysis of macOS system events, Jamf Protect (originally called GamePlan) creates unprecedented telemetry and provides enterprise security teams with the insights they require for behavioral detections and threat hunting. With its streaming insights and KEXT-less design, Protect extends Apple’s security and privacy model to an enterprise while upholding the Apple user experience and never delaying an OS upgrade.

There are a number of other tools, many of which are provided by large technology companies that are happy to sell software that works on the Mac, but often don’t work as well as we’d like. This isn’t to say there isn’t merit in them, and there are tools out there evolving at a rapid pace. And, of course, there are environments that see no need for any security solutions whatsoever, relying entirely on their own automations using built-in frameworks in macOS.

Administrator Rights on macOS

An important topic from both an operational and security standpoint is how to manage administrator rights for the user accounts used on the fleet. Before delving into that, first some backstory on how administrator rights came to exist on macOS.

Most of these Apple platforms do not have the concept of multiple users. There's just one user state in play by default. iOS and iPadOS do include authentication, but there is still usually only one user context which is in scope.

iPadOS does have the concept of multiple user accounts via supporting user sessions for multiple Managed Apple IDs, but that's a special configuration option for when sharing an iPad between multiple people is necessary. All of the Managed Apple ID user accounts are equal in terms of what they can do on the iPad, so the idea of standard user vs. admin user doesn't come into play. Instead, the user paradigm is equal user rights with separation of documents and data for each user.

It's only on macOS that the paradigm of multiple user accounts and those accounts having different permissions for access and actions exists. The Macs haven’t always had it though. If you look at the various versions of the original Mac OS between System One’s introduction and Mac OS 9, you see a similar user paradigm to what you see on Apple’s other platforms. By default, there was only one user context, and the operating system would boot into it automatically.

So if the paradigm we use today didn’t come from the original Mac OS, where did it come from?

It comes from NeXT Computers and more specifically the Unix-based NeXTSTEP operating system developed by NeXT. When Apple bought NeXT in 1996, it began using NeXTSTEP’s foundations to build what would eventually become Mac OS X. This included building a Unix-based operating system, which included multiple user accounts. More importantly for this topic, NeXTSTEP included the paradigm of an account named root which is a superuser account. On NeXTSTEP, root can do anything. It has read/write access to the entire local filesystem and can run any command.

Apple had previously built Unix-based operating systems with superuser accounts for specialized purposes, but with this change, Apple began mainstreaming the paradigm for its main operating system of both multiple user accounts and a superuser account which has more access and privileges than other user accounts.

However, there’s only one root user in Unix and only one password to that account. Sharing passwords is a security issue. Apple’s solution was to introduce a new set of superuser privileges for Mac OS X, which they designated an admin account. These privileges could then be applied to multiple accounts.

Management of which accounts have admin rights is handled by membership in a local group on the Mac named admin, shown in Figure 8-29. However, membership in this group only handles admin rights for the Mac OS X graphical user interface.

A screenshot of the directory utility window. It has icons for services, search policy, and directory editor. The option directory editor has been selected. The left section has a search bar with selected administrators. The right section has the name and value.

To provide administrative rights on the command line, Apple uses the sudo command-line tool. This tool enables authorized user accounts to run commands as root or another user. As part of the OS installation process, Apple installs a configuration file for sudo that grants members of the admin group all the privileges that the sudo tool can grant. In turn, this means that members of the admin group have the same ability as the root account to run all commands and functions with the root account’s privileges (Figure 8-30).

A screenshot of username pico sudo window. It highlights the default sudo configuration. It is % admin, A L L equals open parenthesis A L L close parenthesis A L L.

With regard to the actual root user, Apple put some controls in place to limit the root user account's abilities and permissions. These controls include disabling the root account by default, discouraging its use, and providing ways to access elevated or root privileges using other means.

This paradigm of multiple user accounts, a superuser account whose use is discouraged, special accounts (referred to as administrator accounts) which have more access and privileges than other user accounts, and nonspecial accounts (referred to as standard accounts) has been used in all versions of the Mac operating system from Mac OS X 10.0 Cheetah through to today's version of macOS.

With these protections in place to contain the power of the root account, where large sections of the filesystem can’t be written to or altered and user data requires permission to access, let’s reexamine the statement about root as it relates to administrator rights. It remains true that anything root can do, an account with admin rights can do, but what root can do on macOS is significantly contained compared to other Unix-based OSs. With the lowered capability also comes lowered risk.

With these rights being managed in two locations, this leaves open the possibility that admin rights in the macOS graphical user interface and the command line can be managed separately. If desired, you could assign admin rights in the GUI but not to the command line or vice versa by editing the sudo configuration file to change it from Apple’s default settings.

Permanent admin rights can be granted to an account by adding the account in question to the admin group and not removing it. With Apple’s default configuration for sudo, this should grant the account administrator rights for both the graphical user interface and the command line.

Not granting administrator rights to an account means making sure that the account is not a member of the admin group. Assuming Apple’s default configuration for sudo, keeping the account out of the admin group should ensure it only has the rights granted to a standard user account.

Granting administrator rights on a nonpermanent basis to an account usually means that there is a mechanism in place to enable the account to be added and removed from the admin group as needed.

Is there a one best way for deciding how to manage admin rights? Unfortunately, not. There are a number of factors which affect this decision, which may include legal requirements, complying with the requirements of an external standard that your business has committed to complying with, internally created policy requirements of your company, school, or institution, or operational requirements in your environment.

No matter what other factors exist, the key question which must be answered is going to be if you can trust your users with admin rights while also remaining in compliance with your other requirements. If you can, then (in this author's opinion) they should have them. If you can’t, then they shouldn’t.

If you make the choice to grant admin rights on a nonpermanent basis, as mentioned earlier, you will likely need a mechanism in place which can enable accounts to be added and removed from the admin group as needed. A tool for enabling this is the Privileges app (Figure 8-31), an application developed and open sourced by SAP, which allows a user account which is logged in to macOS’s graphical user interface to grant and remove administrator rights.

A screenshot of Privileges window. There is a pop-up window on the screen with the text, you are currently a standard user. Would you like to request administrator privileges? There are buttons for options, request privileges and cancel at the bottom.

Summary

The Mac is still very much treated as a computer by most corporate IT departments. Therefore, they will expect the same full complement of tools to be used on the Mac so it is an equal citizen to Windows. You may disagree that you need a tool to perform various tasks, but that doesn’t mean that you always have the option to choose whether to run these tools or not. iOS is very different. You can’t run an agent on iOS. But you can check that the device meets certain criteria and look for threats on the device.

You have to implement these tools, settings, or procedures so the device is compliant with the policies required to be able to get on the network of most organizations. Doing so may require two to three agents. But the alternative is likely that you can’t let devices access the network.

Ultimately, the Mac team at most organizations will start off by integrating solutions the larger Windows population of devices already leverage. For example, if you’re using Symantec products for other platforms, you probably already have licensing and so will just use those same tools to secure the Mac. However, as your deployment matures and grows, you will end up with the political capital to go to your CISO and argue for the tools that work best for the platform (see Appendix A) or to explain why those tools are irrelevant for the platform your team manages.

Some of the more talented administrators might read this chapter and be surprised that something wasn’t covered. We included the links to Apple’s security documents and didn’t want to duplicate any of the content covered there. Some aspects of securing devices simply couldn’t be covered as they’re moving targets, though. Security might be the fastest changing landscape in technology.

Now that you’re starting to get a number of different tools running on devices throughout your enterprise, let’s shift our attention toward testing, so you can make sure everything works when Apple accelerates the rate of change in their systems even faster in the years to come.