Transcription
Good evening. This presentation is based on my GIAC GSNA Gold technical paperentitled “Auditing Mac OS X Compliance with the Center for Internet Security BenchmarkUsing Nessus.”I wrote the paper as the beginning of the compliance checks for a customer that wanted anautomated 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 InternetSecurity (CIS, www.ciseurity.org ).The CIS Benchmark for Mac OS X was released May 2008. It contained Level 1 andLevel 2 items. Implementing Level 1 is the minimum recommendation and should not breakany applications. Level 2 increases the security posture of the machine but could breakapplications. In both Level 1 and 2, there are 118 Benchmark items: 66 Level 1 items and 52Level 2 items. Of those 118 items, there are 51 listed as “Scorable,” indicating that they can beverified with an automated check. Many of the remain items are listed as manual; in otherwords there is no easy way to automate the checking for that item. The Benchmark includesitems 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 Objectcapability. That means checking the compliance of a Mac against the benchmark requiresmanually examining the contents of files or other manual checks. The customer could haveused a shell script to check the compliance of their Macs but they were already using Nessus todo 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 Macso I imposed the constraint that only built-in tools would be used and not require installing anyscripts or tools in the target machines.1
In this presentation, you will learn how you can check for secure configurations of MacOS X (10.5) using Nessus 3 and later. We will learn how the compliance check features ofNessus are used to check security settings on Mac OS X in addition to using the local securitychecks to scan for vulnerabilities. We will will also learn how to customize the compliancechecks for use in your Mac OS X environment. You'll also receive pointers to a detailed list ofcompliance 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 andWindows Device Configurations. Retrieved October 30, 2008, from Tenable Network Securityweb site: r/nessus compliance checks.pdfSmith, R.D. (2008, November 7). Auditing Mac OS X Compliance with the Center for InternetSecurity Benchmark Using Nessus. Retrieved December 31, 2008 from GIAC web site: http://www.giac.org/certified professionals/practicals/GSNA/00487.php2
Nessus started out as an open-source network-based vulnerability scanner. It works solelyby checking for open ports and then analyzing the ports and the service behind each port todetermine if the machine has a vulnerability. Nessus uses a client-server architecture in whichthe Nessus daemon conducted the scan against specified targets. The client tells the serverwhich vulnerabilities to check for by specifying a set of plugins to run along with anyinformation necessary for the plugins to run. The Nessus plugins told the server how toconduct the vulnerability checks and the expected results. Once the scan was completed, theserver 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 biggestchange was the addition of the capability to do local checks. Now a plugin can tell Nessus tolog 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 networkvulnerabilities. For example, it can find that the machine has a vulnerable version of AdobeReader installed.Tenable Security also made several changes in the licensing of Nessus 3. Currently thereare two type of licenses: HomeFeed and ProfessionalFeed. The HomeFeed license is free andallows installation and use in a noncommercial environment. The ProfessionalFeed is requiredif you use Nessus in a commercial environment or for scanning third parties. You need aProfessionalFeed license installed to enable the compliance checks capability.Compliance checks use .audit files to specify the checks that will be performed on thetarget machine and the expected results. Tenable has created Windows and UNIX versionsof .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 .auditfiles. We are going to talk exclusively about Unix .audit files for the rest of this talk, althoughmany of the concepts can be applied to the Windows .audit files as well.3
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 ofthe .audit file specifies the compliance check items.You can do built-in checks that examine some standard security related parameters onUNIX machines. For example, looking for accounts with an invalid default shell based on thelist of shells listed in /etc/shells. Some of these built-in check items don’t work on allversions of UNIX or Linux, for example the min password age built-in check is notsupported on Mac OS X targets.Custom items are usually check parameters that are not standard across the various flavorsof UNIX or Linux or are customized for a particular installation. For the Mac OS X dot-auditfiles, 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 onhow check is specified. Grammar custom check allows you to use regular expressions todefine the correct grammar or construction of a particular file and then check that fileThere are several other types of custom items that are specific for a particular UNIX orLinux distribution. For example, on RedHat derived systems, you can look at the status ofservices using chkconfig command or check the version of a particular installed rpmpackage.Let’s look at some examples of specifying built-in check items.4
Here are two examples of built in checks. You can tell they are built-in checks since theystart with an item tag and end with an /item tag. The checks are built from keywordvalue pairs. The name keyword is required and specifies the built-in check. The nextkeyword, description is also required. One of the requirements for the descriptionkeyword is each check must have a unique description value, but that requirement is handledby Tenable for the built-in checks.Each built-in check may require other keyword-value pairs. For example, themin password length requires the value keyword-value pair that specifies the range ofacceptable password lengths. For the account bad home permissions check needs themode 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 anycheck. The value set using this keyword modifies the severity of the Nessus finding when thecheck fails. The default severity is HIGH. In the account bad home permissions checkexample, I have changed the severity to MEDIUM.One thing to remember when writing the checks, the keyword-value pair must be on asingle line in the .audit file. In the min password length example, the description linehas 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 themin depth. Now let’s look at the custom compliance checks.5
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-valuepairs to the specify the check.The system keyword specifies the operating system that the check applies to. Todetermine the correct value, run uname on the system. For example on a Mac OS X system, ina Terminal.app window you would get:RDS-MacBook-Pro: rick unameDarwinThe 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 fileexists and it matches the specified properties of the file. The properties that can be checked areowner, 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-inchecks. The info keyword-value pairs are optional and are used to add information to theNessus finding output. In this example, I’ve included information about the applicable sectionof the CIS benchmark. In the rest of the examples only the Benchmarks Section info keywordvalue pairs will be shown.The file keyword is required and specifies the file to check. You can specify the full path tothe file or you can use the search locations keyword to tell Nessus the directories tosearch 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-valuepairs. 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.6
For most UNIX systems, checking the configuration settings usually involves looking forthe correct value in a text-based configuration file. That is exactly what aFILE CONTENT CHECK checks does. It searches the contents of a text file for a match to theregular expression given in the regex keyword. The check will fail if the file does not exist orthe 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-inchecks. The file keyword specifies the file to examine. You can specify the full path to thefile or you can specify the search locations keyword to tell Nessus the directories tosearch 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 fileand the correct results. For this example, the regex keyword is set so we are looking for theline 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 withthe two characters, “.*”. In regular expressions, a “.” means any character and a “*” means thepreceding character can be repeated zero or more times. This gives the possibility of text ateither end of the line. The “ ” represents the end of the line. So putting it back together, theregular expression will match a line with any number of characters before “TIMESYNC ” andany 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 thedesired value is inserted at the correct position. In this example, we want to see if theTIMESYNC variable in the /etc/hostconfig file is assigned “-YES-” as its value. So theregular expression for the expect keyword has “-YES-” in place of the “.* ”. For the check topass, the line which matched the regex keyword pattern can contain any number of charactersbefore “TIMESYNC -YES-” and nothing after.This type of check doesn’t work for configuration files where the text to check is onmultiple lines or the configuration files aren’t text files. We will need to use commandexecution checks for many of the configuration file checks.7
The command execution compliance checks gives us the capability to use the output of acommand run on the target system to verify the compliance of the target system. The Nessuscompliance check plugin runs the command then verifies the output is correct. On Unixsystems, the Nessus compliance plugin will run the command with sudo using the suppliedsudo credentials unless the nosudo keyword is set to “YES.”There are limitations on command execution compliance checks that we need tounderstand before we look at some examples. The first limitation that you need to understandis the commands must be as a single line. You can pipe commands together but you have toend up with one line of output. That is the second limitation of the CMD EXEC checks. Whenthe compliance check plugin does the comparison of the command output to the expectkeyword 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 thedesired 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 ofoutput. 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 oneliners to examine the command output when it is too complex to examine with a simple regularexpression.You can use any scripting language for these checks, like Ruby or python, if you cancreate the same functionality on one line in those languages.Now let’s look at some examples.8
The first example is a relatively simple command execution check. This examplecompliance check verifies that a password is required to be entered to boot the machine. This isan example of a command that produces multiple lines of output but the data that needs to beexamined is on one line.For this check the type keyword is set to CMD EXEC. Again, this type of check requiresthat you specify a unique value for the description keyword. The other two required keywordsare cmd and expect. The cmd keyword value is the exact command that needs to be run to getthe 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 searchfor the line containing the “security-mode” NVRAM variable. The expected output is theNVRAM 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. Anydouble quotes or back slashes you need to use in the command line itself you must escape bywith a backslash. We will see this in the complex command execution examples.9
This example is another simple command execution compliance check. Apple stores someconfiguration information in Apple binary property list (plist) files. You have to use thedefaults command line tool to get or set the variables stored in the files. This compliancecheck 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 thecom.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.10
In this example compliance check, we are checking whether the Apache httpd daemon isconfigured to start on boot. The Apache configuration stored in an XML-based Apple propertylist (plist) file. These files are text files but the setting name and the corresponding value arestored on different lines in the text so you can’t use simple FILE CONTENT checks. Thecontents of the plist file for the check on the above are listed below. You can see theDisabled key and its value, “true” are different lines.rick cat st ?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 11
To handle these files, you can use Perl one-liners to find the value of the setting and createthe single line of output that can be checked by the Nessus compliance check engine. The Perlcommand line options you need to use and understand are:-0777Puts Perl in to “file slurp” mode. Perl will read in the entire file as one lineinto the input record.-eAllows you to define Perl code to be executed by the compiler, that is, createa one-liner.-nCreates an implicit loop. It loops around your -e code so it will read all ofthe files given on the command line a line at a time.-lCauses Perl to automatically chomp the input record (remove the line feedand carriage return characters)This example check is an if-else conditional that looks for the desired key with the correctvalue using a regular expression. If it is found, “Disabled” or “Service Enabled” isprinted 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 wayit is readable by people who aren’t familiar with Perl.)12
This example is one of the more complex compliance checks I implemented. The CISbenchmark requires that a banner with organization defined content is set for the OpenSSHdaemon, sshd. This check does two things: checks the /etc/sshd config file for a bannerbeing configured and checks the banner file content. To create the configuration checkcommand, 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 configfile.rick grep -E ' Banner' /etc/sshd configBanner /etc/motdThen cut is used to get the banner file name out of the Banner line from the sshd configfile.rick grep -E ' Banner' /etc/sshd config cut -d " " -f2/etc/motdThe third step, and the first Perl one-liner, uses a system call to list the contents of the bannerfile, 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.13
The last step is to concatenate the contents of the banner file into one line as the output forthe 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 monitoredand 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 technicalpaper. This check needs to be customized for your organization’s approved banner text.14
The first step in configuring the scan policy in Nessus is ensuring the correct plugins areenabled. On the Plugin Selections tab, enabling the “MacOS X Local Checks” family ensuresNessus logs in to the target machines to login via OpenSSH to check the configuration of themachine from the inside. The local security checks are a prerequisite for the compliancechecks. Under the Pol
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.File Size: 2MB
