@jgstew Trying to use the lsof command to ascertian whether log4j libraries are in use.
Can you see an issue with the way im trying to run this, see varied exit codes …
wait sh -c “for i in $(find / -iname ‘log4j’); do echo $(lsof $i); done > /var/opt/BESClient/BPS-Scans/lsof_results.txt”
You’ll have the same ‘find’ challenges we had, i.e. traversing symlinks and network shared filesystems.
What you’re trying looks to me similar to @strawgate’s method, detailed at Free Tool: Low-Impact Log4j CVE-2021-44228 Detection so suggest you have a look there.
I.E. instead of using ‘find’ to walk every filesystem, start with using ‘lsof’ to list everything and then filter the ‘lsof’ result.
Didn’t get any results using @strawgate method. Got random exit code 1 and exit code 2’s … no matching open handles found in the logs.
FYI, the newest releases of Logspresso scan utility in the last few hours have much improved exclusion of network shares: https://github.com/logpresso/CVE-2021-44228-Scanner/releases/tag/v2.3.7
--exclude-fs nfs,tmpfs
Exclude paths by file system type. nfs, nfs3, nfs4, cifs, tmpfs, devtmpfs, fuse.sshfs and iso9660 is ignored by default.
I will update the tasks to use the newest utility shortly.
See, this is why I can’t do release notes 
I’ve added another post to our Summary thread at Log4j CVE-2021-44228, CVE-2021-45046 Summary Page
Please see here for refreshed Scan tasks (using Logpresso 2.3.6, new refresh coming soon); additional Task to scan by downloading temporary JRE on Windows, Linux, and Mac; additional Task to scan by using the existing installed Java; and additonal task to scan using Mac native binary.
The Linux, Mac, and Java scans have been enhanced to allow adding your own list of path exclusions, on the Description page of the task.
The “Run: log4j2-scan v2.3.6 - Universal JAR - System JRE” Task allows insight into a wider range of operating systems, where you already have a JRE of version 7 or higher installed. Last night I was able to scan SunOS 5.11 and Raspberry Pi Raspbian with it.
More version and task refreshes coming soon, more OS support for the “temporary JRE” scans coming soon.
We also need your feedback. We’ve made many updates on the scan tasks, and Logpresso on their tool itself, to try to exclude network paths from being scanned and overwhelming fileservers. Please let us know in this thread whether that is still an issue in the latest versions of the scans (including telling us “yeah, it seems ok to me”).
If you’re still seeing network paths being hit by the scans, please give us as much detail as you can - what operating systems and versions, are they nfs, cifs, sshfs, gpfs, or something else. Is it automount? Can you post copies of your /etc/fstab, ‘mount’ command output, ‘df’ command output, anything that would help us build exclusions.
Again, thank you all for working through this with us. I’m sure for most of us this is the most severe and widespread security issue we’ve faced, and it’s great how the entire cyber community is coming together to protect each other.
If you’re having issues with the content you can post on the issues portion of the GitHub page: https://github.com/VerveIndustrialProtection/CVE-2021-44228-Log4j/issues
Can you elaborate on that? I’m not sure whether you should be expecting results or not - you should definitely get results if you have an application actively loading the vulnerable log4j files, but if it’s not in active use, at least his primary scan method should not alert on it.
Which of the Verve / strawgate scan methods did you use? There are at least two, possibly three, at this point.
Ideally we move troubleshooting for the Verve content to the github repo as Verve has a couple of folks involved in support watching the repo (and we don’t clog up this chat). If you’re having issues with verve content please post here: https://github.com/VerveIndustrialProtection/CVE-2021-44228-Log4j/issues and we will provide support.
This command and relevance provides what we are looking for -
lsof | grep log4j > /var/opt/BESClient/BPS-Scans/lsof_results.txt
unique values of (following texts of firsts " /" of lines of file “lsof_results.txt” of folder “/var/opt/BESClient/BPS-Scans”)
We are joining this data with the results from Logpresso scanning.
Another filesystem for academics would be AFS to add to the list.
I’ve deployed it on 6 macOS systems and see data from 5 of the system in results analysis. Either the other one is still running or has not checked in yet.
Thank you Jason. I tested it, its working on some and not working for some servers.
May i use this relevance, the old one? Just modifying the version to include "2.16.0"
This is the example: /app/MSTR/install/jar/log4j-core-2.16.0.jar
As per the relevance, it should not show the above result as the version is 2.16.0
I’m not sure why the old relevance still shows the results, could you help modify the relevance.
it whose (not exists (following texts of last “log4j-core” of it) whose (it as version >= version “2.16.0”)) of (it as string) of (if exists property “locked lines” then locked lines of it else lines of it) whose (it does not start with “SCAN_COMPLETE” and it as lowercase does not end with “-javadoc.jar” and it as lowercase does not end with “-sources.jar” and it as lowercase does not end with “-tests.jar”) of files “BPS-Scans/CVE-2021-44228.txt” of folder(pathname of parent folder of parent folder of client folder of site “actionsite”)
ah, so that is one that should be excluded? interesting. We can add that, but also provide feedback to logpresso utility that it should be excluded. Do you know if it shows up as just afs in the mount -l command and/or relevance? I am assuming so?
2.16.0 is still vulnerable, just not to the original CVE. You need to be 2.17 to be in the clear. Even 2.15 should be clear of the original very bad remote code execution vulnerability.
If you are on anything other than 2.17 then you have known CVEs you are still vulnerable to, just not as many as 2.14 or 2.15.
Thank you.
Does this relevance look for versions below 2.16? Could you please help with that.
it whose (not exists (following texts of last “log4j-core” of it) whose (it as version >= version “2.16.0”)) of (it as string) of (if exists property “locked lines” then locked lines of it else lines of it) whose (it does not start with “SCAN_COMPLETE” and it as lowercase does not end with “-javadoc.jar” and it as lowercase does not end with “-sources.jar” and it as lowercase does not end with “-tests.jar”) of files “BPS-Scans/CVE-2021-44228.txt” of folder(pathname of parent folder of parent folder of client folder of site “actionsite”)That looks like what it’s trying to do, but also it’s an older version of what I had in the analysis, and also that’s deprecated in favor of the LogPresso scans and analysis
FYI this setting to configure the client utility cache to be at least 300BM will likely be a prereq to running the Logpresso scan using the JAR and temporary downloaded JRE on all platforms in the future. It also just a best practice in general to set all clients to have this setting.
See this task to do so:
Hi all, I made progress, been not working since Friday so this is first day I’m working on this… on my annual leave… worked out plan of attack yesterday and this afternoon coded up the relevance for the action for the currently all JAVA version of Logpresso.
Here is link to current progress: https://bigfix.me/fixlet/details/26903
This is very much in development still so its not production ready but its testing fine so far on what I have tested both Windows and Linux
Notes/brain dump since my last update
Lots more work here but its a start
If anyone is using this, I’ve added a 5 minute timeout to terminate the LSOF process.
override wait
timeout_seconds=300
disposition=terminate
wait /bin/sh -c “(lsof / | grep log4j > /var/opt/BESClient/BPS-Scans/lsof_results.txt)”