Log4j CVE-2021-44228 Detection and Mitigation

[nicksberger]

add this to the command line --fix --force-fix

[SSenowech]

I grabbed the logpresso fixlet and analysis from the github site. Is that the correct place to pull from?

I have both BES files from github imported and tried testing against one endpoint. The scan worked – created a file on the endpoint listing the copies of the file and each shows as having been mitigated. The analysis for the same box displays .

[jgstew]

@SSenowech

I grabbed the logpresso fixlet and analysis from the github site. Is that the correct place to pull from?

yes, github is the place.

I just released an updated version of the scanner for both Linux and Windows. Same links as before:

• bigfix-content/fixlet/Logpresso log4j2-scan - Windows x64.bes at main · jgstew/bigfix-content · GitHub
• bigfix-content/fixlet/Logpresso log4j2-scan - Linux x64.bes at main · jgstew/bigfix-content · GitHub

[atlauren]

It looks like logpresso only outputs if vulnerable versions are found. Correct?

[JasonWalker]

I’ve updated the shell-script based analysis results, see summary at Log4j CVE-2021-44228, CVE-2021-45046 Summary Page

• Added hashes for versions 2.12.2 and 2.16.0
• Add 2.15.0 as “Potentially Vulnerable”.
• Exclude 2.12.2 as “Potentially Vulnerable”.

Again, with the forward work focusing on Logpresso, this scan method and analysis result are mostly deprecated but may still be useful so I have not removed them.

[JasonWalker]

@atlauren

It looks like logpresso only outputs if vulnerable versions are found. Correct?

I think you may have a problem launching the scan. I’d still expect an output to be created.

Logpresso CVE-2021-44228 Vulnerability Scanner 1.7.0 (2021-12-17)
Scanning directory: / (without /cdrom, /dev, /mnt, /proc, /sys, /sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu,cpuacct, /sys/fs/cgroup/cpuset, /sys/fs/cgroup/devices, /sys/fs/cgroup/freezer, /sys/fs/cgroup/hugetlb, /sys/fs/cgroup/memory, /sys/fs/cgroup/net_cls,net_prio, /sys/fs/cgroup/perf_event, /sys/fs/cgroup/pids, /sys/fs/cgroup/systemd, /tmp, /dev, /dev/shm, /run, /sys/fs/cgroup, /run/user/1000, /media/cdrom)
Skipping broken jar file /home/jason/log4j-core-2.13.0.jar ('zip file is empty')

Scanned 13992 directories and 161362 files
Found 0 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files

[atlauren]

This output is for a file that is supposed to be 2.16.0:

>log4j2-scan.exe c:\REDACTED\sqldeveloper-21.4.1.349.1822-x64\sqldeveloper\lib\log4j-core.jar
Logpresso CVE-2021-44228 Vulnerability Scanner 1.7.0 (2021-12-17)
Scanning directory: c:\REDACTED\sqldeveloper-21.4.1.349.1822-x64\sqldeveloper\lib\log4j-core.jar

Scanned 0 directories and 1 files
Found 0 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 0.02 seconds

[JasonWalker]

Ok with a non-vulnerable version I think that’s the expected output.
You might try adding the --trace parameter if you’d like to test that it really is examining the file, or scan a vulnerable version alongside it, but that output looks good to me.

[JasonWalker]

(and, I gotta say I hope I never have to deal with the vendor stripping the version numbers off of the filename)

[JasonWalker]

Third CVE
https://nvd.nist.gov/vuln/detail/CVE-2021-4104

This one affects Log4j 1.x in specific non-default configurations. We are aware of this. Current guidance is to upgrade to 2.16.0, I’m not expecting workarounds in the end-of-life 1.x versions.

[sbl]

Jason, Was the entry for 2.16 added as a match that means you are on the latest version whereas the all 2.15 entries and below mean - vulnerable?

[JasonWalker]

Yes that’s right.

Also 2.12.2 is also considered “fixed”, where 2.12.2 supports JRE 7 while 2.16.0 requires JRE 8 or higher. Both are accounted for in the Analysis.

[sbl]

Thanks for the clarification. One other thing we noticed was a “not matched” verdict for 2.15 as follows:

C:\Program Files\Code42\lib\log4j-core-2.15.0.jar, 419a8512895971b7b4f4f33e620d361254e5c9552b904b0474b09ddd4a6a220b, Not Matched

It’s because the hash doesn’t match the one in the property (make sense). So I am wondering is there more than one version 2.15 out there or should we consider all other ones not matching ‘bad’?

[atlauren]

We have quite a lot of “not matched” from libraries that at are binary-bundled with vendor apps.

[drothert]

Not sure if this was previously mentioned but the BFI 10.0.7 has the remediation for CVE-2021-44228: BigFix Inventory has a remediation for Log4j Vulnerability CVE 2021-44228

In addition for detecting the Log4j vulnerability in other products the BFI development team has created a separate post for custom template signatures:

BigFix Inventory: discovery of applications that may be affected by Log4j vulnerability (CVE-2021-44228) as well as other potential vulnerabilities

How to use BigFix Inventory to discover applications that may be affected by Log4j vulnerability (CVE-2021-44228) as well as other potential vulnerabilities Java-based applications that use Log4J 2.x library version earlier than 2.15 may be affected by CVE-2021-44228. BigFix Inventory helps you to discover if the affected versions of Log4J are deployed on your environment. It also helps you to identify which applications use the affected version of Log4J. However, there are other known Log4j vu…

[jgstew]

The logpresso scan utility does seem to find vulnerable versions bundled into other JAR files, but it won’t find those that have been compiled into a binary like an EXE but that is very very hard to detect.

[sbl]

@jgstew ran the logpresso task on a few windows and linux machines as a test. On the analyses side for windows I am seeing a few error results in the analysis:

The expression could not be evaluated: File error "classFileIOError" on "C:\Program Files(x86)\BigFix Enterprise\Bes CLient\BPS-Scans\results-log4j2-scan.txt": "Windows Error 0x20%: The process cannot access the file because it is being used by another.

When I go to the system I can see the file exists.

Wondering if others are seeing this too?

[JasonWalker]

That probably indicates the scan was still running and had the file locked when the analysis was evaluated.
For a quick workaround, right-click those computers and “Send Refresh” to have them re-evaluate, or wait for the next evaluation period.
We should be able to new a new version of the Analysis out tomorrow to use ‘locked lines’ rather than ‘lines’ of file.

[sbl]

Thanks for clarification on that. I am seeing results now from my Linux systems with some unbelievable elapsed times. Which seems to be more a product of the scanner itself vs the bigfix content. But is it really that quick? Here is the output from 2 linux systems one with affected files the other without.

Server 1:
File reads:
Logpresso CVE-2021-44228 Vulnerability Scanner 1.7.0 (2021-12-17)
Scanning directory: / (without /cdrom, /dev, /mnt, /proc, /sys, /sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu,cpuacct, /sys/fs/cgroup/cpuset, /sys/fs/cgroup/devices, /sys/fs/cgroup/freezer, /sys/fs/cgroup/memory, /sys/fs/cgroup/net_cls,net_prio, /sys/fs/cgroup/perf_event, /sys/fs/cgroup/pids, /sys/fs/cgroup/rdma, /sys/fs/cgroup/systemd, /sys/fs/cgroup/unified, /dev, /run, /dev/shm, /run/lock, /sys/fs/cgroup)

Scanned 21397 directories and 175881 files
Found 0 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 1.26 seconds

Property Result = <none>

Server 2:
File Reads:
Logpresso CVE-2021-44228 Vulnerability Scanner 1.7.0 (2021-12-17)
Scanning directory: / (without /cdrom, /dev, /mnt, /proc, /sys, /sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu,cpuacct, /sys/fs/cgroup/cpuset, /sys/fs/cgroup/devices, /sys/fs/cgroup/freezer, /sys/fs/cgroup/memory, /sys/fs/cgroup/net_cls,net_prio, /sys/fs/cgroup/perf_event, /sys/fs/cgroup/pids, /sys/fs/cgroup/rdma, /sys/fs/cgroup/systemd, /sys/fs/cgroup/unified, /dev, /run, /dev/shm, /run/lock, /sys/fs/cgroup)
[] Found CVE-2021-44228 vulnerability in /usr/share/elasticsearch/lib/log4j-core-2.11.1.jar, log4j 2.11.1
[] Found CVE-2021-44228 vulnerability in /usr/share/elasticsearch/bin/elasticsearch-sql-cli-7.9.1.jar, log4j 2.11.1

    Scanned 7691 directories and 83105 files
    Found 2 vulnerable files
    Found 0 potentially vulnerable files
    Found 0 mitigated files
    Completed in 0.62 seconds

    Property Result= 
    /usr/share/elasticsearch/lib/log4j-core-2.11.1.jar, log4j 2.11.1
    /usr/share/elasticsearch/bin/elasticsearch-sql-cli-7.9.1.jar, log4j 2.11.1

[QvR]

Tested the scan on AIX and it doesn’t show any applicable machines on it. Any suggestions to modify so that a scan can be run?