• 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: A Medium Severity Was Found In Log4j
CVE-2021-44832: A Medium Severity 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.

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

Adam Murray

Adam Murray is a content writer at Mend. He began his career in corporate communications and PR, in London and New York, before moving to Tel Aviv. He’s spent the last ten years working with tech companies like Amdocs, Gilat Satellite Systems, Allot Communications, and Sisense. He holds a Ph.D. in English Literature. When he’s not spending time with his wife and son, he’s preoccupied with his beloved football team, Tottenham Hotspur.

Subscribe to Our Blog