LOG4J JNDI attack CVE-2021-45105 wso2 vulnerability [closed]

My present project is fully dockerized with large number of Spring Boot containers. Most of them are built with log4j 2+ (less than 2.7 for Java 8) version. How to fully proof the application from the JNDI attack CVE-2021-45105?

I know the best possible solution is to rebuild those containers with the log4j version, but it will take time and budget.

But if I disable the look up function at the docker compose level for every containers, using the below command, does it work?

“JVM_EXTRA_OPTS=-Dlog4j2.formatMsgNoLookups=true”

Secondly, If I delete the JndiLookup.class from log4j-core jar ‘zip -q -d log4j-core-*.jar’ and re-package, does it affect any present logging implementation? If yes, what functionalities can be affected?

If I set system property log4j2.formatMsgNoLookups=true, will it work? Where should I set this property to stop lookup?

Note: I was informed recently that I will need to handle/remove “JMSAppender” and “ServerSocket” classes also from log4j-core jar as they can be vulnerable also.

If I do not configure JMSAppender and SocketAppender, so they should not become vulnerable right? Or still I need to delete them?

Answer

I got the below points after doing some internet search,

for the above mentioned issues, to be safe we need to do the following:

Temporary Fix For log4j 1.x

• Check that the Log4j is not configured to perform JNDI requests

• Find JAR files containing the JMSAppender.class

  find . 2>/dev/null -type f -regextype posix-egrep -iregex ‘.*.(jar|war)’ -exec grep -i JMSAppender.class {} ;

found in BOOT-INF/lib/log4j-1.2.17.jar

• Remove JMSAppender.class from the identified JAR files

  zip -d log4j-1.2.16.jar org/apache/log4j/net/JMSAppender.class

  zip -d log4j-1.2.16.jar org/apache/log4j/net/SocketServer.class

Temporary Fix For log4j 2.x

• Find JAR files containing the JndiLookup and JndiManager classes

• Used following command to find the JAR files:

find . 2>/dev/null -type f -regextype posix-egrep -iregex ‘.*.(jar|war)’ -exec grep -i JndiLookup.class {} ;

find . 2>/dev/null -type f -regextype posix-egrep -iregex ‘.*.(jar|war)’ -exec grep -i JndiManager.class {} ;

• Remove JAR files containing the JndiLookup and JndiManager classes

For the parmanent fix,

Patch to log4j2.17.0 version, only use log4j2.17.0+ version

Log4j >=2.15.0 requires Java 8. Therefore, organizations that use Java 7 can update to a special security release  2.12.3.  Organizations that use Java 6 can update to a special security release 2.3.1.

Applications using Log4j 1.x may be impacted if their configuration uses JNDI. Log4j 1.x comes with Java Classes which will perform a JNDI lookup if enabled in log4j’s configuration file, including, but not limited to JMSAppender. Thus, an attacker who already has write access to an application’s log4j configuration file can trigger an RCE attack whenever log4j 1.x reads a corrupt/malicious configuration file. The best solution if the upgrade is not possible is to remove JMSAppender class and other.

Please note that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed (by Apache log4j). Users should upgrade to latest Log4j v2 (>=2.16.0) to obtain security fixes.

For Apache log4j versions from 1.2 (up to 1.2.17), the SocketServer class is vulnerable to deserialization of untrusted data, which leads to remote code execution if combined with a deserialization gadget.

Check if JMSAppender and SocketServer are enabled in the configuration file of log4j (e.g., log4j.properties or log4j.xml). Check that the access to the log4j configuration file is limited.