Or fleet will report version it sees of log4j below 2.15 as vulnerable?

Osquery doesn't have a way to detect Java libraries, so we won't be able to do so directly.

My thought process is every log4j instance is vulnerable until patched so planning to do Osquery yara based scanning using the following as a starting point to identify any usage in the estate https://github.com/timb-machine/log4j

Oh nice, good idea to use yara.

May also be a nice blog post 🙂 for fleet.

i would love to see that, i dont know much about yara but i would definitely love to learn good uses for it

I consider Yara strings on steroids , it’s probably not the most efficient use of Osquery tables here, as the file table would be quicker for determine the existing of the Java libs and then Yara to do a strings match.

@Gavin here's what I came up with based on that:

WITH target_jars AS
(SELECT DISTINCT path from
(WITH split(word, str) AS (
    SELECT '', cmdline||' ' FROM processes
    UNION ALL SELECT
    substr(str, 0, instr(str, ' ')),
    substr(str, instr(str, ' ')+1)
    FROM split WHERE str!=''
) SELECT word AS path FROM split WHERE word like '%.jar'
UNION ALL
select path from process_open_files where path like '%.jar'
)) select path, matches from yara where path in (select path from target_jars) and count > 0 and sigrule IN (
'rule log4jJndiLookup {
  meta:
    author = "Tim Brown @timb_machine"
    description = "Hunts for references to Log4J JndiLookup"
  strings:
    $jndilookup = "JndiLookup"
  condition:
    $jndilookup
}',
'rule log4jjavaclass {
  meta:
    author = "Tim Brown @timb_machine"
    description = "Hunts for references to Log4J java in class form"
  strings:
    $javaclass = "org/apache/logging/log4j"
  condition:
    $javaclass
}'
);

Uptycs already got one out on the similar Vain

They have some good queries there. Their Yara rules (https://gist.github.com/ureddy-uptycs/4fdd68e859f022e65e7b7779e247f0d0) seem to be detecting exploitation, not existence of the library.

Very good point, I would like to see vanilla detections, My mitigations / detections ended up breaking out of OSquery for quickness but I am going to look into wrapping the tooling used into an extension instead. Mainly rg for quickness.

Awesome glad to hear that!

yea I don't know anything abvout YARA but as good as any time to learn I spose

Opened this a while ago for Yara endpoint on Fleet, maybe time to revisit it 😉 https://github.com/fleetdm/fleet/issues/1047

Will comment on the issue I have actually given this a whole bunch of thought over the past days about pro’s and con’s of a public Yara ruleset for your business. We currently have some basic rules deployed via puppet to localhost and loaded as a config. I imagine this may be a really good feature for orbit where you can define rules orbit can pick them up and load them on the fly for privacy.

What I was thinking was that Fleet be the repo and Osquery gets the yara rules from there.

The fleet server itself? , Hypothetical question. What happens if a business you expose your server to the internet so you can monitor devices off VPN And you have a whole bunch of proprietary Yara rules does osquery support auth to that endpoint? One option is to make the endpoint something like

fleet/secretstring/rule

in the absence of something like mutual TLS or any other auth.

Hey @Gavin did not think about proprietary Yara rules, that is a good question. My view was that, for example, through the UI you can import Yara rules and deploy them to the osquery agents.

Nice query, is there any table that can be used instead of

process_open_files

to be able to run this query in windows endpoints? 🙂