Skip to main content

 

UPDATE (12/17/21) - includes new Remediation Code: On December 6, version 2.15.0 was released to address CVE-2021-44228, the now infamous 10/10 CVSS remote code execution (RCE) vulnerability in Log4Shell. Shortly after, CVE-2021-45046 was discovered in version 2.15.0, with a CVSS of 3.7. Version 2.16.0 was released on December 13 to address the new vulnerability.
However, on December 17 a researcher discovered a new bypass to allow full RCE once again, which resulted in a CVSS increase from 3.7 to 9.0. If you only upgraded to version 2.15.0, you are not protected from possible RCE, upgrade to 2.16.0 immediately. Visit the Apache website for additional information.Log4Shell is a zero-day unauthenticated Remote Code Execution (RCE) vulnerability in Log4j versions 2.0-beta9 up to 2.14.1 identified as CVE-2021-44228.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Log4Shell scores a perfect 10.0 on CVSS, the maximum possible criticality for a vulnerability. The vulnerability was demonstrated with a proof of concept exploit published to GitHub, and threat actors are already searching for the vulnerability.

Apache stated that in Log4j versions 2.14.1 and earlier, "JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI-related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.”

This exploitation allows for complete system control on target Apache systems. Apache has quickly released Log4j 2.15.0 to address the vulnerability, disabling the log messages behavior by default. You can also remediate without patching by reverting to previous versions of Log4j.

Automox customers can also use a Worklet as a temporary fix for CVE-2021-44228 until the impacted systems can be patched and fully remediated. 
 

Evaluation Code:

#!/bin/bash

#================================================================

# HEADER

#================================================================

#% SYNOPSIS

#+  This worklet is a temporary fix for CVE-2021-44228, or the

#%  Log4j vulnerability in formatMsgNoLookups.

#% DESCRIPTION

#%  This worklet is a temporary fix for CVE-2021-44228, or the

#%  Log4j vulnerability in formatMsgNoLookups.

#% USAGE

#%    ./evaluation.sh

#%

#% EXAMPLES

#%   ./evaluation.sh

#%    

#================================================================

#- IMPLEMENTATION

#-    version         WF-548-Log4j_temporary_fix (www.automox.com) 1.0

#-    author          Michael King

#-

#================================================================

#  HISTORY

#     12/10/2021 : Michael King : Script creation

#     ##/##/#### : ####: Validated and catalogued

# 

#================================================================

# END_OF_HEADER

#================================================================

exit 1

 

Remediation Code:

 

#!/bin/bash
#================================================================
# HEADER
#================================================================
#% SYNOPSIS
#+  This worklet is a temporary fix for CVE-2021-44228, or the
#%  Log4j vulnerability in formatMsgNoLookups.
#% DESCRIPTION
#%  This worklet is a temporary fix for CVE-2021-44228, or the
#%  Log4j vulnerability in formatMsgNoLookups.
#% USAGE
#%    ./remediation.sh
#%
#% EXAMPLES
#%	  ./remediation.sh
#%
#================================================================
#- IMPLEMENTATION
#-    version        WF-548-Log4j_temporary_fix (www.automox.com) 1.1
#-    author         Michael King
#-
#================================================================
#  HISTORY
#     12/10/2021 : Michael King : Script creation
#     12/17/2021 : Michael King : Validated and catalogued
#
#================================================================
# END_OF_HEADER
#================================================================
# Ideally, upgrading to a current version of log4j2 is the best
# fix for this vulnerability.  However, if that is not currently
# an option this may work as a temporary fix.  If using this
# temporary fix, please be aware of SDLC pipeline and how changes
# here may be overwritten by your existing workflow.
#################################################################
# WARNING: Setting the option below will attempt to remove
# JndiLookup.class from the log4j-core-*.jar file, which may
# break code in production.  Make sure to thoroughly evaluate
# and test this fix before attempting it.
# After the change is made a full restart of the environment is
# recommended to ensure the change is live.
# Example: in our test environment this path was
# /usr/local/apache-log4j-2.15.0-bin
#
log4jpath=/usr/local/apache-log4j-2.15.0-bin
if j -n "$log4jpath" ]; then
    if zip -q -d "$log4jpath"/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class &> /dev/null; then
        echo "Successfully removed JndiLookup.class.  " 2>&1
    else
        echo "failed to remove JndiLookup.class.  " 2>&1
    fi
fi


This Worklet follows the recommendations from RedHat for remediation. Additional details can be found here. This is a CVSS 10.0 vulnerability. Organizations using the Log4j library are advised to upgrade to the latest release immediately, seeing that attackers are already searching for exploitable targets.

For more information on remediation and patching, visit the Automox blog post here: https://blog.automox.com/log4j-critical-vulnerability-scores-a-10

Since the “workaround” can vary within different environments (and can break applications), I ended up writing this worklet for “finding” Log4j files across Linux devices. This helps isolating the hosts.

It just scans the device and, if anything is found, it e-mails the files list to whoever needs to know about it.

The worklet is using an in-house tool I wrote for messaging users, but it can be easily adapted to use other MTA solutions.

This works inside our environment. Please keep in mind you should make adjustments and test it before running in your production environment. I hope it helps.

The evaluation code is just the “exit 1”.

 

Remediation code:

#!/bin/bash

# Find log4j files, builds a list and e-mail them.

LOG_FILE="/root/log4j_find.log"

# Control flag
found="0"

if ! find / -type f -name "*og4j*.jar" -exec false {} +
then
  # find found something. Second run is super fast and will build the list.
  find / -type f -name "*og4j*.jar" > ${LOG_FILE}
  found="1"
fi

if r "$found" -eq "1" ]; then
  if -x YOUR_MTA_GOES_HERE ]; then
    YOUR_MTA_GOES_HERE -s "Log4j:$(hostname -s) may be affected" "$(cat ${LOG_FILE})"
  fi
fi

 

 

:D

Reply


Terms & ConditionsCookie settings