Closed dremspider closed 1 year ago
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?
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:
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.
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:
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:
Other than that, the tool is pretty easy to use! So far I haven't had any issues.
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, 0f3a22878848102daa12f4690b1fb7e03ae90233.
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:
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.
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.
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 notifications@github.com wrote:
plutil -convert xml1 -o - x.plist
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.
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.
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.
I don't see an easy way to set up the initial information about executables on your system. I played with a Python script (sorry my ruby skills are limited) that parses the log file and grabs unique paths and developers that have been launched. My idea is to extend this to allow the user to let this run for a while, and then run this tool that would parse through the logs and allow them to add exceptions as they would see fit. Right now, it is just dumping out the info.
More ideas for the future: -Dump to some sort of json/xml structure and allow the user to edit, user can then accept all executables in that xml structure -Allow the user to see what recently has been denied, then maybe approve the executable easily -Allow the user to only see non-signed executables and signed executables (so that they can accept the cert first, then add a rule for the path
Is there any tool like this? Would you be interested in me extending this idea? Should I just make it a separate project or would you be interested in integrating this with your project?
The output is this:
Unique Executables: Path of the executable: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdworker Common name of the certificate that signed the executable: (null) SHA256 hash of the executable: None SHA256 hash of the cert that signed the executable: None
Unique Publishers: Common Name: Apple Mac OS Application Signing SHA256 hash of the cert that signed the executable: ad9dba778a3a1204a02298193be3c8d184a6bdc0d10ae109dfaf356722b3cf92
....Continued......
Code is:
SantaParseLibs.py:
author = 'dlohin'
class santa_data_structure(object): def init(self,executable_cn = None, executable_hash = None, cert_hash = None): """ Pass in each entry of santa.log and add it to a dictionary :type executable_cn: str :type executable_hash: str :type cert_hash: str """ self.executable_cn= executable_cn self.executable_hash = executable_hash self.cert_hash = cert_hash
SantaParser.py:
author = 'dlohin'
from SantaParseLibs import santa_data_structure import re
f = open('/var/log/santa.log',mode='r')
unique_executables = {} unique_publishers={}
for line in f:
print(i)
Lets print out all the information
print("Unique Executables:") for key, value in unique_executables.items(): print(" Path of the executable: %s" % key) print(" Common name of the certificate that signed the executable: %s" % value.executable_cn) print(" SHA256 hash of the executable: %s" % value.executable_hash) print(" SHA256 hash of the cert that signed the executable: %s\n" % value.cert_hash)
print("Unique Publishers:") for key, value in unique_publishers.items(): print(" Common Name: %s" % key) print(" SHA256 hash of the cert that signed the executable: %s\n" % value)