1

Good evening. This presentation is based on my GIAC GSNA Gold technical paper entitled “Auditing Mac OS X Compliance with the Center for Internet Security Benchmark Using Nessus.”

I wrote the paper as the beginning of the compliance checks for a customer that wanted an automated method to check the compliance of their Mac OS X machines against a baseline. Their baseline was derived from the Mac OS X v10.5 Benchmark from Center for Internet Security (CIS, www.ciseurity.org ).

The CIS Benchmark for Mac OS X was released May 2008. It contained Level 1 and Level 2 items. Implementing Level 1 is the minimum recommendation and should not break any applications. Level 2 increases the security posture of the machine but could break applications. In both Level 1 and 2, there are 118 Benchmark items: 66 Level 1 items and 52 Level 2 items. Of those 118 items, there are 51 listed as “Scorable,” indicating that they can be verified with an automated check. Many of the remain items are listed as manual; in other words there is no easy way to automate the checking for that item. The Benchmark includes items which are operational policy issues that can’t be checked on the machines.

Unlike Windows, Mac OS X does not have a “security template” or Group Policy Object capability. That means checking the compliance of a Mac against the benchmark requires manually examining the contents of files or other manual checks. The customer could have used a shell script to check the compliance of their Macs but they were already using Nessus to do compliance checks on Windows machines and wanted to use the same tool.

When I began writing the compliance checks I wanted to be able to use them on any Mac so I imposed the constraint that only built-in tools would be used and not require installing any scripts or tools in the target machines.

2

In this presentation, you will learn how you can check for secure configurations of Mac OS X (10.5) using Nessus 3 and later. We will learn how the compliance check features of Nessus are used to check security settings on Mac OS X in addition to using the local security checks to scan for vulnerabilities. We will will also learn how to customize the compliance checks for use in your Mac OS X environment. You'll also receive pointers to a detailed list of compliance checks that everyone using a Mac should know and use.

References: Center for Internet Security. (2008, May). CIS Level 1 & 2 Benchmark for Mac OS X. Retrieved November 4, 2008 from Center for Internet Security web site: http://www.cisecurity.org/bench_macosx.html (registration required) Tenable Network Security. (2008, August 1). Nessus Compliance Checks – Auditing UNIX and Windows Device Configurations. Retrieved October 30, 2008, from Tenable Network Security web site: https://plugins-customers.nessus.org/support-center/nessus_compliance_checks.pdf Smith, R.D. (2008, November 7). Auditing Mac OS X Compliance with the Center for Internet Security Benchmark Using Nessus. Retrieved December 31, 2008 from GIAC web site: http://www.giac.org/certified_professionals/practicals/GSNA/00487.php

3

Nessus started out as an open-source network-based vulnerability scanner. It works solely by checking for open ports and then analyzing the ports and the service behind each port to determine if the machine has a vulnerability. Nessus uses a client-server architecture in which the Nessus daemon conducted the scan against specified targets. The client tells the server which vulnerabilities to check for by specifying a set of plugins to run along with any information necessary for the plugins to run. The Nessus plugins told the server how to conduct the vulnerability checks and the expected results. Once the scan was completed, the server sent the results to the client.

When Tenable Security introduced Nessus 3, it went from open source to closed source. Tenable also made several improvements to the capabilities of the Nessus server. The biggest change was the addition of the capability to do local checks. Now a plugin can tell Nessus to log in to the remote target machine and conduct various types of checks. In other words, Nessus can find local client-side vulnerabilities on the machine instead of just network vulnerabilities. For example, it can find that the machine has a vulnerable version of Adobe Reader installed.

Tenable Security also made several changes in the licensing of Nessus 3. Currently there are two type of licenses: HomeFeed and ProfessionalFeed. The HomeFeed license is free and allows installation and use in a noncommercial environment. The ProfessionalFeed is required if you use Nessus in a commercial environment or for scanning third parties. You need a ProfessionalFeed license installed to enable the compliance checks capability.

Compliance checks use .audit files to specify the checks that will be performed on the target machine and the expected results. Tenable has created Windows and UNIX versions of .audit files to give the ability to specify unique checks on the different OSs. For example, you can check registry values and permissions on a Windows machine with Windows .audit files. We are going to talk exclusively about Unix .audit files for the rest of this talk, although many of the concepts can be applied to the Windows .audit files as well.

4

The .audit files are XML-like in structure. A simple one line tag, <check_type:"Unix"> specifies that this is a UNIX .audit file and a </check_type> tag closes the file. The rest of the .audit file specifies the compliance check items.

You can do built-in checks that examine some standard security related parameters on UNIX machines. For example, looking for accounts with an invalid default shell based on the list of shells listed in /etc/shells. Some of these built-in check items don’t work on all versions of UNIX or Linux, for example the min_password_age built-in check is not supported on Mac OS X targets.

Custom items are usually check parameters that are not standard across the various flavors of UNIX or Linux or are customized for a particular installation. For the Mac OS X dot-audit files, the majority of the check items used were command execution and file content checks. File content checks can look for existence of text in the file or the lack of text depending on how check is specified. Grammar custom check allows you to use regular expressions to define the correct grammar or construction of a particular file and then check that file

There are several other types of custom items that are specific for a particular UNIX or Linux distribution. For example, on RedHat derived systems, you can look at the status of services using chkconfig command or check the version of a particular installed rpm package.

Let’s look at some examples of specifying built-in check items.

5

Here are two examples of built in checks. You can tell they are built-in checks since they start with an <item> tag and end with an </item> tag. The checks are built from keyword-value pairs. The name keyword is required and specifies the built-in check. The next keyword, description is also required. One of the requirements for the description keyword is each check must have a unique description value, but that requirement is handled by Tenable for the built-in checks.

Each built-in check may require other keyword-value pairs. For example, the min_password_length requires the value keyword-value pair that specifies the range of acceptable password lengths. For the account_bad_home_permissions check needs the mode keyword-value pair set to the acceptable permissions for a user’s home directory.

The severity keyword is one of the optional keyword-value pairs that can be used with any check. The value set using this keyword modifies the severity of the Nessus finding when the check fails. The default severity is HIGH. In the account_bad_home_permissions check example, I have changed the severity to MEDIUM.

One thing to remember when writing the checks, the keyword-value pair must be on a single line in the .audit file. In the min_password_length example, the description line has been wrapped onto a second line for display purposes.

These checks are well documented in Tenable’s guide to .audit files so I won’t cover them in depth. Now let’s look at the custom compliance checks.

6

The first difference between the built-in checks and the custom checks is the tags are “custom_item” not “item.” Also in most cases, the custom checks need more key-value pairs to the specify the check.

The system keyword specifies the operating system that the check applies to. To determine the correct value, run uname on the system. For example on a Mac OS X system, in a Terminal.app window you would get:

RDS-MacBook-Pro:~ rick$ uname

Darwin

The type keyword tells Nessus which one of the 10 kinds of custom checks to perform. This example is a FILE_CHECK so the Nessus compliance check plugin will check the file exists and it matches the specified properties of the file. The properties that can be checked are owner, group owner, permissions, and the MD5 checksum of the file.

The description keyword is required and the value must be unique just like for built-in checks. The info keyword-value pairs are optional and are used to add information to the Nessus finding output. In this example, I’ve included information about the applicable section of the CIS benchmark. In the rest of the examples only the Benchmarks Section info keyword-value pairs will be shown.

The file keyword is required and specifies the file to check. You can specify the full path to the file or you can use the search_locations keyword to tell Nessus the directories to search for a file with the name specified by the file keyword.

The checks can be specified by using the owner, group, mode, or md5 keyword-value pairs. In this example the mode keyword is used with a value of 0700. For the mode keyword, you can specify the mode as either an absolute mode, “0644”, or as a symbolic mode, “-rw-r--r—”.

Now let’s look at checking the contents of a file.

7

For most UNIX systems, checking the configuration settings usually involves looking for the correct value in a text-based configuration file. That is exactly what a FILE_CONTENT_CHECK checks does. It searches the contents of a text file for a match to the regular expression given in the regex keyword. The check will fail if the file does not exist or the contents of the file doesn’t match the expected results.

The description keyword is required and the value must be unique just like the built-in checks. The file keyword specifies the file to examine. You can specify the full path to the file or you can specify the search_locations keyword to tell Nessus the directories to search for a file with the name specified by the file keyword.

The regex and the expect keywords tell Nessus what content to look for in the text file and the correct results. For this example, the regex keyword is set so we are looking for the line containing “TIMESYNC=” along with the possibility of some other text on either side of it. To break the regular expression down, we see that the regular expression starts and ends with the two characters, “.*”. In regular expressions, a “.” means any character and a “*” means the preceding character can be repeated zero or more times. This gives the possibility of text at either end of the line. The “$” represents the end of the line. So putting it back together, the regular expression will match a line with any number of characters before “TIMESYNC=” and any number of characters after until the end of the line.

The expect keyword is set to the same regular express as the regex keyword except the desired value is inserted at the correct position. In this example, we want to see if the TIMESYNC variable in the /etc/hostconfig file is assigned “-YES-” as its value. So the regular expression for the expect keyword has “-YES-” in place of the “.*$”. For the check to pass, the line which matched the regex keyword pattern can contain any number of characters before “TIMESYNC=-YES-” and nothing after.

This type of check doesn’t work for configuration files where the text to check is on multiple lines or the configuration files aren’t text files. We will need to use command execution checks for many of the configuration file checks.

8

The command execution compliance checks gives us the capability to use the output of a command run on the target system to verify the compliance of the target system. The Nessus compliance check plugin runs the command then verifies the output is correct. On Unix systems, the Nessus compliance plugin will run the command with sudo using the supplied sudo credentials unless the nosudo keyword is set to “YES.”

There are limitations on command execution compliance checks that we need to understand before we look at some examples. The first limitation that you need to understand is the commands must be as a single line. You can pipe commands together but you have to end up with one line of output. That is the second limitation of the CMD_EXEC checks. When the compliance check plugin does the comparison of the command output to the expect keyword value, it only looks at the first line of the command output. I used two workarounds.

• The first workaround is the obvious one. You can pipe multiple commands to get the desired results. This works well if the final command gives one line of output. • The second workaround is to use Perl one-liners. Perl one-liners allows you to “compress” multiple lines of text into a single line of output.

You can use a Perl one-liners when the output of the command has multiple lines of output. Or when you need to examine an XML-base Apple binary property list file (plist) where the configuration setting information is on multiple lines. You can also use the Perl one-liners to examine the command output when it is too complex to examine with a simple regular expression.

You can use any scripting language for these checks, like Ruby or python, if you can create the same functionality on one line in those languages.

Now let’s look at some examples.

9

The first example is a relatively simple command execution check. This example compliance check verifies that a password is required to be entered to boot the machine. This is an example of a command that produces multiple lines of output but the data that needs to be examined is on one line.

For this check the type keyword is set to CMD_EXEC. Again, this type of check requires that you specify a unique value for the description keyword. The other two required keywords are cmd and expect. The cmd keyword value is the exact command that needs to be run to get the expected results.

For this example, the nvram command is used to get or set firmware NVRAM variables. The “–p” option lists all of the NVRAM variables. The output is piped through grep to search for the line containing the “security-mode” NVRAM variable. The expected output is the NVRAM variable name followed by any number of any characters (indicated by the “.*” combination) and then the desired value of “command.”

For the cmd keyword, you have to put the exact command line inside double-quotes. Any double quotes or back slashes you need to use in the command line itself you must escape by with a backslash. We will see this in the complex command execution examples.

10

This example is another simple command execution compliance check. Apple stores some configuration information in Apple binary property list (plist) files. You have to use the defaults command line tool to get or set the variables stored in the files. This compliance check verifies the Mac OS X automatic logon feature has been disabled.

In this example, the defaults command is used to read in the /Library/Preferences/.GlobalPreferences plist file and print out the value of the com.apple.userpref.DisableAutoLogin variable.

The expected results is a value of 1, which is the value if the automatic logins are disabled. If automatic logins are not disabled, the value returned would be 0.

Now let’s look at some complex examples of command execution compliance checks.

11

In this example compliance check, we are checking whether the Apache httpd daemon is configured to start on boot. The Apache configuration stored in an XML-based Apple property list (plist) file. These files are text files but the setting name and the corresponding value are stored on different lines in the text so you can’t use simple FILE_CONTENT checks. The contents of the plist file for the check on the above are listed below. You can see the Disabled key and its value, “true” are different lines.

rick$ cat /System/Library/LaunchDaemons/org.apache.httpd.plist

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>Disabled</key>

<true/>

<key>Label</key>

<string>org.apache.httpd</string>

<key>OnDemand</key>

<false/>

…

</dict>

</plist>

To handle these files, you can use Perl one-liners to find the value of the setting and create the single line of output that can be checked by the Nessus compliance check engine. The Perl command line options you need to use and understand are:

-0777 Puts Perl in to “file slurp” mode. Perl will read in the entire file as one line into the input record.

-e Allows you to define Perl code to be executed by the compiler, that is, create a one-liner.

-n Creates an implicit loop. It loops around your -e code so it will read all of the files given on the command line a line at a time.

-l Causes Perl to automatically chomp the input record (remove the line feed and carriage return characters)

This example check is an if-else conditional that looks for the desired key with the correct value using a regular expression. If it is found, “Disabled” or “Service Enabled” is printed as output. The compliance check looks for “Disabled” as the output.

This is a good example of escaping double quotes and back slashes in the command line. (Yes, the Perl code can be written in other ways to do the same check in less space but this way it is readable by people who aren’t familiar with Perl.)

12

13

This example is one of the more complex compliance checks I implemented. The CIS benchmark requires that a banner with organization defined content is set for the OpenSSH daemon, sshd. This check does two things: checks the /etc/sshd_config file for a banner being configured and checks the banner file content. To create the configuration check command, I used two command line tools and two Perl one-liners.

The first step is using grep to find the Banner configuration line in the sshd_config file.

rick$ grep -E '^Banner' /etc/sshd_config

Banner /etc/motd

Then cut is used to get the banner file name out of the Banner line from the sshd_config file.

rick$ grep -E '^Banner' /etc/sshd_config | cut -d " " -f2

/etc/motd

The third step, and the first Perl one-liner, uses a system call to list the contents of the banner file, in this example /etc/motd.

rick$ grep -E '^Banner' /etc/sshd_config | cut -d " " -f2 | \ perl -nle 'system("cat", $_);'

!!Authorized Uses ONLY!!

All activity may be monitored and reported.

The last step is to concatenate the contents of the banner file into one line as the output for the compliance check engine.

rick$ grep -E '^Banner' /etc/sshd_config | cut -d " " -f2 | \ perl -nle 'system("cat", $_);’ | \ perl -0777 -ne 's/\n//g;s/\r//g;print;'

!!Authorized Uses ONLY!!All activity may be monitored and reported.

The expect keyword is written to match on this value. NOTE: This is the banner text that I used as an example for my GIAC GSNA technical

paper. This check needs to be customized for your organization’s approved banner text.

14

15

The first step in configuring the scan policy in Nessus is ensuring the correct plugins are enabled. On the Plugin Selections tab, enabling the “MacOS X Local Checks” family ensures Nessus logs in to the target machines to login via OpenSSH to check the configuration of the machine from the inside. The local security checks are a prerequisite for the compliance checks. Under the Policy Compliance family, enabling the Unix Compliance Checks enables the compliance check plugin. Both of these should be enabled by default in a new scan policy.

On the Credentials tab, you need to supply ssh credentials for an admin account in order for the Nessus server to remotely login to the Mac OS X target machines and conduct the local security checks. You can specify either a username and password or a set of SSH public-private keys to login to the remote machines. Nessus prefers root logins to do the checks but since the root user is disabled by default on Mac OS X, you also need to supply sudo credentials.

On the Advanced tab, select Unix Compliance from the pull-down menu. Then enter the .audit files.

NOTE: The instructions above assume you are using NessusClient to connect to a Nessus server that was registered with a ProfessionalFeed License and has updated plugins. NOTE: If Nessus fails to conduct the local security checks, verify you have entered the correct credentials and that Remote Login is enabled and allowed through any firewall. Test by establishing an ssh connection into the target from the Nessus server using the same credentials. NOTE: If you don’t see the Policy Compliance category of plugins, then you probably don’t have a ProfessionalFeed license. You can also look for the unix_compliance_check.nbin, compliance_check.nbin, and compliance_check_windows_file_content.nbin files in the directory where your plugins are stored. These “nbin” files are compiled Nessus plugins as opposed to the standard Nessus Attack Script Language (NASL) plugins. The complied plugins contain Tenable Security’s proprietary code.

16

17

I designed my test setup with the goals of testing each check completely as possible and also as fast as possible. To do that, I used two targets, one configured to pass the check and one to fail the check. If possible, I used the default configuration as one of the configurations for testing. To minimize the number of findings while I was testing, both targets were patched up to Mac OS X v10.5.5, which was the latest version when I was testing. I created a Nessus Audit Admin account on both machines.

For hardware, I also needed to check configurations on the PowerPC-based and Intel-based Macs. My two test targets were a MacBook Pro 15 (Intel-based) and a PowerMac G4 867MHz (PowerPC-based). Using the old PowerMac gave me a machine that did not have an iSight camera and Bluetooth installed. For some configuration checks, the configuration of the machines was switched to verify that each machine could pass

For Nessus, I used NessusClient 3.2.1 on a MacBook Pro 17, also running Mac OS X v10.5.5. The Nessus server version 3.2.1 was running on a Dell Latitude D600 running openSuSE 11.0 Linux. The Nessus server was registered with a ProfessionalFeed license.

For testing new compliance checks, I used a test .audit file containing only one compliance check. Each compliance check was tested by itself to ensure that the check failed or passed on the appropriate machine. After running a Nessus scan against the two machines, the results were filtered for the Plugin ID of the UNIX compliance checks plugin, 21157.

The complex command execution compliance checks required multiple iterations. Starting out in a Terminal window on one of the targets, the command line with the Perl one-liner is written and tested iteratively until the check worked. The command line testing also helped determine the value for the expect keyword. Once the one-liner worked on one target, the compliance check was added to the test .audit file. Then both targets were scanned, the results checked. Then the Perl one-liner or the expect keyword value would be modified. The cycle repeated until the check worked correctly on both machines.

18

In this presentation, we covered how to write a number of different types of Nessus compliance checks. Built-in checks can be used for some benchmark items, but most of the items require a custom compliance check. We also covered some techniques to check the configuration settings in a number of different file types with custom compliance checks. And, how to set up a test environment for testing your own compliance checks. Overall, Nessus compliance checks work well for checking the security configuration of Mac OS X machine against the CIS benchmark. Using the techniques in this presentation I was able to write compliance checks to cover 62 benchmarks items, over half of the total items and more than the 51 Scorable items. The majority of the checks I implemented, 50 of 62, were system context items, that is, they check a system wide configuration. The rest were user context items and the check must be run against the configuration of all user accounts. I implemented 12 user context items but they only check the configuration of the user account that Nessus uses to log in. Most of the benchmark items that I couldn’t check completely were in user context. To access the account configuration files, you need to su to each account. I couldn’t find a way to check those items without enabling the superuser, or root, account and providing the root credentials to Nessus. The complete set of .audit files for checking a Mac OS X system against the CIS Benchmark are available from my GIAC GSNA technical paper. Email me at rdsmith@mac.com if you have questions.