https://github.com/osquery/osquery logo
Join Slack
Powered by
A question I have, is it silly to have something l...
# general
m
A question I have, is it silly to have something like osquery installed in a fixed path? And also fixed name of osqueryd service. It seems to me like it would be trivial for any bad software to check (for example) C:\Program Files\osquery and /or check for osqueryd service and just stop the service/delete the path. Shouldn't we be doing things like all using different paths and service names to avoid such a thing happening?
w
changing path names and changing service names imo fail in to security by obscurity level things, itll make things way harder to integrate in the future if you have 1k systems with 1k different service names. i think its better to focus on defense in depth, adding more and more layers to your defense
m
@wkleinhenz yes sorry I wasn't clear, so I meant random amongst us, so you and I are not using the same paths. So our entire fleet might use the same path, but it's not a given what that path is we will chose. as it stands now, if everyone is saving to C:\Program Files\osquery a bad actor can simply look there to yay or nay osquery on device. If we mitigate such simple things, then we force the bad process to start hashing all services to find osquery (or maybe it searches the binary for certain strings) but this behaviour should be caught by heuristics.
So maybe for my entire fleet I can save to C:/ProgramData/JimBob and I can name my service bobjimmyd and then the bad process will have to actually parse each service or each folder path looking for osquery instead of one quick filesystem or service exists check.
Because if they know that literally everyone who uses osqueryd has the service name osqueryd, then they only need to look for that. We make it far too easy for them why?
w
right my statement still applies. make sure that osquery isnt your only reporting tool, make sure standard users cant stop any of those monitoring tools and create alerts for when they stop for any reason
m
@wkleinhenz still I think we need to be hardening osqueryd like I suggest. i can't see any downsides to doing it, only positives, and it will make it much harder for bad process to kill osqueryd undetected.
I notice Bitdefender enterprise is good in that it lets you remotely deploy to different paths even at a policy level. I think they realise that being in the one path consistently is insane. It's like standing on top of a hill with no trees with artillery zeroing in on you, why do that to yourself on purpose?
w
i mean it wouldnt be too hard to just look for the hashes of osquery bin files in fact that might be a better way of hunting it anyway
m
@wkleinhenz yes that's what I said start hashing bins looking, but that behaviour should be picked up in heuristics
So if a process starts hashing binaries AV should see that behaviour and neuter it
w
right so why wouldnt that also work for a bad proc killing other procs
m
terminating a process is not as obvious as hashing all processes. One single action vs a consistent number of same actions.
There are many legitimate reasons to terminate a process. how many legitimate reasons are there to start sha1 every bin file? not too many I'd think
w
right but you can look for a process killing the OSquery process or service. im not sure buit i imagine there could be reasons for an entire filesystem to be hashed file by file things like searching are made faster with hashtables or FIM tools might do something similar but might also just look at file changes
m
@wkleinhenz I'm sure anyone can look for any process being terminated. But the question is, is it looking? I can tell you that at least for bitdefender, it doesn't care if you terminate osqueryd. So, we need to mitigate for this case and make it harder to simply just shutdown osqueryd. Not sure why you're so against it, are you an osquery developer?
w
right your AV might not but you should have something like sysmon, auditd, splunk, etc that is, even windows event logs can be configured to log like that
m
@wkleinhenz but if all those things are in standard paths, what stops me just turning them all off?
w
im against it cause its an anti pattern in security, why do i have to be a dev to object
m
And for windows event logs i simply need to turn off the log shipper like filebeat or whatever is being used.
w
thats the point you make it so you cant stop them
m
your anti-anti-pattern is creating a pattern lol
Look to the kayesa ransomware, it was using known paths to kill AV and do damage.
w
the point is secrecy doesnt stop some one from doing something it just adds some extra steps
m
I am well aware of the security by obscurity factor. this isn't adding security, this is hardening.
we're not saying the system is more secure, we are simply hardening our tools from attack
Like setting kernel settings in sysctl.conf to harden the kernel from attack
ASLR in RAM is another example, randomising the layout of process memory in RAM so that an attacker cannot predict the memory address of our processes. That's not security by obscurity despite it actually obscuring something, that's hardening.
"it just adds some extra steps" and extra steps means what?....... a greater chance of detection!!! Thus achieving a desirable outcome for us. As I said there only appears to be positives and no negatives from doing it, so why are we not doing it? The security by obscurity card does not fly here.
m
Though you're not wrong, the osquery threat model does not include attackers on host with administrator/root permission
w
ALSR isnt security by obscurity just like how encryption isnt security by obscurity. changing ports and service names is as it violates https://en.wikipedia.org/wiki/Kerckhoffs's_principle
m
m
@wkleinhenz are you suggesting that people for example should just leave ssh on port 22?
w
what im suggesting is that changing the ssh port to a different port isnt really security or hardening or whatever if you dont actually secure ssh
like if youre logging in as root with the password of toor with a weak cipher and a vulnerable version it doesnt matter what port it runs on
m
Sure a port number is just a number. I don't change it for security, I change it because it reduces the number of unauth access attempts (if the port is open public facing)
w
right, but thats what security by obscurity is, securing things via an arbitrary secret
m
@wkleinhenz so I'm not sure what you are saying. Are you saying we shouldn't change our SSH port from 22 because it reduces unauth access attempts and that'd be security by obscurity? or it's ok for us to change it from 22 to reduce unauth access attempts because less unauth access attempts is > security? (that's a fact)
w
the point is that changing port 22 isnt a factor, you can do it if you want but if ssh itself isnt secure it doesnt matter what port it uses
just like here, you can change the osquery install location or service name but if the system itself isnt secure it doesnt matter
look at the differences between cryptography and encoding
p
it will decrease the chances to be targeted but once targeted, if the service is not hardened (fail2ban etc) it would not make a difference...
m
@Pensamento Profundo bingo.
And @Mike Myers does raise an interesting point of the threat model osquery operates too
In saying that, I still think if it's not hard for the devs to enable (I tried to do it manually and the service just refused to start) I think there is a bit to be gained by allowing us to not plaster osqueryd everywhere as osqueryd. I think we can install to a different file path at the moment anyway right? At least on windows which is the bulk of my focus with this topic. I think it would be good to be able to run our service as a different name combined with different file path just to make the evil drops job harder and hopefully we can catch it first. I don't feel like this is trying to add a security assertion, merely a frustrater for the baddies. Given that I can see no disadvantages for us to do it, again the question comes back to why aren't we doing it?
m
if there's a usability case for it, you can raise an issue or PR on github. Moving the install path or making it configurable might be difficult for underlying reasons like EndpointSecurity on macOS but that's a different discussion than whether it's a useful desired thing or not
m
@Mike Myers yeh I'm not so worried about any of the *nix/darwin os, I think already we can choose the install path on windows can't we?
I think for windows it'd just be the service name
m
office hours starts in a few minutes if you'd like to add this discussion #officehours
m
Sure, looks like 0300 is officehours for me hahaha
p
If ur concerned about attacks deleting or stopping osquery file/service I think there r ways u could detect that Ex: Windows logs what services r stopped/started U could monitor for osquery service being stopped Also if u using a remote management server for osquery If an attacker stops/deletes osquery that still system will stop checking in to the server Depending on the organization and server settings that could be flagged or alerted But that could be difficult to implement/monitor
m
@puffycid yea but if osquery is your windows log analyser/shipper and it's off! You loose that visibility, at least remotely. For something like a server absolutely, osquery being off and uncontactable from fleet would be an IOC, but for an end user laptop not so much 😅
👍 1
3 Views
Open in Slack
PreviousNext
Powered by