Free Tool: Low-Impact Log4j CVE-2021-44228 Detection

[strawgate]

Over the last week we’ve been hard at work using our OT-tuned agent and some novel detection techniques to find active Java applications utilizing Log4j libraries on Windows and Linux. Our customers in the Operational Technology (OT) world need a detection mechanism that won’t stop them from generating power, bottling vaccines, and producing microchips. As a result, and based on our 3 decades of serving the OT industry, we focus on and provide the least intrusive (OT safe) ways to detect and protect.

Our detector lets our customers discover vulnerable systems quickly and plan remediation while they work to figure out when they’re going to run the big and heavy scanners from their other vendors.

Not one of our customers? We’ve worked to make a generalized version of our detector available for free for all BigFix users here: https://github.com/VerveIndustrialProtection/CVE-2021-44228-Log4j

Update (12/20) : Significant additions to the Verve Log4j Content are outlined here: Free Tools: Multiple Log4j Detection Mechanisms + Remediation

[strawgate]

This content has average runtimes in our environment of 1-2s without running anything in the background past the completion of the fixlet.

This content takes a different approach from most others. It is likely to produce false negatives (it is not a perfect detection mechanism) but hopefully minimizes false positive. The most vulnerable systems are systems running java-based servers (web servers, background servers, etc) and not java-based desktop apps. If the JAR hasn’t been fat-packed then each JAR will be an open file handle by the java process. We can use this information to look for java processes, see if Log4j is present and then report the version of Log4j present.

This content does not recursively open JAR files, does not find JAR files not in use on the system, does not find JAR files by their hashes, and may miss beta versions of the Log4j JARs. For that functionality seek out a heavier handed solution like logpresso.

[Mario]

I do like this approach, would be great for servers with external access on a constant basis.

I had a similar idea pop into my head when I was researching how to find a working java on the machine as one of the methods presented was exactly this fashion on linux.

However instructions from clients and top is to do the full scan on all jars.
Nice work however

[strawgate]

As discussed in the readme, this is a complementary solution – It’s meant to give teams a list of servers that definitely require remediation with low false positives while they figure out how they are going to do full system scans.

[Mario]

Yeah indeed, I am a big fan of this approach, it has its place for sure However the clients we deal with are prefering the full on approach as the remediations and testing are looking like a 6 plus month project

[JasonWalker]

Thank you so much for your work on this and making it available to everyone. I like this approach as well, especially as it could allow ongoing monitoring of systems after a first-scrub.

I’ve updated our pinned “Summary” thread with links to your GitHub and to this discussion thread, I look forward to hearing where this helps.

I’m also going to trim this thread of some responses on the logistics of download the files, and want to link to a tip on downloading content from GitHub: Tips: Downloading files from GitHub

[strawgate]

I’ve gotten some questions about what “low-impact” means:

Our median run-time is 1s with some endpoints finishing so quickly they actually report completing in 0 seconds. This is not a fixlet that starts a background job and returns right away. This is 1 second to find out you’re vulnerable to Log4j.

We’re hard at work adding additional capabilities to our content including nested JAR detection without full-system scans. PM me if you’re interested in helping test.

[strawgate]

An additional note from our testing – the basic Detector (enhanced detector coming soon) appears to be able to locate vulnerable Log4j libraries used by processes in Docker containers on Linux Docker hosts.

[jgstew]

locate vulnerable Log4j libraries used by processes in Docker containers

That is interesting.

I assume this is only applicable if running the detection on a Linux host that is running docker containers, since on Windows you wouldn’t have visibility to the processes running in a VM.