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.
An official fix was released by the Apache Log4j team, and backported to older branches:
In the past weeks, Log4j was found to have numerous vulnerabilities in a very short time. This is a combination of the following:
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:
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.