check_dtrace - A Volatility Plugin Arises

Summary

After reading through fG!'s presentation on OS X rootkits I decided to look into some other D-Trace providers, such as fbt and mach_trap to close the loop on the D-Trace topic. While this endeavor didn't start with the intention of building a plugin, I decided to do so to save time for myself and possibly others (and of course have some fun!).

Some OS X D-Trace providers

The D-Trace fbt provider has probes for almost all kernel functions, and is generally more useful when monitoring a particular behavior or issue in a specific kernel subsystem. This provider is very sensitive about OS versions so it requires some knowledge of OS internals.

The syscall provider, on the other hand, let's you monitor the entry point into the kernel from applications in userland and is not very OS specific. While the syscall provider dynamically rewrites the syscall table, the fbt provider manipulates the stack to transfer the control to the IDT handler, which transfers the control to the D-Trace probe, which in turn emulates the replaced instruction.

The mach_trap probes fire on entry or return of the specified Mach library function. Nemo uses this provider to hide processes from ps and the Activity Monitor in his presentation.

You can find a full list of providers at the Apple site, but I'll be focusing on the three providers mentioned above.

Analysis 

This time instead of collecting memory samples, I created an OS X VM using VMWare Fusion to do some live analysis since the Volatility Framework can work with vmem files. Creating a VM is pretty straight forward if you have the OS X installer app handy. To run a Volatility command on a vmem file:

$ python vol.py mac_check_dtrace -f ~/Documents/Virtual\ Machines/Mac\ OS\ X\ 10.8\ 64-bit.vmwarevm/563d899c-18ee-3dc2-0fec-60b3b62d2b34.vmem --profile=MacMountainLion_10_8_3_AMDx64

I already had talked about finding syscall probes in my previous post so I'll skip that. The mach_trap probe announces its presence in a similar fashion to a syscall probe by replacing a trap table entry with a '_dtrace_machtrace_syscall' entry, thus making it easy to detect using the Volatility plugin check_trap_table:

The fbt probe on the other hand is not that obvious. The Volatility syscall plugin will not show any D-Trace or 'hooked' entries while the following D-Trace command is running:

$ sudo dtrace -n 'fbt:mach_kernel:getdirentries64:entry{printf("%x",arg0);}'

To detect the fbt probe, fG! provided a few good pointers in his latest presentation about OS X rootkits. Using Volatility's mac_volshell plugin we can monitor the changes:

The screenshot above shows the side by side comparison of before and during running the fbt probe. As suggested by fG!, the disassembly of the function shows that it has been patched. The check_dtrace plugin checks for the presence of this patch to detect the fbt probe.

A Plugin Arises

To save us the trouble of running three separate plugins and other commands, I've built the 'check_dtrace' plugin to detect syscall, mach_trap, and fbt probes to incorporate the discussed analysis. The plugin can be found at github.

Below is a sample output of the plugin:

The plugin was able to detect all three probes running concurrently at the target host.

Conclusion

Thanks to fG!, Nemo and the Volatility Framework, I did have a good time with OS X internals! While the check_dtrace plugin is not that complex, it's able to detect otherwise not so obvious D-Trace rootkit techniques. And again we have seen that it's tough to hide in memory.