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.
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.
2 Likes
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 ?
1 Like
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.
1 Like
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 ??
1 Like
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.
1 Like
You can do both with the utility, makes sense to have report only be the default.
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.
1 Like
The logpresso utility handles this case and more.
1 Like
report on class, with the option to fix
1 Like
A fixlet using logpresso would be a big help.
2 Likes
What I read yesterday is that Apache is removing the JNDI class altogether in Version 16. That is why I thought it would be safer to remove the class from the core files detected, because the filename will stay the same and other than missing the jndi class all other components would be the expected version of the application using it. I know it’s a risk, and make break functionality, but I am only concerned about workstations at this moment, and I’m trying to reduce the risk to our company. I renamed the class in a jar file yesterday so that I could test the zip command. Of course it didn’t work, but it did with 7z, which we have on all of our workstations. Once edited, the core file has a new current date. I am just not good at writing complex dos commands that would tack the required stings in front and after each line of the resulting path lines of your search task.
1 Like
Can you provide an example few lines from the results from the search task? I don’t have one handy at the moment.
Also, the logpresso thing I’m working on will do this and more.
If anyone has example command line options for running the logpresso utility that would be cool. I’m working on the action side of things right now.
BFI team has produced custom Signatures, hosted at BigFix.me.
See updated links at Log4j CVE-2021-44228, CVE-2021-45046 Summary Page
2 Likes
I cannot stress enough how un-tested this is. But I’ve made a Task (on Windows) that will parse the earlier scan results, find log4j-core-2.x.jar files that are not 2.16.0, and replace those files.
The original file is backed up to log4j-core-2.x.jar-disabled, and the new version keeps the old version’s filename. That is an attempt to let the new version work with older configuration files.
I’m ready for a few brave souls to try it out. No warranty, at your own risk, etc.
2 Likes
for windows (this is just me testing), this gives me what i need
log4j2-scan.exe --drives c > “C:\temp\Logpresso\output.txt”
analysis would be something like this (obviously cleaned up)
//Vulnerable files
q: preceding texts of firsts “,” of following texts of firsts "vulnerability in " of lines of file “Output.txt” of folder "C:\Temp\Logpresso"
A: C:\Temp\cis-cat-full-2019\ciscat-full-bundle-2019-01-17-v3.0.55\cis-cat-full\lib\log4j-core-2.3.jar
A: C:\Temp\cylance\cis-cat-full-2019\ciscat-full-bundle-2019-01-17-v3.0.55\cis-cat-full\lib\log4j-core-2.3.jar
T: 3.995 ms
//Mitigated files
q: preceding texts of firsts “,” of following texts of firsts “vulnerability in " of lines whose (it as lowercase contains " (mitigated)” as lowercase) of file “Output.txt” of folder "C:\Temp\Logpresso"
A: C:\Temp\cis-cat-full-2019\ciscat-full-bundle-2019-01-17-v3.0.55\cis-cat-full\lib\log4j-core-2.3.jar
A: C:\Temp\cylance\cis-cat-full-2019\ciscat-full-bundle-2019-01-17-v3.0.55\cis-cat-full\lib\log4j-core-2.3.jar
T: 1.287 ms
1 Like
C:\Program Files\Code42\lib\log4j-core-2.13.3.jar
C:\sqldeveloper\sqldeveloper\lib\log4j-core.jar
C:\Users%username%\Downloads\sqldeveloper-19.2.1.247.2212-x64\sqldeveloper\sqldeveloper\lib\log4j-core.jar
SCAN_COMPLETE
1 Like
I changed the username to var; that’s not the way it writes to the CVE-2021-44228.txt file.
1 Like
Man meets machine ! You are awesome! I have plenty of test targets. Going to try this out now
1 Like