CVE-2021-44832: A New Medium Severity Vulnerability Was Found in Log4j
The little brother of Log4j 1.x CVE-2021-4104 and Logback’s CVE-2021-42550 was finally discovered.
Another — though unlikely — vulnerability was discovered in Log4j’s latest versions: CVE-2021-44832. This is an Arbitrary Code Execution exploit using, yet again, the now infamous JNDI functionality.
The vulnerability lets an attacker with control over the Log4j configuration set a malicious datasource for the JDBC (Java DataBase Connectivity API) appender. The datasource refers to an attacker-controlled JNDI URI that will execute arbitrary code on the application using Log4j.
The vulnerability was given a well-deserved medium score of 6.6, (CVSS 3.1). Although this is a Code Execution attack, it demands a crucial precondition — the attacker must have permissions to modify the log4j.xml file, only available to a highly privileged actor. Alternatively, it requires an attacker to spoof a remote server from which the application imports the log4j.xml file, only if the application uses a remote log4j.xml file in the first place, and if it imports the file using an insecure connection (HTTP).
Since there is a very low chance that all of these conditions coming together to allow an attack, the vulnerability was given a medium CVSS score, which rates it as a Highly Complex attack, with High Privileges needed.
Fixing CVE-2021-44832
An official fix was released by the Apache Log4j team, and backported to older branches:
- If you’re using the Log4j 2.17.x branch for Java 8 and later – upgrade to 2.17.1
- If you’re using the Log4j 2.12.x branch for Java 7 – upgrade to 2.12.4
- If you’re using the Log4j 2.3.x branch for Java 6 – upgrade to 2.3.2
Addressing the Log4j Vulnerability Chaos With a Preemptive Mindset
In the past weeks, Log4j was found to have numerous vulnerabilities in a very short time. This is a combination of the following:
- It was subject to an unusual amount of examining eyes attracted to it since the original infamous CVE-2021-44228.
- It is a highly popular library used worldwide.
- It provides countless customization options and configurations.
The last point is key to understanding and preparing ourselves for future vulnerabilities to be discovered in Log4j:
With an abundance of features comes an abundance of possible breaches
Log4j can be configured in a great number of ways: appenders, pattern format lookups, remote configurations are just a few of the examples.
If your application’s logging system is customized in some non-default way, it should be used with a careful approach. We recommend you carefully examine each Log4j customization you use — remote calls, appender configurations, etc. — and ensure you are not opening the door to a potential attack exploiting or misusing your original intention:
- Make sure your configuration is using external data sources that you trust.
- Use secure connections when referring to remote sources.
- Ensure that your logging configuration is not using any data that can be manipulated by the application’s users.
- Re-evaluate the access control list of your configuration file, to ensure modifying permissions are given only to those you trust.
Other attack vectors could be discovered in the future, but a thorough security-focused inspection could put you ahead of them. It is especially important that you prevent these breaches, in the critical time frame immediately after a new attack vector is discovered. Not only that, this preventative approach will help protect you from breaches that will remain undiscovered by the community.
Learn More: Get free tools to detect and fix Log4j vulnerabilities at our Log4j Vulnerability Resource Center.
