Title
#general
Mystery Incorporated

Mystery Incorporated

08/03/2021, 9:50 AM
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

wkleinhenz

08/03/2021, 12:38 PM
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
Mystery Incorporated

Mystery Incorporated

08/03/2021, 3:51 PM
@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.
3:54 PM
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.
3:56 PM
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

wkleinhenz

08/03/2021, 3:57 PM
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
Mystery Incorporated

Mystery Incorporated

08/03/2021, 3:59 PM
@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.
4:06 PM
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

wkleinhenz

08/03/2021, 4:06 PM
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
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:07 PM
@wkleinhenz yes that's what I said start hashing bins looking, but that behaviour should be picked up in heuristics
4:07 PM
So if a process starts hashing binaries AV should see that behaviour and neuter it
w

wkleinhenz

08/03/2021, 4:08 PM
right so why wouldnt that also work for a bad proc killing other procs
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:09 PM
terminating a process is not as obvious as hashing all processes. One single action vs a consistent number of same actions.
4:10 PM
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

wkleinhenz

08/03/2021, 4:14 PM
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
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:20 PM
@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

wkleinhenz

08/03/2021, 4:21 PM
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
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:21 PM
@wkleinhenz but if all those things are in standard paths, what stops me just turning them all off?
w

wkleinhenz

08/03/2021, 4:21 PM
im against it cause its an anti pattern in security, why do i have to be a dev to object
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:22 PM
And for windows event logs i simply need to turn off the log shipper like filebeat or whatever is being used.
w

wkleinhenz

08/03/2021, 4:22 PM
thats the point you make it so you cant stop them
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:22 PM
your anti-anti-pattern is creating a pattern lol
4:23 PM
Look to the kayesa ransomware, it was using known paths to kill AV and do damage.
w

wkleinhenz

08/03/2021, 4:23 PM
the point is secrecy doesnt stop some one from doing something it just adds some extra steps
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:23 PM
I am well aware of the security by obscurity factor. this isn't adding security, this is hardening.
4:24 PM
we're not saying the system is more secure, we are simply hardening our tools from attack
4:24 PM
Like setting kernel settings in sysctl.conf to harden the kernel from attack
4:28 PM
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.
4:33 PM
"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.
Mike Myers

Mike Myers

08/03/2021, 4:34 PM
Though you're not wrong, the osquery threat model does not include attackers on host with administrator/root permission
w

wkleinhenz

08/03/2021, 4:34 PM
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
Mike Myers

Mike Myers

08/03/2021, 4:35 PM
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:36 PM
@wkleinhenz are you suggesting that people for example should just leave ssh on port 22?
w

wkleinhenz

08/03/2021, 4:37 PM
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
4:38 PM
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
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:39 PM
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

wkleinhenz

08/03/2021, 4:41 PM
right, but thats what security by obscurity is, securing things via an arbitrary secret
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:45 PM
@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

wkleinhenz

08/03/2021, 4:46 PM
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
4:47 PM
just like here, you can change the osquery install location or service name but if the system itself isnt secure it doesnt matter
4:47 PM
look at the differences between cryptography and encoding
Pensamento Profundo

Pensamento Profundo

08/03/2021, 4:48 PM
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...
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:48 PM
@Pensamento Profundo bingo.
4:49 PM
And @Mike Myers does raise an interesting point of the threat model osquery operates too
4:51 PM
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?
Mike Myers

Mike Myers

08/03/2021, 4:55 PM
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
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:56 PM
@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?
4:57 PM
I think for windows it'd just be the service name
Mike Myers

Mike Myers

08/03/2021, 4:57 PM
office hours starts in a few minutes if you'd like to add this discussion #officehours
Mystery Incorporated

Mystery Incorporated

08/03/2021, 4:59 PM
Sure, looks like 0300 is officehours for me hahaha
puffycid

puffycid

08/03/2021, 5:36 PM
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
Mystery Incorporated

Mystery Incorporated

08/03/2021, 5:44 PM
@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 😅