Adding Hidden LaunchAgent/Daemon Discovery #8053
Conversation
| return Status(1, "Target directory is invalid"); | ||
| } | ||
|
|
||
| if (recursive) { |
There was a problem hiding this comment.
I don't know these libraries very well -- if there's a symlink loop here, what happens?
There was a problem hiding this comment.
If there is I believe that risks already exists as a result of this PR... #7974 (comment)
I'm reusing the code that was introduced for directory listing to list files here. So I'm also uncertain as to whether there is a potential symlink loop... but if there is I believe it'll already exist 馃憖
There was a problem hiding this comment.
Symlinks should not be a problem because recursion for those is by default disabled; it's documented here https://www.boost.org/doc/libs/1_77_0/libs/filesystem/doc/reference.html#Class-recursive_directory_iterator
[Note: By default, recursive_directory_iterator does not follow directory symlinks. To follow directory symlinks, specify directory_options::follow_directory_symlink in opts. 鈥攅nd note]
But I think the directory PR (and this PR) might still have issues with hardlinks, junctions and the directory PR it's incorrectly returning all symlinks as if they were directories.
I think it's important to test this situations on at least Linux and Windows.
mike-myers-tob
added
virtual tables
macOS
ready for review
|
Closing and reopening to kick the CI |
There was a problem hiding this comment.
I left a comment about recursion, I think this needs further tests to verify its functionality (and also CI tests that can be run to verify the behavior).
Finally, the CI is currently failing because there's a test that it's "importing" via extern the removed alternative that was called here; since it's the last place where it was directly used (and it's not a public function) the linker is dropping it.
Long story short, all the references and implementation of listInAbsoluteDirectory should be removed.
Please see the original PR for historical comments. Opening a clean PR to move away from some chaotic branch conflicts.
Hidden LaunchAgent/Daemon Discovery
Background
As per this issue -> #7703 <- this PR introduces the capability for osquery to identify LaunchAgents/Daemons that are defined in hidden
.plistfiles.The TL;DR from the issue linked above is ->
Malware commonly persists on macOS devices using LaunchAgents/Daemons. It has been observed that certain malware samples have been utilising hidden
plistfiles i.e./Library/LaunchDaemons/.com.apple.WindowServer.plist. This PR aims to cover off this blind spot within the current launchd table.Changes
One file has been altered within this PR:
osquery/filesystem/filesystem.cpp- adding a consistent approach to discovering files and directories. This allows us to identify hidden files; which in this case enables us to identify hidden launch items.Impact
This PR prevents malicious LaunchAgents/Daemons from evading detection by using a hidden plist files. As shown in the screenshot below, we can now identify these hidden plists:
Updates
Since the opening of the original PR, @marcosd4h made some great changes to directory listing (馃憦) - which I was able to replicate for file discovery to allow us to identify hidden files. Specifically in this case to target macOS launch items.
cc. @Smjert, @directionless from the previous PR.