New Idea for an easier tool to inventory all executables about santa HOT 10 CLOSED

It could also be possible to use this tool for forensic history. Run the command and see all the dates and arguments a particular commaND was run. I noticed that it appears that the log file isn't persistent and seems to get wiped out? Maybe after reboot?

from santa.

We don't have anything like this but it certainly is a good idea. I'd prefer to see it added as a command to santactl, using the SNTFileInfo class to grab the details though, rather than looking through the log.

The log file is rotated by ASL when it reaches a certain size. For forensic history we're relying on either/or:

1. Having some system collect the log from the machine regularly, which many organizations running Macs already do.
2. Connecting clients to a server so Santa can upload execution events for analysis and management of the rules.

Though I can definitely see value in evaluating all binaries on a host when Santa is first installed but this would need to be run in the background with as little performance penalty as possible.

from santa.

Thank you very much for you time. I have a total of about 2 weeks experience with Mac systems. Most of my experience came from managing security in Linux enterprise systems and figured I would give it a shot. I have been looking to learn more about the OS and how it differs from Linux. I wasn't aware of ASL, but I see now it is very similiar to sylog/logrotate, thanks for the info.

I could see two purposes of a tool like this:

1. The what the heck is being launched on my system approach... This is how I used it. I ran your tool in monitor mode for a little bit and then clicked on everything I could find and let the logs fill up. I then ran this tool and got a list of all the developers/paths and made exceptions to them as I saw fit. Ideal, no but it worked.
2. The maintaining a baseline approach. This is how I have used most enterprise whitelisting tools in the past. We build a system which has all the software our users have and we only use it for the purpose of whitelisting so that we can be sure it won't be compromised. When software needs to be added/updated we deploy to this system first, record the changes and add it to our whitelist. We then push the software/updates.

Perhaps it would be possible to create a "unique" executable table in the SQLite database. When a file is read, the program first checks if it is trusted, if it isn't see if the file has been seen before. If it hasn't it adds an entry to this table. It would then be possible to go in and easily accept or investigate the executables. This would make the monitor mode a lot more useful and ensure that when you do lock it down, you can be confident you got most of the files. Santactl could then be used to pull this information from the table. It would also be possible to warn (maybe add a notification in the notification center) when a hash has changed to turn the monitor mode into a simple file integrity monitor.

Not sure if this approach would be much better, I have never programmed in objective-c so I am not sure how useful I would be though maybe now is a good time to learn :-).

Some things I learned while using the tool... I didn't have a config.plist. I had to create it, no idea why. Once I did, I couldn't modify it. When I would save the file with vi and then save it, it would revert back. I found that I had to stop the service before editing the file with:
kextunload /Library/Extensions/santa-driver.kext/
launchctl unload /Library/LaunchDaemons/com.google.santad.plist

Then I could modify it, the start it up again.

One area that I was really confused with was santactl for adding rules. I thought that path would add an exception that would allow the executable that is at that path regardless of the hash or binary at that location and sha256 would allow any executable with that sha hash to execute (i.e. sha256sum). I later figure out that path would allow that executable to run with that specific hash and that sha256 was allowing by a certificate. I would recommend making this more clear in the usage information:

• (NSString *)longHelpText {
  return (@"Usage: santactl rule {add|remove} [options]\n"
  @" --whitelist: add to whitelist\n"
  @" --blacklist: add to blacklist\n"
  @" --silent-blacklist: add to silent blacklist\n"
  @" --message {message}: custom message\n"
  @" --path {path}: Will match on any executable with the hash of the file as specified in the path\n"
  @" --sha256 {sha256}: Will match on any executable which has been signed by a certificate with the sha256 hash specified\n");
  }

Other than that, the tool is pretty easy to use! So far I haven't had any issues.

from santa.

Santa actually keeps a database of blocked or allowed-but-unknown binaries in a second SQLite database called events.db, these events are intended to be uploaded to a central server where you would manage the whitelist. We're still working on the server side and hope to have it open sourced before the end of the year.

As our intention is to use Santa with this server, I haven't spent much time thinking about single user machines or using Santa without a server, though I can certainly see the appeal of this. When I have a bit more time, I'll investigate this further.

Without a config.plist Santa should still run, using some very basic defaults. Did you get an error when you tried?

Some of the keys in the config.plist are protected when santad is running, as you found.

For the rule help text: good suggestion, 0f3a228.

from santa.

Config.plist, no it worked fine, I was just confused because I was trying to set it to block and the file wasn't there.

The eventsdb would have been useful for me earlier. How do I read this?

95|a8c7932565aaa1cc98337e1a22bc39495af7b4d1b41f4f1e2853677b8d191d06|bplist00?z{X$versionX$objectsY$archiverT$top

eventsdata clearly is what I need, but I am not sure what it all means. How do I pull the file path/hash/certificate from this to be able to create a rule to allow this or is this somehow encrypted so only the server can read this?

61|13a2f6fa0a166324139ac00dfb9cb5bda14b1900e7e9e06c1e981eb5d8b751a2|bplist00?JKX$versionX$objectsY$archiverT$top

If I know this I could easily develop a python script to pull this data and accomplish something similar to what I was doing before with the event logs before. I started looking the code, I have some C background, though haven't touched it in a few years. I though how different could objective C be... Boy was I wrong, brackets everywhere, pluses and minuses in front of functions?/methods? I think... I started looking into it to see if I could do anything.

Some thoughts on how to make this really work well for personal users:

1. Have a setting for enterprise or personal mode.
2. Allow the user to modify the settings/view the events from an application (preference pane?).
3. When the user is prompted for the executable being blocked give them the option to create whitelist rules (with a password of course).

What would be really awesome, though a lot of work is some sort of file reputation service. All users submit their newly seen hashes to a server (scale matters here, so it would be better as a cloud type service), the server on the other end would rate the executable. The rating would be low, if the executable was never seen before (or seen only recently) and would be high if it has seen lots of users. This of course is me dreaming.

I will continue messing with objective c, but I can't promise anything. All my GUI experience is visual studio/c# so I have a bit of a learning curve. I would imagine that I could use your santactl example to see if I could get the GUI added.

from santa.

The events in the database are archived Objective-C objects, you can extract them with:

sqlite3 /var/db/santa/events.db "SELECT writefile(idx || '.plist', eventdata) FROM events;"

And read them with plutil -convert xml1 -o - x.plist.

Unfortunately the format is not intended for easy consumption outside of the app which produced it.

from santa.

Very cool, this would have made it a lot easier.

I could begin working on a Python tool to pull this information.

https://docs.python.org/3/library/plistlib.html https://docs.python.org/3/library/plistlib.html

Python 2.X comes with Mac I believe though I had to install Python 3.X. My code currently is 3.X, but it should be easy for me to convert it to 2.X. It appears that the python that is included includes plistlib to de-serialize this information so the user wouldn’t need to install anything extra.

Would you be interested in a tool such as this?

I don’t have the skills to do this in Objective-C at this time.

On Sep 29, 2015, at 3:19 PM, Russell Hancox [email protected] wrote:

plutil -convert xml1 -o - x.plist

from santa.

I have been spending a bit of time learning objective-C. I now can at least understand the code a bit better. Objective-C is an interesting mix of C and its own weird concoction. I agree that it would be better for pulling from this events.db database. From my brief looking at SntFileInfo, it appears this is the class which is called for getting information about a file (i.e. who signed it, what is it's hash, etc). I would like to pull the information directly from the database because the file may be long gone by the time you get to the database.

I am going to try to get to eventually playing with it and maybe adding a command to santactl to dump all the information from the database and make it in a more user friendly format. It could be a real, practical way for me to learn objective-c. All my experience has been with C#, so it could be a fun way to learn.

from santa.

Sorry, I'd meant to respond to this sooner but got sidetracked.

The class that is serialized into the database is actually SNTStoredEvent (SNTFileInfo gathers the data as you identified but it's stored by way of SNTStoredEvent which has no logic in it other than the ability to be transported between processes). As santactl isn't meant to access the databases directly, there's an RPC system for asking the daemon to send over events that are in the database (as used in the sync command) and it will handle the deserializing back into objects for you.

Adding this is a command to santactl should be relatively easy. I'd suggest using the status command as a starting template as it's quite short but still requires a daemon connection. You can then look at SNTCommandSyncEventUpload, which shows how to get the events via the daemon (lines 36 and 57).

I'm always happy to help if you get stuck, we have a Google Group called santa-dev that you can sign up and post to.

from santa.

Closing this as we've not done it in over 5 years. We may revisit this at some point in the future but I think that needs another feature request.

from santa.