How to find vulnerable log4j programs (CVE-2021-44228) on a Windows 10 PC and how to provide first-a-CodePudding

How to find vulnerable log4j programs (CVE-2021-44228) on a Windows 10 PC and how to provide first-aid when I cannot update to a fixed log4j version?

CodePudding user response：

It is possible to delete JndiLookup class from log4j-core jar files in order to provide first aid in the context of the log4j security desaster (CVE-2021-44228). Delete the JndiLookup classes, if you cannot update the Java application to a version with fixed log4j version, as it is suggested by log4j themselves.

So this is just a first-aid quick fix until you get application updates! The Following PowerShell script will search all drives for log4j-core*.jar files. In any found one, we will delete the JndiLookup class from it, with "zip -q -d" command.

On Windows 10 PCs, there is PowerShell for scripting. Thus, create an anyname.ps1 file with the following content:

# Ensure we can run everything
Set-ExecutionPolicy Bypass -Scope Process -Force

# Escape characters in PowerShell: https://ss64.com/ps/syntax-esc.html

Write-Host "Start iterating drives..."
$volumes = Get-WmiObject win32_volume -filter "drivetype=3"
foreach ($volume in $volumes)
{
    $driveletter = $volume.driveletter # e.g. C:
    if ($driveletter -ne $null)
    {
        $drivename   = $volume.name        # e.g. C:\
        
        Write-Host "`n== Checking $driveletter... =="
 
        # Find log4j-core*.jar files, directly
        # and remove org/apache/logging/log4j/core/lookup/JndiLookup.class 
        # with zip.exe -q -d command.
        # Use unzip -l | findstr JndiLookup as paranoia check.
        Write-Host "== Find log4j-core*.jar files... =="
            Get-ChildItem -Path $drivename -Filter log4j-core*.jar -Recurse -ErrorAction SilentlyContinue | % {
            Write-Host "== $($_.FullName) =="
            
            Write-Host "> zip.exe -q -d `"$($_.FullName)`" `"org/apache/logging/log4j/core/lookup/JndiLookup.class`""
            zip.exe -q -d "$($_.FullName)" "org/apache/logging/log4j/core/lookup/JndiLookup.class"
            
            Write-Host "> unzip.exe -l `"$($_.FullName)`" | findstr JndiLookup"
            unzip.exe -l "$($_.FullName)" | findstr JndiLookup
            
            Write-Host "== END =="
        }
        
        # Find JndiLookup.class in uncompressed directories on the file-system (aka *.class)
        Write-Host "== Find uncompressed JndiLookup.class files... =="
        Get-ChildItem -Path $drivename -Filter JndiLookup.class -Recurse -ErrorAction SilentlyContinue | % {
            Write-Host "== $($_.FullName) =="
            
            Write-Host "> Remove-Item -Path `"$($_.FullName)`" -Force"
            Remove-Item -Path $_.FullName -Force
            
            Write-Host "== END =="
        }
    }
}

# Find embedded log4j-core*.jar files ("Java Über JARs" or shaded JARs, i.e., JARs in other JAR/WAR/etc.)
Write-Host "== Find log4j-core*.jar files that are embedded into other archives... =="
Write-Host "TODO: Not supported!"
Write-Host "INSTEAD APPLY: https://github.com/mergebase/log4j-detector"

# Find log4j in docker containers
Write-Host "== Find log4j in docker containers... =="
Write-Host "TODO: Not supported!"
Write-Host "READ: https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/"
Write-Host "THUS, APPLY: docker scan"

Write-Host "Press ENTER to continue..."
cmd /c Pause | Out-Null

Now you can execute this ps1 file.

Easy way to execute the ps1 file: create an anyname.cmd file besides the identically named ps1 file with the following content:

powershell.exe -ExecutionPolicy ByPass -noprofile -command "&{start-process powershell -ArgumentList '-ExecutionPolicy ByPass -noprofile -NoExit -file \"%~dpn0.ps1\"' -verb RunAs}"

You can double-click the cmd. It will execute the ps1 script with elevated privileges.

Kind regards!

Update: There have now been several attempted fixes by log4j (versions 2.15, 2.16 and now 2.17). Possibly, the "first-aid" removal of JndiLookup class (from any log4j JARs, possibly embedded, i.e., "Java Über JARs" or shaded JARs, or in uncompressed directories on the file-system, aka *.class) should actually be your preferred present and future option.

CodePudding user response：

UPDATE: 2021-12-18...

Remember to always check for the latest information from the resources listed below

CVE-2021-45105... 2.16.0 and 2.12.2 are no longer valid remediations! The current fixing versions are 2.17.0 (Java 8) and 2.12.3 (Java 7). All other Java versions have to take the stop gap approach (removing/deleting JndiLookup.class file from the log4j-core JAR.
I have updated my message below accordingly.

Answering the question directly:
I know you asked specifically about what to do if you can't upgrade... I will answer that question at the bottom. However, I am including the other information as well for anyone else that stumbles across this.

For detection: See CyberPetaNeuron's other answer

For remediation: keep reading

More resources
- https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
  - This one has TONS of useful info including detectors, even more resource links, very easy to understand remediation steps, and more
- https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
- https://github.com/cisagov/log4j-affected-db
- https://logging.apache.org/log4j/2.x/security.html

Remediation:
CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
While most people that need to know probably already know enough to do what they need to do, I thought I would still put this just in case...

Follow the guidance in those resources... it may change, but

As of 2021-12-18

It's basically

Remove log4j-core JAR files if possible
- From both running machines for immediate fix AND
- in your source code / source code management files to prevent future builds / releases / deployments from overwriting the change
If that is not possible (due to a dependency), upgrade them
- If you are running Java 8, then you can upgrade to log4j 2.17.0
- If you are running Java 7, then you can upgrade to log4j 2.12.3
- If you are running an older version of Java, then you need to upgrade to the newest version of Java and then use the newest version of Log4J
- Again, these changes have to happen both on running machine and in code
If neither of those are possible for some reason... then there is the NON-remediation stop gap of removing the JndiLookup.class file from the log4j-core JARs.
- There is a one-liner for the stop gap option on Linux using the zip command that comes packaged with most Linux distros by default.
  - zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
- At time of writing, most of the guides online for the stop gap option on Windows say to do the following (again... assuming you can't do one of the remove JAR or upgrade options above):
  - Install something like 7-zip
  - Locate all of your log4j-core JAR files and for each one do the following...
  - Rename the JAR to change the extension to .zip
  - Use 7-zip to unzip the JAR (which now has a .zip extension)
  - Locate and remove the JndiLookup.class file from the unzipped folder
    - The path is \\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
  - Delete the old JAR file (which now has an extension of .zip)
  - Use 7-zip to RE-zip the folder
  - Rename the new .zip folder to change the extension to .jar
- There are also some options to use Power Shell
  - Reddit thread: log4j_0day_being_exploited
  - ctrl f for "PowerShell"

This is fine if you only have 1 or 2 JAR files to deal with and you don't mind installing 7-zip or you have PowerShell available to do it. However, if you have lots of JAR files, or if you don't want to install 7-zip and don't have access to Power Shell, I created an open-source VBS script that will do it for you without needing to install any additional software. https://github.com/CrazyKidJack/Windowslog4jClassRemover

Read the README and the Release Notes https://github.com/CrazyKidJack/Windowslog4jClassRemover/releases/latest

CodePudding user response：

I provided the first-aid PowerShell script in the other answer, however, meanwhile there are several advanced tools that allow detection and patching of log4j-based applications, in context of CVE-2021-44228, for the case that you cannot upgrade the application and its bundled log4j, yet.

https://github.com/mergebase/log4j-detector

log4j-detector is a Java-based tool that searches for vulnerable log4j instances. It detects log4j in "Java Über JARs" as well as other JARs/WARs, in uncompressed directories on the file-system (aka *.class) and in shaded jars. It provides information about the found log4j versions. (It does not provide a patcher to fix the findings.) But this one seems to be most thorough in its detection.

https://github.com/hillu/local-log4j-vuln-scanner

log4j-vuln-scanner is a Go-based tool, with binary releases for x86_64 Windows, Linux, MacOSX, that searches for vulnerable log4j instances. It finds log4j also within other JAR and WAR files and it provides information about the found log4j versions. (It seems not as thorough as the log4j-detector above.) But this one provides a patcher to fix the findings.

https://github.com/logpresso/CVE-2021-44228-Scanner (=log4j2-scan)

log4j2-scan is available for Windows, Linux and MacOS. The depth of search is not as clearly specified as with the others. However, it also provides means to fix its findings.

https://github.com/Neo23x0/log4shell-detector

log4shell-detector is a python-based tool that searches for log files and, from the logs strings, tries to detect any exploitation attempts.

Related Issue: How to find log4j instances in Docker containers? Use docker scan! But please, read https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/ for further instructions.