Mac OS X Live Forensics 108: Santa and Virtual Machines
Hey all! Some quick tips in this post.
A quick Christmas treat, OS X whitelisting and blacklisting brought to us by Google, aptly named Santa: https://github.com/google/santa
Its very important to note that this package is still not 1.0 yet, so it could very likely make your system more vulnerable in it's current state. None the less, it has some awesome features, which we will be instrumenting in our virtual machines later. It has some really interesting features for the enterprise, including user land event monitoring and white/black listing based on code signing certificates. Overall, this is an important step for locking down the OS X desktop for enterprise use.
When using a tool like Santa or KnockKnock (which we talked about in Mac OS X Live Forensics 104), sometimes you may see a binary that you don't quite remember. To check a signing cert, issue:
codesign -dvvvv /path/to/binary
It's easy to test this out where most kexts are stored:
/System/Library/Extensions/ or /Library/Extensions/
We had previously discussed setting up a VM from the 'Install Mavricks' DMG (in Mac OS X Live Forensics 105), but there is a much simpler way to create an OS X vm, if you are already running OS X on your host machine.
The easiest way I've found to start the OS X virtual machine is using VMware Fusion:
1) Start a new VM
2) Click More Options
5) You will need to enter your Apple ID:
6) The install will take awhile
7) Finally, create a new account and login, your sandbox awaits
Now that we have our VM going, let's play with Santa!
First things first, you will need to install Xcode from the App Store. Once installed, remember to run: sudo xcodebuild -license
Once you have Xcode installed., launch the Terminal app from Utilities
Start by cloning the repo:
git clone https://github.com/google/santa
cd santa
sudo gem install cocoapods
sudo rake build:debug
You will need to sign the project using your developer code signing cert. If you don't have one you can also download the prebuilt project releases. You can even check their kext signing cert as we previously covered: codesign -dvvvv binaries/santa-driver.kext
To run Santa, first your going to need a configuration file. Your config.plist file is what controls the program, it should be set at /var/db/santa/config.plist. Full instructions are on the wiki, and they are very straight forward for both enabling debugging and restricting program execution. Another good resource is dutchcoders.io. The basics of configuration are as follows:
sudo cp conf/com.google.santa.asl.conf /etc/asl
sudo cp conf/config.plist /var/db/santa/config.plist
sudo chmod 600 /var/db/santa/config.plist
sudo chown root:wheel /var/db/santa/config.plist
sudo cp -r binaries/santa-driver.kext /
sudo cp -r binaries/Santa.app /Applications
sudo cp -r binaries/santad /usr/libexec
sudo cp -r binaries/santactl /usr/sbin
sudo kextload /santa-driver.kext
We can now start santa by running: /usr/libexec/santad
Or have it start at bootup by setting: sudo cp conf/com.google.santad.plist /Library/LaunchDaemons
Then issuing: sudo launchctl load /Library/LaunchDaemons/com.google.santad.plist
You can now modify your rules database at: /var/db/santa/rules.db
And check your events database at: /var/db/santa/events.db
And should also view your logs at: /var/log/santad.log
The log format is pretty simple as well. It starts with a timestamp at the far right, when execution started. After the colon we have the Decision (Approved or Denied), the Reason (B, C, ?), the Sha-1 hash of the binary, the path to the binary, the binary's signing certificate's Sha-1 hash, and the binary's signing certificate's common name. This is all extremely helpful information, and can greatly aid a timeline in an IR. Any company would reap multiple benefits implementing a system like this, so I can't wait to see it reach maturity, and we will likely be exploring this tool much further now that we can set up a small army of OS X virtual machines to play on.
**Edit**
I was asked for an example of the log output, to get an idea of how the tool works, in monitor mode. This can be leveraged to see what programs were executed (their sha1 as an identifier), when they executed and their file path. The value in having a system like this in place is clearly evident, both from a preventative standpoint and from an incident response perspective. In the following example I execute Xcode and one of my favorite 3rd party Zip utilities for OS X, Keka:
A quick Christmas treat, OS X whitelisting and blacklisting brought to us by Google, aptly named Santa: https://github.com/google/santa
Its very important to note that this package is still not 1.0 yet, so it could very likely make your system more vulnerable in it's current state. None the less, it has some awesome features, which we will be instrumenting in our virtual machines later. It has some really interesting features for the enterprise, including user land event monitoring and white/black listing based on code signing certificates. Overall, this is an important step for locking down the OS X desktop for enterprise use.
When using a tool like Santa or KnockKnock (which we talked about in Mac OS X Live Forensics 104), sometimes you may see a binary that you don't quite remember. To check a signing cert, issue:
codesign -dvvvv /path/to/binary
It's easy to test this out where most kexts are stored:
/System/Library/Extensions/ or /Library/Extensions/
We had previously discussed setting up a VM from the 'Install Mavricks' DMG (in Mac OS X Live Forensics 105), but there is a much simpler way to create an OS X vm, if you are already running OS X on your host machine.
The easiest way I've found to start the OS X virtual machine is using VMware Fusion:
1) Start a new VM
2) Click More Options
3) Select Install OS X from the recovery partition
4) Finish the machine (you can change details later when powered down), and boot it up.
You can install it fresh or restore from a time machine (a good way to test on your current build).6) The install will take awhile
7) Finally, create a new account and login, your sandbox awaits
Now that we have our VM going, let's play with Santa!
First things first, you will need to install Xcode from the App Store. Once installed, remember to run: sudo xcodebuild -license
Once you have Xcode installed., launch the Terminal app from Utilities
Start by cloning the repo:
git clone https://github.com/google/santa
cd santa
sudo gem install cocoapods
sudo rake build:debug
Identifier=com.google.santa-driver
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=507 flags=0x0(none) hashes=18+3 location=embedded
Hash type=sha1 size=20
CDHash=2dc5f1588c77c2194ac944cdd920dfe9a1005b92
Signature size=8560
Authority=Developer ID Application: Google, Inc. (EQHXZ8M8AV)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 16, 2014, 1:55:55 PM
Info.plist entries=19
TeamIdentifier=EQHXZ8M8AV
Sealed Resources version=2 rules=12 files=0
Internal requirements count=1 size=184
To run Santa, first your going to need a configuration file. Your config.plist file is what controls the program, it should be set at /var/db/santa/config.plist. Full instructions are on the wiki, and they are very straight forward for both enabling debugging and restricting program execution. Another good resource is dutchcoders.io. The basics of configuration are as follows:
sudo cp conf/com.google.santa.asl.conf /etc/asl
sudo cp conf/config.plist /var/db/santa/config.plist
sudo chmod 600 /var/db/santa/config.plist
sudo chown root:wheel /var/db/santa/config.plist
sudo cp -r binaries/santa-driver.kext /
sudo cp -r binaries/Santa.app /Applications
sudo cp -r binaries/santad /usr/libexec
sudo cp -r binaries/santactl /usr/sbin
sudo kextload /santa-driver.kext
We can now start santa by running: /usr/libexec/santad
Or have it start at bootup by setting: sudo cp conf/com.google.santad.plist /Library/LaunchDaemons
Then issuing: sudo launchctl load /Library/LaunchDaemons/com.google.santad.plist
You can now modify your rules database at: /var/db/santa/rules.db
And check your events database at: /var/db/santa/events.db
And should also view your logs at: /var/log/santad.log
The log format is pretty simple as well. It starts with a timestamp at the far right, when execution started. After the colon we have the Decision (Approved or Denied), the Reason (B, C, ?), the Sha-1 hash of the binary, the path to the binary, the binary's signing certificate's Sha-1 hash, and the binary's signing certificate's common name. This is all extremely helpful information, and can greatly aid a timeline in an IR. Any company would reap multiple benefits implementing a system like this, so I can't wait to see it reach maturity, and we will likely be exploring this tool much further now that we can set up a small army of OS X virtual machines to play on.
**Edit**
I was asked for an example of the log output, to get an idea of how the tool works, in monitor mode. This can be leveraged to see what programs were executed (their sha1 as an identifier), when they executed and their file path. The value in having a system like this in place is clearly evident, both from a preventative standpoint and from an incident response perspective. In the following example I execute Xcode and one of my favorite 3rd party Zip utilities for OS X, Keka:
[2014-12-27 02:29:38.085Z] I santad: A,?,500518b802d719ec6d3b9ea9575b7981d1299bce,/Applications/Xcode.app/Contents/MacOS/Xcode,393d9e53bbd977911124b88d9850fef000588768,Apple Mac OS Application Signing
[2014-12-27 02:29:39.920Z] I santad: A,C,de6bbf6e62704ce45f7792313d5e572ca4386167,/System/Library/CoreServices/pbs,013e2787748a74103d62d2cdbf77a1345517c482,Software Signing
[2014-12-27 02:29:40.052Z] I santad: A,C,2debd0c21f0f1aa665484eec52879dc36bf777cb,/Applications/Xcode.app/Contents/Developer/Library/PrivateFrameworks/CoreSimulator.framework/Versions/A/XPCServices/com.apple.CoreSimulator.CoreSimulatorService.xpc/Contents/MacOS/com.apple.CoreSimulator.CoreSimulatorService,013e2787748a74103d62d2cdbf77a1345517c482,Software Signing
[2014-12-27 02:29:45.066Z] I santad: A,C,5890e93dc6ce4c6d644a0a8a380f7ab6571bc339,/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/Support/SFLSharedPrefsTool,013e2787748a74103d62d2cdbf77a1345517c482,Software Signing
[2014-12-27 02:29:46.763Z] I santad: A,C,37baf396741895e0a545e2f2e5c69b92151a52ad,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/CVMCompiler,013e2787748a74103d62d2cdbf77a1345517c482,Software Signing
[2014-12-27 02:30:02.564Z] I santad: A,C,99f2b9543f1ea368f5534f92983ef943b2d6b2b3,/usr/sbin/newsyslog,013e2787748a74103d62d2cdbf77a1345517c482,Software Signing
[2014-12-27 02:30:11.064Z] I santad: A,C,becb40a888c8e534074c30fb6e5564e06089de23,/System/Library/Frameworks/QuickLook.framework/Versions/A/Resources/quicklookd.app/Contents/MacOS/quicklookd,013e2787748a74103d62d2cdbf77a1345517c482,Software Signing
[2014-12-27 02:30:13.429Z] I santad: A,?,42c3dc767ce1ba241b58542b7e0f6a0be5efa349,/Applications/Keka.app/Contents/Resources/keka7z,e6ce66e3d69f49515bd8c0b5cdda8edc0f1b7b83,Developer ID Application: Jorge Garcia Armero
