Log4j CVE-2021-44228 Detection and Mitigation

[fermt]

Yes, I saw that as an option… The problem is that we don’t have the list of pathnames, they are mounted with different name variations and we have hundreds of clients doing that

[JasonWalker]

Poll on Mitigation

As we are waiting for vendors to update their individual applications, the cyber community has coalesced on a couple of techniques that may mitigate the problem. Both of these involve modifying the Log4J JAR file. Both of these could have unintended consequences on the products using Log4J and thus come with an element of risk.

Method 1 would be to replace the JAR file entirely, with the latest log4j-2.16.0.jar. To avoid updating whatever application was using log4j, we would need for the new version of the file to retain the old version’s name. Something like
cp -y log4j-core-2.16.0.jar /opt/whatever-program/lib/log4j-2.14.0.jar

In this method, it would be much easier to track which JAR files have already been updated, because there is a single known hash for log4j-core-2.16.0.jar that all of the log4j-core should match once they are replaced.

Method 2, is to unpack the log4j-core-X.X.X.jar file and remove the affected library from the ClassPath via a command such as
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Windows lacks a zip command-line utility on Windows (we could download 7-zip to do this though), but the real complexity comes in knowing which files we have already fixed. Depending on the distribution, version of zip, etc., we could end up with an unknown number of resulting hash versions, so we would need some kind of log/tracking mechanism to know which ones have been fixed already.

So, I wanted to poll the community on which, if either, mitigation you’d like to see us pursue.

• Unpack the JAR and remove the Class
• Replace the JAR with 2.16.0
• Neither; I can only rely on official updates from the affected vendors.

Show results

(Edit: re-ordered the descriptions to match the order of the poll questions)

[fermt]

Apache noted this:

https://logging.apache.org/log4j/2.x/security.html

[Mario]

I have been working on something, will report tomorrow as going bed finally. Needs testing

[nicksberger]

Anyone found a way to determine whether the jar file is running the JndiLookup.class without having to run a script ?

Looking at command line arguments or a java process or similar ??

Need an output similar to what this command will show but using native relevance

Run below command to check whether it lists any jar files which contains vulnerable class.
find / -type f -name “*.jar” -exec sh -c “zipinfo -1 {} | grep JndiLookup.class && echo {}” ;

[jgstew]

#!/bin/bash

echo ‘export LOG4J_FORMAT_MSG_NO_LOOKUPS=true’ >> ~/.bashrc

This won’t work. This is a per-user location, not system wide.

Copy the file CVE-2021-44228.txt task results from the BES folder to another location on the hard drive
Edit the file to append in front and after the path\exe so that it creates a command such as this for each line that is not SCAN_COMPLETE:

“C:\Program Files\7-Zip\7z.exe” d -tzip “C:\Program Files\Code42\lib\log4j-core-2.13.3.jar” org/apache/logging/log4j/core/lookup/JndiLookup.class
rename as batch
execute

You don’t need to make a copy of the original txt file to do this, you can just use relevance to build the BAT file within a “create file” command.

Has anyone faced a problem when there is a CIFS share mounted?

@JasonWalker 's version skips nfs shares but we are observing high resource usage when the servers have other type of share disks with millions of files.

That is definitely not intended. You want to exclude all network shares from scanning ideally.

Method 1, is to unpack the log4j-core-X.X.X.jar file and remove the affected library from the ClassPath via a command such as

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

If someone does actually want to go down this path, then it seems like this is the best way to do it on Windows/Linux: https://github.com/logpresso/CVE-2021-44228-Scanner (from @Mario 's link above)

Method 2 would be to replace the JAR file entirely, with the latest log4j-2.16.0.jar. To avoid updating whatever application was using log4j, we would need for the new version of the file to retain the old version’s name. Something like

cp -y log4j-core-2.16.0.jar /opt/whatever-program/lib/log4j-2.14.0.jar

This is my preference, especially because we might not be done with Log4J CVEs and we might have to do this all over again with log4j-core-2.17.0.jar or similar in the future. I feel like if you already going to mess with things in weird ways, then “patching” it forward is better than removing things.

That said, using the environment variable, the logpresso scan and fix utility, and the replacing of the JAR files could all be done together. You don’t technically have to pick and choose which you do.

That said, the fix of removing the class file that the logpresso scan and fix utility does is not reversible as easily as renaming the affected JAR to something like JAR.20211215.backup and placing the new JAR in it’s place. I like the idea that just swapping out the JAR file for the fixed version is a much more easily reversible operation for either the application owner or for a bigfix operator.

The if { unix of operating system } section is Linux (and bash/ksh) specific, and won’t work on all platforms (e.g. AIX and Solaris). Better would be to set the variable, then export it as a separate command. The /etc/profile file is the only file which is guaranteed to be read across OSes, as /etc/profile.d is Linux specific.

The newest version of the script on github actually accounts for this now.

Finally, /etc/profile (and /etc/profile.d) only works for interactive shells, and most programs will run as system services. The approach for setting global environment variables is highly platform dependent on Unix, and even varies across Linux variants. The most portable approach is probably /etc/environment

Oh damn, I definitely want this to be for everything, not interactive shells which are actually much less likely to be an issue. Things running as services are the most likely to be a problem. This is what I was worried about. It does seem like /etc/environment would be the right place if it exists and is used on the platform, but then annoying that other platforms have other locations.

If someone has example commands to address this for different OSes as far as setting env vars for system services, that would be extremely helpful.

CC: @QvR

[JasonWalker]

No, there is no native relevance to extract a zip file and look inside the contents. That will require an Action.

[nicksberger]

More interested in the reporting. Based on the results from the scan you posted and the results file. Do you have a quick way to develop the action required to pipe the results of the lookup class to file ?

[jgstew]

Do you have a quick way to develop the action required to pipe the results of the lookup class to file ?

Can you be more specific? Not sure what an example input and desired output looks like, or which thing you are looking at.

Based on the results from the scan you posted and the results file.

Do you mean Jason Walker’s scan results using DIR/Find? or do you mean using the logpresso utility?

[FatScottishGuy]

Some other feedback internally

I notice that in the scan, we are just looking at log4j-core*.jar files. I’m seeing that since the jndi class can be baked into any jar file or even jar files inside of jar files, is there a plan to expand this fixlet to do a deeper dive on all of the jar files on a system?

The scanners I have seen look to open up the jar files recursively, hash all the files inside, and match against the hashes of known vulnerable files.

[jgstew]

The scanners I have seen look to open up the jar files recursively, hash all the files inside, and match against the hashes of known vulnerable files.

This is a gap most likely to be filled by something like the logpresso scan utility or similar. The pure DIR/FIND stuff won’t really do for that.

[JasonWalker]

Trying to walk before I run.
I do have plans to eventually check inside WAR files for log4j-core, but I don’t think it’s safe to remove the JNDI class entirely from every JAR file. JNDI has valid uses, that just don’t include parsing user-provided strings the way Log4J is doing it.

[nicksberger]

Jasons script was great, but the lookup.class is just as importatnt as the vulnerable pathanmes/mitigation steps.
Looking at logpresso, that appears to do everything we need. Has anyone created a fixlet for this utility ?

[jgstew]

Has anyone created a fixlet for this utility ?

I only just now found out about it, but it seems to do everything needed if you are okay with the remove class approach. I can look at making one and output the results to a file in a similar location as Jason’s scan log.

[nicksberger]

That would be great, BigFix is getting huge kudos right now on this. Time is of the essence.
Is there a way to not fix, just report ??

[nicksberger]

I think if you exclude the following flags from the command line, it will report only

–fix
Backup original file and remove JndiLookup.class from JAR recursively.
–force-fix
Do not prompt confirmation. Don’t use this option unless you know what you are doing.

[jgstew]

Is there a way to not fix, just report ??

You can do both with the utility, makes sense to have report only be the default.

[whbennethum]

Method 2 similar to? https://gist.github.com/neoKushan/e156810fc91765aa84857314b92bb22d

[JasonWalker]

Yes, similar to that. I was considering downloading 7zip to do it though, since some platforms may lack PowerShell and the Archive support can vary by PowerShell version.

[jgstew]

Method 2 similar to?

The logpresso utility handles this case and more.