I’m still working on testing it, but I don’t have a mac handy in my lab environment at the moment.
The main thing to try is to invoke the same command in the bigfix client log on the terminal and see if it works that way or not.
I would guess I have something wrong and it will never work until I fix it, but I don’t know what that is yet.
I can confirm the jar based scan works when the Visual C++ library is not installed.
We figured out part of the issue with the Mac scan tasks and should have it working some time Monday.
The issue was that the relevance used to build the exception list works on Linux/Unix but not MacOS due to differences in inspectors.
We are also wondering, should the scan check inside any mounted DMGs? I would assume not, but currently it does because they appear as “Fixed Disks”
I could see it being valuable to scan inside dmg. Not sure if logpresso binary would otherwise be able to look inside of them if they weren’t mounted. Not going to catch them all, but better than skipping them. It might be helpful to identify dmgs that have the vulnerability - stop using them or at least identify them. I suppose some companies might have some kind of network share and maybe people are mounting the dmg from there? That’s not common at our company.
@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”)