https://github.com/osquery/osquery logo
Title
t

Thomas Stromberg

02/08/2023, 11:43 PM
I have a
file
query that I would like to be able to recurse directories that begin with a '.' (hidden), but I can't figure out the right magic incantation for the life of me. For example, if you run this to prepare the test:
mkdir -p /tmp/.out/.omg && cp /bin/ls /tmp/.out/.omg
You can find this file in osquery using:
SELECT path FROM file WHERE file.directory = '/tmp/.out/.omg';
But how would I find it without knowing what subdirectories in /tmp that it's part of? Ideally I'd love '/tmp/%%' to have returned it, but it doesn't include directories that begin with a dot. This also returns zero result:
SELECT path FROM file WHERE file.directory = '/tmp/.%/.%';
As does:
SELECT path FROM file WHERE file.directory = '/tmp/.out/.o%';
macOS & Linux both behave similarly, using osquery 5.7.0.
I did skim through these articles again but neither seemed to mention the observed behavior: • https://www.kolide.com/blog/the-file-table-osquery-s-secret-weaponhttps://www.uptycs.com/blog/wildcards-and-globbing-in-osquery
s

seph

02/08/2023, 11:49 PM
:thinks: Yeah, I recall some conversation, somewhere, about how it doesn’t traverse through the dot directories. I don’t know if there’s a workaround.
t

Thomas Stromberg

02/09/2023, 12:26 AM
Funny enough, the issue was fully between the seat and the keyboard. I accidentally switched to using
=
instead of
LIKE
when doing the hidden directory tests. This works:
SELECT path FROM file
WHERE
file.directory LIKE '/tmp/.%/.%'
AND NOT file.directory LIKE '%/../%'
AND NOT file.directory LIKE '%/./%';
It's awkward to add the second two filters, but otherwise you end up with a lot of weird content entries, like
/tmp/././out
and
/tmp/../../etc
Here's the query I was refactoring to try to speed up: https://raw.githubusercontent.com/chainguard-dev/osquery-defense-kit/main/detection/evasion/unexpected-tmp-executables-macos.sql I managed to make it 50% faster, but that was likely more due to me restricting the recursion depth than subquery trickery.
s

seph

02/09/2023, 1:15 AM
I can’t really absorb this, but I wonder if you’d do better with a regex there.