Log4j zero day security vulnerability, detection and logfix

• 24 February, 2022
• No Comments

How many of us are surprised to learn that yet another log4j security vulnerability has been discovered? In my office, that would be a big, fat zero. We don’t like it mind you, but surprised? Heck no. The latest, CVE-2021-44832, with a Common Vulnerability Scoring System (CVSS) rating of 6.6, moderate, isn’t awful. But this vulnerability can still be used to conduct an Arbitrary Code Execution (ACE) attack. That’s more than bad enough.

The Apache Software Foundation (ASF) has already released the fix, Log4j 2.17.1 on Dec. 29. Now, you need to find the vulnerable log4j2 libraries and patch them.

If left unpatched, an attacker can use the vulnerability to conduct a RCE with the Java database connectivity (JDBC) Appender. This, like the name says, is Java’s default application programming interface (API) for accessing database management systems.

Besides a vulnerable version of log4j being used, this attack requires the attacker to have permission to modify the logging configuration file. With that, they can build a malicious configuration using a JDBC Appender with a data source referencing a Java Naming and Directory Interface (JNDI) URI which can execute remote code. You can fix this issue by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

Checkmarx security researcher Yaniv Nizry claimed credit for discovering the vulnerability. In his blog post describing the log4j2 security weakness, Nizry added that this one’s harder to exploit 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 Man in the Middle (MITM) attack,” using input ending in a vulnerable configuration variable or by modifying the config file.

So, while it’s harder, a hard-working hacker can still wreak havoc on your system with it. While looking at the code, the JDBC Appender caught Nizry’s eyes since there were some public ways of causing a remote code execution (RCE) via JDBC Java deserialization. But then he noticed you could configure log4j so it would fetch the database source dynamically and remotely via JNDI using the DataSource element. Worse still, you could feed an arbitrary Lightweight Directory Access Protocol (LDAP) remote URL to it. You can see where this is going from here. Once that was done, they could insert a malicious payload. In their tests, they simply used calc.exe as their delivery. Still, if you want to start say a remote shell, you could do that too.

As I write this, there are no known exploits. Let me repeat that, there are no “known” exploits. It’s time to get cracking and do some more patching.

Have fun and may your beeper not go off on New Year’s Eve.

Oh, who are we kidding? The way things are going you’re still going to be tracking down and patching log4j2 libraries well into 2022. Hang in there, folks!