Log4j CVE-2021-44228 Detection and Mitigation

Mario 2021-12-17 23:18:50 UTC #325

Unfortunately, due to the nature of the vulnerability, this problem will not ever blow over as long as java is in existence. The possibility of people inadvertently installing or updating or restoring from backup is immense. This could bring you back to square one and you would pay a heavy price if it’s simply ignored.

I recommend scan tasks to run forever into the future and change processes changed to include a section about Log4j going into the future, as part of any change that involves touching software.

Log4j is just ingrained into so many applications that most people are not even aware of its existence. It’s impossible to know it even exists unless scans were run in most cases.

There is no logpresso solution without java at this stage for Mac.
The pre compiled versions are very limited in terms of OS support but the java should work with a great many OS versions.
This is what I guess the community here is trying to accomplish now

jgstew 2021-12-17 23:28:37 UTC #326

Probably only needs to be like once a week or something like that in the future, but you are right, you have to double check and make sure things don’t pop back up. That said, if they do, it might be because the fix broke the app, so you have to be careful if you are refixing and rebreaking the same app over and over.

arnars 2021-12-18 02:58:41 UTC #327

Hey thanks. This really helped out. I was definitely not using /bin/sh -c ! But so I had issues with it outputting it to results.txt… did some digging around and finally got it to work like this:

run /bin/bash -c “cd /tmp && java -jar logpresso-log4j2-scan-2.1.3.jar --no-symlink --no-empty-report / > ‘{parameter “ListFile”}’ 2>&1”

jgstew 2021-12-18 03:40:14 UTC #328

That command looks good. For some reason I don’t understand the outer quotes have to be double quotes for commands run with bigfix even though bash works either way.

It won’t redirect to a file without invoking it with a shell generally. A lot of things you take for granted are actually provided by the shell, not the OS, but it is hard to tell which is which when You are already starting in the shell in the terminal.

Another example is finding an executable on the PATH. That is usually done by the shell.

When you run installler or msiexec without the shell, it works but is actually more efficient in terms of processes, threads, and memory. This is why bigfix doesn’t always invoke using a shell every time.

fermt 2021-12-18 17:37:44 UTC #329

Is anyone adding a check for the pre-requisites to run the native executables?

If you get VCRUNTIME140.dll not found error, install Visual C++ Redistributable.

`GLIBC_2.14' not found (required by ./log4j2-scan)

JasonWalker 2021-12-18 18:24:20 UTC #330

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.

fermt 2021-12-18 18:27:30 UTC #331

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.

JasonWalker 2021-12-18 18:45:39 UTC #332

(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.

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
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
....

JasonWalker 2021-12-18 18:49:22 UTC #333

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

JasonWalker 2021-12-18 18:58:44 UTC #334

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

JasonWalker 2021-12-18 19:25:31 UTC #335

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

JasonWalker 2021-12-19 00:56:28 UTC #337

Significant update on the Analysis to retrieve results of the logpresso-log4jscan process at https://github.com/jgstew/bigfix-content/blob/master/analyses/log4j2-scan%20results.bes

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.

jgstew 2021-12-19 05:00:15 UTC #338

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.

Mario 2021-12-19 05:09:16 UTC #339

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…

jgstew 2021-12-19 05:56:10 UTC #340

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.

jgstew 2021-12-19 06:01:48 UTC #341

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.

jgstew 2021-12-19 15:57:33 UTC #342

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

https://github.com/jgstew/bigfix-content/blob/master/fixlet/Logpresso%20log4j2-scan%20-%20MacOS%20x64.bes

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

JasonWalker 2021-12-19 17:18:44 UTC #343

@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.

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

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.

fermt 2021-12-19 19:45:16 UTC #344

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

Thanks again for all your help.

sbl 2021-12-19 20:50:22 UTC #345

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.