Log4j CVE-2021-44228 Detection and Mitigation

I’m trying to help integrate our file scan results (logpresso) with another system via REST API. Here is the query I’ve built, but I can’t get any results to appear for “log4j Scan - File Result Details”.

https://<server_and_port>/api/query?relevance=(name of it | “not found”,value of result from (bes property “log4j Scan - Last Scan Time”) of it as universal time as universal string | “not found”, (concatenation “|” of (ip addresses of it as string)) | “not found”, last report time of it as string | “not found”, concatenation “|” of values of results from (bes property “log4j Scan - File Result Details”) of it | “not found”) of bes computers whose(name of it=“C02C20E6MD6V”)

I choose a specific computer name where I know there are two file results. “log4j Scan - Last Scan Time” is showing results.

Is there something about the type of the result that is preventing showing results?

There’s nothing intrinsically “special” about these properties. I’d start by querying for only one property at a time to see which, if any, are breaking the query.
Are you getting an error response, or just an empty result?
One consideration, since we have both the “Community” version (from GitHub) and the “Offical” version (in the “BES Inventory and License” Site), we could have duplicate property names if you’ve imported the GitHub version. A definition like (bes property “log4j Scan - Last Scan Time”) could be ambiguous.

One “interesting quirk” about the creation class bes property <string> is that you will get a property but not necessarily the right one. Looking at my console where I have three copies of this property, a query like

(names of it, names of sites of source analyses of it) of bes property "log4j Scan - Last Scan Time"

yields

log4j Scan - Last Scan Time, BES Inventory and License Test

…I know there are three different copies of this property on mine, but bes property "X" only gives me one of them, and I can’t control which one it gives.

I can get all of them via

(names of it, names of sites of source analyses of it) of bes properties whose (name of it = "log4j Scan - Last Scan Time")

log4j Scan - Last Scan Time, BES Inventory and License
log4j Scan - Last Scan Time, BES Inventory and License Test
log4j Scan - Last Scan Time, Test

You might need to change your lookup pattern to something like

( concatenation "|" of values of results from (bes properties whose (name of site of source analysis of it = "BES Inventory and License" and name of it = "log4j Scan - Last Scan Time")) of it | "not found") of bes computers

2 Likes

Did anyone faced issue with huge memory consumption with log4j scanning, we have some input from other teams where it block 5GB of memory while scanning the system.

This process was running on those machines.

C:\Windows\Temp\log4j2-scan.exe

I haven’t seen other reports of such yet. Were you using one of the Fixlets (we haven’t updated the .EXE version in quite some time, focusing instead on the .JAR versions of the scanner)?

I wonder whether it was scanning a very large archive or something like that?

I’d first ensure you’re using the latest version, and the run with the --trace parameter.

We’re seeting Tenable/Nessus log4j plugins consume mass quantities of CPU and RAM. There’s at least one WMI query that uses a lot of CPU, and a PowerShell using up to ~3.5GB of RAM. Turning the agent’s performance settings to “low” doesn’t seem to have an impact on these subprocesses.

The BigFix team has published an update to the “BES Inventory and License” Site, enabling updated Scans, Mitigation, and Mitigation Rollback using the 2.7.1 version of Logpresso Scanner

1 Like

The Logpresso Scanner with version 2.5.3 works for RHEL 6, but with version 2.7.1 doesn’t work.

JUMP log4j-tools]$ ./log4j2-scan-2.7.1-logpresso
./log4j2-scan-2.7.1-logpresso: /lib64/libc.so.6: version GLIBC_2.15' not found (required by ./log42-scan-2.7.1-logpresso) ./log4j2-scan-2.7.1-logpresso: /lib64/libc.so.6: versionGLIBC_2.14’ not found (required by ./log42-scan-2.7.1-logpresso)

Our content should be using the Java version of the scanner, mostly to get around glibc and c++ dependencies

Hi Jason, from my experience the Java at least from several places I found had glibc version requirements itself

Understood. The version of Adoptium JDK that we use to run the scan does require glibc 2.12 or higher, a less strict requirement than the Logpresso prebuilt binaries.
That’s not a limitation we can work around, if you have trouble with the Logpresso prebuilt binary you’ll need to switch to the Java version (as used in our content) or install the requisite glibc versions.

Yep, it’s much better than the pre-built binaries indeeed.
Definitely easier to switch to java based version

Running Logpress 2.7.2 on Linux using the correct switches to exclude NFS but ts not working as expected.
Anyone else using the tool and successfully excluding NFS ?
We are experiencing performance issues on the filers caused by open handles as a result of the scan.
Any advice ?
@jgstew

1 Like

Can you post the command-line you’re running?

How does it compare with the command line we use in our tasks?

1 Like
run /bin/sh -c "cd /tmp && ./log4j2-scan --exclude-fs {("--exclude " & it) of concatenations " --exclude " of unique values whose(it does not contain " ") of (it;"/mnt";"/dev";"/cdrom") of items 0 of (mount points of it, filesystem types of it, types of it) whose(item 2 of it != "DRIVE_FIXED" OR item 1 of it is contained by set of ("cgroup";"cifs";"nfs";"cgroup2";"sysfs";"proc";"cpuset")) of filesystems} / > {parameter "ListFile"}"

also noticing that the relevance for detecting the process is not working as expected, tried with exists running application “log4j2-scan” and exists process “log4j2-scan”

Something to note is if you use the ‘–exclude-fs’ parameter, that overwrites all the default filesystem exclusions so you need to exclude every type of filesystem you want to skip, not just add more to be excluded.
You may also have cases where a symlink to a remote filesystem is being scanned, even if the actual mountpoint for the filesystem is not, so be sure to include --no-symlink as well to skip those.

An example of the full command line we’re using in our content would be

java -jar ./logpresso-log4j2-scan.jar --silent --scan-log4j1 --no-symlink --no-empty-report --exclude-fs nfs,nfs3,nfs4,cifs,tmpfs,devtmpfs,iso9660,autofs,afs --exclude-config '/path/to/exclusions.txt' --report-json --report-path '/var/opt/BESClient/BPS-Scans/report-output.json

1 Like

I’m afraid you’re asking us to comment on relevance that we don’t have - this is some custom relevance you built, right? What OS are you running this on?
On Mac machine, there is no process “name” creation class, I’m afraid, I’ve run into that problem myself. On Mac you’d have to use something like
not exists processes whose (name of it = "log4j2-scan")

so …

run /bin/sh -c "cd /tmp && ./log4j2-scan --no-symlink --exclude-fs nfs,nfs3,nfs4,cifs,tmpfs,devtmpfs,iso9660,autofs,afs {("--exclude " & it) of concatenations " --exclude " of unique values whose(it does not contain " ") of (it;"/mnt";"/dev";"/cdrom") of items 0 of (mount points of it, filesystem types of it, types of it) whose(item 2 of it != "DRIVE_FIXED" OR item 1 of it is contained by set of ("cgroup";"cifs";"nfs";"cgroup2";"sysfs";"proc";"cpuset")) of filesystems} / > {parameter "ListFile"}"

Yes - I think so, but run the exclude piece through the fixlet debugger or qna to see if it’s actually building the exclude list that you expect. It should result in something like the string

--exclude /mnt --exclude /dev --exclude /cdrom

and have --exclude parameters for any of your nfs / cifs filesystems.
If your filer mounts don’t appear as NFS links, or maybe if their mounts are triggered by automount, there may be more work for you to do on the exclusions or with the --exclude-fs line. Getting the filesystem types would help, if you can run the ‘mount’ command on one of these clients to show what kind of filesystems they are.

2 Likes

Works as expected now, as always thanks for your help.

2 Likes