• Home
  • Blog
  • CVE-2021-44832: A New Medium Severity Vulnerability Was Found in Log4j

CVE-2021-44832: A New Medium Severity Vulnerability Was Found in Log4j

CVE-2021-44832 Vulnerability in Log4j
CVE-2021-44832 Vulnerability 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.

Are You Vulnerable to Log4j?

Try this free CLI tool to scan your code & identify vulnerable versions of Log4j

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.

Meet The Author

Subscribe to Our Blog