Why You Need to Know About Recent Log4j Vulnerabilities? | HCLTech

Why do you need to know about recent log4J vulnerabilities?

Why do you need to know about recent log4J vulnerabilities?
March 15, 2022

Introduction

Java log4j is a popular logging framework in Java, under the Apache Software License. It is a fast, versatile, and reliable logging framework.

The advantage of Apache log4j is that logging can be done at different levels. They are hierarchical: TRACE, DEBUG, INFO, WARN, ERROR, and FATAL. By setting a particular log level, messages will get logged for that level and all levels above it. It can be configured using a configuration file without requiring a code update to prevent log4j vulnerabilities.

Example:

2021-06-08 12:11:44 INFO testlog1

2021-06-08 12:11:51 DEBUG testlog2

2021-06-08 12:11:53 INFO testlog3

What happened to log4j recently?

Recently a new zero-day exploit was announced recently against the Log4J2 library, where it can allow an attacker to execute the code remotely, which has been reported with CVE-2021-44228 and CVE-2021-45046 against the log4j-core jar.

A new zero-day exploit was recently announced against the Apache log4J2 library, where it can allow an attacker to execute the code remotely, which has been reported with CVE-2021-44228 and CVE-2021-45046 against the log4j-core jar.

 About vulnerabilities till now:

Name

Vulnerability type

Affected log4j versions

CVE-2021-44228

RCE

2.0 through 2.14.1

CVE-2021-45046

Denial of Service (DoS) and RCE

2.0 through 2.15.0

CVE-2021-4104

RCE

1.2*

CVE-2021-45105

Denial of Service (DoS)

2.0-beta9 to 2.16.0

CVE-2021-44832 

 

RCE

2.0 to 2.17.0

 

Details of CVE-2021-44228 

Apache Log4j2 starting from 2.0-beta9 to 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in the configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker with access to log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. By default, this behavior has been disabled from apache log4j 2.15.0. This functionality has been completely removed from version 2.16.0. These log4j vulnerabilities are specific to log4j-core and do not affect log4net, log4cxx, or other Apache Logging Services projects.

Details of CVE-2021-45046

The solution to address CVE-2021-44228 in the 2.15.0 log4j versions of apache log4j was incomplete in certain non-default configurations. This could allow  attackers, with control over the Thread Context Map (MDC) input data when the logging configuration, to use a non-default Pattern Layout with either a Context Lookup or a Thread Context Map pattern to craft malicious input data using a JNDI Lookup pattern. Those actions result in certain log4j vulnerabilities, such as an information leak in and remote code execution in some environments and local code execution in all environments. The apache log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) have addressed this issue by removing support for message lookup patterns and disabling JNDI functionality.

Details of CVE-2021-45105

It is a newly released Denial of Service (DoS) vulnerability in Apache log4j2. The vulnerability is exploitable in non-default configurations. An attacker can send a crafted request that contains a recursive lookup that can result in a DoS condition. To fix this vulnerability, Apache has released Log4j 2.17.0 version.

Details of CVE-2021-44832

Apache Log4j2 versions from 2.0-beta7 to  2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution attack. An attacker with access to modify the Java log4j logging configuration file can build a malicious Apache log4j2 configuration by using a JDBC Appender with a data source referencing a JNDI URI, which can execute remote code. This is addressed by limiting JNDI data source names to the Java protocol in Java log4j versions 2.17.

Details of CVE-2021-4104

JMSAppender, in log4j 1.2 version, is vulnerable to deserialization of untrusted data if the attacker has the ‘write’ permissions to the log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations that cause JMSAppender to perform JNDI requests for executing remote code in a pattern similar to CVE-2021-44228.

How to scan log4j vulnerabilities:

Qualys Log4j Vulnerability Scanner 1.2.18.0


Supported CVE(s): CVE-2021-4104, CVE-2021-44228, CVE-2021-45046, CVE-2021-45105

Scanning Local Drives...

Log4j Found: 'D:\app\/lib/log4j-core.jar' ( Manifest Vendor: Apache Software Foundation, Manifest Version: 1.1.3, JNDI Class: NOT Found, Log4j Vendor: log4j, Log4j Version: 1.1.3, CVE Status: N/A )

Log4j Found: 'D:\app/lib/log4j.jar' ( Manifest Vendor: Apache Software Foundation, Manifest Version: 1.1.3, JNDI Class: NOT Found, Log4j Vendor: log4j, Log4j Version: 1.1.3, CVE Status: N/A )

Log4j Found: 'D:\app\log4j-1.1.3.zip' ( Manifest Vendor: , Manifest Version: , JNDI Class: NOT Found, Log4j Vendor: Unknown, Log4j Version: Unknown, CVE Status: N/A )

Log4j Found: 'D:\app\log4j-1.2.17.jar' ( Manifest Vendor: Apache Software Foundation, Manifest Version: 1.2.17, JNDI Class: NOT Found, Log4j Vendor: log4j, 

Scan Summary:

    Scan Date:        2021-12-21T13:27:49-0800

    Scan Duration:      66 Seconds

    Files Scanned:      919154

    Directories Scanned:   268121

    JAR(s) Scanned:     617

    WAR(s) Scanned:     0

    EAR(s) Scanned:     0

    ZIP(s) Scanned:     110

    Vulnerabilities Found:  12

Mitigation for 2.x versions:

https://github.com/cisagov/log4j-scanner

Example of output:


Possibly vulnerable jar '/usr/lib/jars/log4j-core-2.15.0.jar'.

Possibly vulnerable jar '/usr/lib/jars/log4j-core-2.15.jar'.

Possibly vulnerable jar '/usr/lib/jars/log4j-core-2.jar'.

Possibly vulnerable jar '/usr/lib/jars/log4j-core.jar'.

Mitigation for 2.x versions:

  • Upgrade to log4j 2.17.1
  • For Log4j versions >=2.10
    A system property can be set for log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to ‘true’
  • For Log4j versions >=2.0-beta9 and <=2.10.0
    remove the JndiLookup class from the classpath. For example:

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

Mitigation for 1.x versions:

A few mitigation options can be used to prevent the exploitation of CVE-2021-4104.

  • Do not use the JMSAppender in the java log4j configuration
  • Remove the JMSAppender class file (org/apache/log4j/net/JMSAppender.class)
  • Limit OS user-access to prevent an attacker from being able to modify the Log4j configuration

References

  • https://logging.apache.org/log4j/2.x/security.html
  • https://en.wikipedia.org/wiki/Log4j

Get HCLTech Insights and Updates delivered to your inbox