Since our last blog on a flaw in Apache Log4j, Apache has released Log4j version 2.16.0 which provides further fixes in the vulnerable library. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) released a Log4j guidance page which tracks vendor vulnerability information and mitigation advice. We recommend reviewing the latest reports and actioning the recommendations.
Details
Log4j Versions 2X
CVE-2021-44228
Field Effect’s 10 December 2021 blog post detailed a critical Remote Code Execution (RCE) vulnerability within Apache Log4j, tracked as CVE-2021-44228. This vulnerability affected Log4j versions:
- 2.0-beta9 to 2.12.1
- 2.13.0 to 2.14.1
In describing this flaw, the National Vulnerability Database (NVD) indicated that a “threat actor who can control log messages or log message parameters” can execute arbitrary code from Lightweight Directory Access Protocol (LDAP) servers. The flaw allows improper input validation when Java Naming and Directory Interface (JNDI) message lookup substitution functionality is enabled. JNDI injection also works with services including Remote Method Invocation (RMI), Domain Name Service (DNS), and Secure LDAP (LDAPS) making exploitation with these services possible.
As of 15 December 2021, there are 242 proofs-of-concept (POC) implementations published on GitHub. Using these POC implementations and various obfuscation techniques, multiple threat groups and security researchers have been scanning for systems vulnerable to this flaw. Exploits are likely to take advantage of systems that have external connections open, are using Java 7 (reaching end-of-life in December 2021), and running Java Runtime Environment version 8u191 and prior. Organizations running these systems should isolate their systems from the internet and apply the latest updates now to prevent being targeted.
In October 2018, Java versions 8u191 introduced restrictions for LDAP and RMI-based JNDI calls, making it harder to exploit JNDI. Later versions of Java versions contain existing application classes that could still be vulnerable to remote execution. It is possible that exploits using this vulnerability on other versions of Java will be used soon.
Log4j is a dependency within many third-party applications. Multiple vendors have reported being affected and are either working on updates or have already released them. The list of vendors is being continually updated and we recommend monitoring for, and applying the updates as they become available.
It is worth noting that only applications that include log4j-core JAR files are directly impacted by this vulnerability. Applications that use `log4j-api` and `log4j-to-slf4j` without the log4j-core JAR file are not impacted as they do not contain the Log4J implementation.
CVE-2021-45046
On 13 December 2021, Apache released Log4j version 2.16.0, which contained a further fix to address a subsequent vulnerability. Researchers found that Log4j version 2.15.0 in certain non-default configurations was susceptible to exploitation, making the previous fix incomplete. This problem is tracked separately from CVE-2021-44228 and was assigned its own identifier, CVE-2021-45046. Log4j version 2.16.0 disables access to JNDI by default and limits the default protocols to Java, LDAP, and LDAPS.
Log4j Versions 1.x
Several sources mistakenly reported Apache Log4j in version 1.x as vulnerable to CVE-2021-44228. Log4j version 1.2 is affected by another flaw, tracked as CVE-2021-4104, that can only be exploited when specific non-default configurations are in place. When the JMS Appender component is configured in the application’s Log4j configuration, it allows the deserialization of untrusted data. A threat actor could use that for RCE on the server if they had Write access to the Log4j configuration. Apache Log4j 1.2 reached its End of Life in August 2015.
Log4j versions up to 1.2.17 are also vulnerable to a 2019 vulnerability tracked as CVE-2019-17571 rated with a CVSS score of 9.8. The flaw is due to the deserialization of untrusted data which can be exploited to remotely execute arbitrary code.
Logback
Logback is a logging framework for Java applications which was created as a successor to the Log4j project. On 14 December 2021, Logback released version 1.2.8 which addressed some vulnerabilities.
Sources reported that Logback 1.2.7 was affected by JNDI attacks. According to the project developers, Logback does not offer a lookup mechanism at the message level and is not vulnerable to CVE-2021-44228. However, it is vulnerable to another, less severe issue, tracked as LOGBACK-1591. Logback may make JNDI calls from within its configuration file. Exploitation requires Write access to the logging configuration Logback.xml and access to the classpath. It is exploitable on Java versions 6u211, 7u201, 8u191, 11.0.1, and earlier.
Field Effect Posture
Field Effect has completed an internal review and confirmed that Apache Log4j is not used within our software and is not affected by these vulnerabilities. Field Effect deployed new network and endpoint-based rules to detect malicious activity associated with this vulnerability.
Covalence clients will have received an ARO if the affected software has been identified within their environment. Covalence’s network-based detection identifies exploitation attempts over non-encrypted communications. Covalence endpoint agent policies were updated to detect more potentially malicious behaviour originating from Java programs, to increase the identification of post-exploitation activities.
The Field Effect team continues to monitor for evidence of exploitation related to the vulnerabilities in Apache Log4j. If you believe a system in your environment may have been a victim of this attack, please contact forensics@fieldeffect.com for support and analysis.
Recommendations
We strongly advise following the guidance below and updating the affected products to the latest version immediately.
We recommend that affected system owners should not only upgrade to the latest version of the Java Runtime Environment but also update Log4j to version 2.16.0 immediately. This update fully remediates the most severe vulnerability, CVE-2021-44228 as it fully disables JNDI and removes support for Message Lookups. When an update to the log4j-core is applied, other JAR files (e.g.log4j-api) need to be updated as well.
If you are using Apache Log4j 1.2, we recommend upgrading to version 2.16 as soon as possible.
We also recommend monitoring for third-party updates and applying them when they become available. If a product you are using is not on the list, we recommend contacting your vendor or developer to inquire about their exposure.
We recommend reviewing the list of mitigations provided by the vendors and applying them in the event that you are unable to apply the updates.
References
