Log4j CVE-2021-44228 Detection and Mitigation

Have you encountered this problem? We are going to need to deploy a JRE and the scanner JAR file to support other operating systems, and I’d like to check whether using the JAR instead of the prebuilt binary avoids the problem.

1 Like

I am seeing this problem with a mass scan we are running this weekend. Many servers were not able to execute the scan due to the missing libs/dependencies. I don’t have exact numbers as of now, hope to run a report during the week.
image

1 Like

(This reply is specifically to @fermt, or anyone else who can reproduce the “Missing VCRUNTIME140.dll” issue; or we can adapt similar for anyone on Linux encountering a glibc version error)

If you’re willing to run a test on any of these machines, it would be very helpful to know the results. I hope we can workaround this by downloading a portable JRE, and using the JAR version of the scanner. But there’s the possibility that just pushes off the VCRUNTIME dependency to the JRE.

  1. Download a ZIP version of the portable JRE 8 from Adoptium (formerly AdopOpenJDK)
    https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u312-b07/OpenJDK8U-jdk_x86-32_windows_hotspot_8u312b07.zip

  2. Download the JAR version of Logpresso scanner (this changes frequently, version number may increment
    https://github.com/logpresso/CVE-2021-44228-Scanner/releases/download/v2.3.0/logpresso-log4j2-scan-2.3.0.jar . If the version gets updated it’s the “Universal” version circled here:

Unzip the JRE. I’m assuming here unzipping to c:\temp\JRE8 and storing the logpresso jar at c:\temp. The next command lines assume those paths.

Open an Elevated Command Prompt and use the extracted JRE to run the JAR-based scan. Here’s an example

C:\Temp>C:\Temp\jre8\OpenJDK8U-jre_x64_windows_hotspot_8u312b07\jdk8u312-b07-jre\bin\java.exe -jar "C:\Temp\logpresso-log4j2-scan-2.3.0.jar" c:\
Logpresso CVE-2021-44228 Vulnerability Scanner 2.3.0 (2021-12-19)
Scanning directory: c:\
Running scan (10s): scanned 6012 directories, 54041 files, last visit: c:\Program Files\VcXsrv\fonts\100dpi
....
1 Like

Happy Saturday morning, everyone.

There’s now a another CVE against Log4j 2.x, prompting upgrade to Log4j2-core-2.17.0.jar. This is the third CVE against Log4j2, and the fourth against Log4j in total this week (including the 1.x versions that are not expected to be fixed)

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

1 Like

Updated the Summary page at Log4j CVE-2021-44228, CVE-2021-45046 Summary Page

I received a question on how to download content from GitHub, so I wrote this Tip:

Significant update on the Analysis to retrieve results of the logpresso-log4jscan process at bigfix-content/analyses/log4j2-scan results.bes at main · jgstew/bigfix-content · GitHub

The property list is expanded to include

  • log4j Scan - Vulnerable File List
  • log4j Scan - Scan Technology
  • log4j Scan - Last Scan Time
  • log4j Scan - Vulnerable File Count
  • log4j Scan - Potentially Vulnerable File Count
  • log4j Scan - Mitigated File Count
  • log4j Scan - File Result Details
  • log4j Scan - File Scan Count
  • log4j Scan - Scan Duration

The “File Scan Count” and “Scan Duration” are useful in identifying failed scans or scans that may have included network paths - a scan with 0 files or empty result probably failed to execute, and a scan with a long duration may have crossed network paths or scanned very large filesystems.

The “Scan Technology” entry includes the Logpresso-Log4jscan version that was executed.

The “File result details” entry contains the full line from the logfile, including the version of Log4j-core that the Logpresso scanner recognized, if any.

5 Likes

Thanks for doing this Jason. I was putting it off since the scan part was in flux.

This is actually expected and listed as a dependency for the Logpresso scan utility binary for windows. We should adjust the relevance to check for this dependency for the windows binary scan task. I had not actually come across any systems that did not already have this installed in my testing on my workstations, but it makes sense that servers with very few programs installed would be more likely to be missing it.

We have confirmed this dependency does NOT exist if you run the scan using a JRE and the JAR file version of the Logpresso scan utility.

Yep, this is a bugger and why I made the java version for windows.
I actually got enough info to start on linuxnversion but not the time yet. Maybe at night time here…

2 Likes

Thanks to Jason, we now have a working version that runs using a pre-installed JRE/JDK and runs the JAR. This will also get around the dependency problem on windows, but with the dependency of having a JRE/JDK already installed somewhere we can find with relevance.

See here: https://github.com/jgstew/bigfix-content/blob/master/fixlet/Logpresso%20log4j2-scan%20-%20Universal.bes

This should resolve @fermt 's issue if the relevance does find java already installed somewhere.

We are still planning on a fixlet/task with the capability to run the JAR version of the utility by downloading a portable JRE/JDK, running the utility, then cleaning up after so the portable JRE is not left behind in a way that can be used. The main issue with this approach is it is going to require figuring out the right JRE to download for every platform and testing it. This will be nearly impossible to do without community help for platforms that we do not have test machines available for.

1 Like

Well, the Logpresso scan utility now has MacOS and Linux ARM binaries available!

… I think this means I need to hook my raspberry pi back up.

3 Likes

I have not tested it yet, but here is a scan task that uses the MacOS binary:

I also updated the Linux, Windows, and Universal ones to use the newer versions of the scan utility.

2 Likes

@fermt, I was able to reproduce this on some of my Win2019 servers. I verified that using an existing JRE on the machine to run the JAR-based scan works, so the Universal JAR scan may work better for you – if you have Java installed on the machine already.

I’ll be working today on versions that download a portable JRE to run the JAR scans on systems without JREs. I’m going to be starting with Windows and Linux, intending to follow-up with Mac, AIX, etc. after.

1 Like

I’m going to test this tomorrow when I get access to the environments.

Thanks again for all your help.

1 Like

I deployed the mac scan task to 5 macs. The task is completed, it’s been about about 2 hours and I have not seen any results in the analyses.

The Analysis properties are set to only evaluate every 6 hours…can you ‘Send Refresh’ to one of the computers to see if it helps?

Was the scan log generated under the /var/opt/BESClient/BPS-Scans directory?

1 Like

it is possible it didn’t work, especially if the results file didn’t get created.

I was testing the mac binary as well. Everytime I invoke it using local terminal (not through BigFix), I’m getting text results generated. Every time I send through Bigfix, I can see in client logs the command is executed successfully, but no text is written to the results file.

1 Like

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.

2 Likes