This vulnerability, known as “Log4Shell” or “Logjam”, has become a worldwide problem.
So far, the log4j vulnerability, tracked as CVE-2021-44228, has been exploited by all sorts of threat groups, including state-sponsored hackers and ransomware groups, to inject Monero miners into vulnerable systems.
The use of Log4j is being abused in many software products, and advisories from several vendors have been released. Also, “logback” does not seem to be an unrelated issue.
This summarizes several relevant CVEs that have been identified so far, and provides good reasons to abandon log4j version 2.15.0 in favor of 2.16.0.
What CVEs do I need to be concerned about?
It all started on December 9, 2021, when the PoC exploit for the critical Log4j zero-day was published on GitHub.
Then the vulnerability was disclosed and a large number of scans were performed by attackers targeting vulnerable servers.
Given the widespread use of Log4j in the majority of Java applications, Log4Shell quickly became a point of attack for companies and governments around the world.
Below is a list of CVEs you should know about, in the order in which they occur.
CVE-2021-44228 [Critical]
The original vulnerability in “Log4Shell” or “logjam” is an untrusted serialization bug. It gives an unauthenticated attacker remote code execution (RCE) capability, allowing a complete system takeover.
CVE-2021-44228, reported to Apache on November 24, 2021 by Chen Zhaojun of the Alibaba Cloud Security Team, affects the default configuration of several Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Apache Struts2, Apache Solr, Apache Druid, and Flink.
This vulnerability lurks in the log4j-core component and is limited to 2.x versions from 2.0-beta9 to 2.14.1. Log4Shell was fixed in version 2.15.0, but was determined to be incomplete
Florian Roth, a threat intelligence analyst, introduced the Sigma rule, which can be employed as one of the defenses.
CVE-2021-45046 [Low]
Rated as low severity, this is a denial of service (DoS) flaw with a score of only 3.7. This flaw was caused by an incomplete fix for CVE-2021-44228 in 2.15.0. The fix applied in 2.15.0 largely resolved this flaw, but not in certain non-default settings.
Log4j 2.15.0 limits JNDI LDAP lookups to localhost by default. However, an attacker with control over the input data of the Thread Context Map (MDC) can create a malicious payload via the JNDI Lookup pattern to cause a denial of service attack. This applies to non-default configurations that use Context Lookup, such as $${ctx:loginId}, or Thread Context Map patterns (%X, %mdc, or %MDC) to lay out non-default patterns.
Log4j 2.16.0 fixes this problem by removing support for the message lookup pattern and disabling the JNDI feature by default
CVE-2021-4104 [High]
It was previously thought to be safe, but it turns out that Log4Shell lurks in older Log4j as well. Basically, any non-default configuration of a Log4j 1.x instance that uses the JMSAppender class is also affected by the untrusted deserialization vulnerability.
Although less severe than CVE-2021-44228, this CVE still affects all versions of log4j:log4j and org.apache.log4j:log4j components for which there is only a 1.x release. Since these are used versions, there is no fix for the 1.x branch anywhere, and you will need to upgrade to log4j-core 2.16.0.
CVE-2021-42550 [Moderate]
There is a vulnerability in the Logback logging framework.
Logback was said to be “unrelated to log4j 2.x and (logback) does not share that vulnerability”, but CVE-2021-4104 was found to affect Log4j 1.x as well, and was assessed as potentially affecting Logback as well. However, CVE-2021-4104 was found to also affect Log4j 1.x and was evaluated as potentially affecting Logback as well.
New versions of Logback, 1.3.0-alpha11 and 1.2.9, have been released to address this vulnerability.
Log4j 2.15 is open to attack: DNS leak and possible RCE
Log4j 2.15.0 may contain more serious vulnerabilities than those discovered so far, making 2.16.0 much more secure.
Because of the aforementioned CVE-2021-45046, it was initially thought that the biggest impact from this flaw would be DoS, but that assumption has turned out to be changing.
Cloud security company Praetorian has demonstrated that its version of Log4j 2.15.0 can be exploited for DNS-based data exfiltration from external hosts, and is working with Apache to release the information.
In a blog post by Praetorian
This is a response to CVE-2021-45046, which applies to Log4j version 2.15. According to the CVE description, this vulnerability could cause a denial of service when using certain types of pattern layouts. The reason they state that it is DoS only is due to the localhost permission list.
We have developed a bypass of this “localhost” allowlist and sent the details to Apache. At the very least, it means that systems vulnerable to CVE-2021-45046 are vulnerable not only to DoS, but also to DNS exfiltration of potentially critical environment variables.
In either case, the action defenders should take is clear: moving to 2.16.0, where jndi is disabled by default, is the safest course of action and the one we recommend to our customers
Log4J 2.15.0’s allowedLdapHost and allowedClasses checks in Log4J 2.15.0. Deserialization will be done as usual
Similarly, Alvaro Muñoz of GitHub Security Lab also reported successful remote code execution bypassing the fix made in 2.15.0.
As a side note, the default settings are unaffected; Lookups must be enabled by specifying %m{lookups} or by using methods such as CVE-2021-45046
While the worst-case scenario caused by Log4j 2.15.0 is not yet fully known, suffice it to say that it is not likely to be limited to DoS alone.
As the situation continues to change, it is recommended that organizations and developers upgrade to 2.16.0. Also, please continue to monitor Apache’s Log4j advisory page for the latest information.
Comments