Update 2021-12-20 11:20 CET:
* As mentioned in our other blog post, Log4j 2.17 was released and fixes CVE-2021-45105
* The CVE has a base score of 7.5, but requires special circumstances (non-standard logging procedures).
* Most systems should not be affected by the DOS vector, regardless of patch level. Even in those few systems that are affected, it will be highly context dependent whether the payload crashes the application or if the application recovers. Even in affected systems, the effect can be small.
* This CVE from CVE-2021-45046, which was initially also marked as DOS. As Truesec mentioned when that CVE was released, CVE-2021-45046 always looked to have other effects than DOS (and was later reclassified). CVE-2021-45105 does not look to have effects beyond DOS so far.
Update 2021-12-17 10:15 CET:
* CVE-2021-45046 is now upgraded to Critical (9.0).
* Note that it still requires non-default logging configuration, making it considerably lower risk than the original CVE-2021-44228.
* This issue is RCE since there are bypasses of the local IP filter as well as bypasses of the serialization filter. Truesec has previously reported serial filter bypass internally to Log4j (among other independent reporters).
Update 2021-12-16 18:20 CET:
* Reports of bypass of the host filter in 2.15 could make CVE-2021-45046 higher risk than previously discussed.
* Most apps likely not be vulnerable to CVE-2021-45046 (requires non-standard logging procedures).
* Recommendations remain: Upgrade to 2.16+ if possible or remove vulnerable classes.
Update 2021-12-14 21:40 CET:
* The new CVE is for the additional vulnerability is CVE-2021-45046. This is for the case where attacker controlled data ends up in the log pattern (as opposed to in the log message in CVE-2021-44228), which is a less common scenario.
* The CVE is marked as DOS, but note that JNDI calls can be issued to machine local addresses (Update 2021-12-16: Reports of host filter bypass). In most cases this looks to be a small risk. CVE is written with 2.15 in mind. Previous versions lack the host filter, and may risk CVE if unusual logging patterns are used.
* As mentioned below: Flags and env variables no longer considered full countermeasures.
* Even more information available at the log4j2 security page. See “Older (discredited) mitigation measures”
* Fixed version for apps targeting Java 7 in the works. Planned to be called 2.12.2.
Update 2021-12-14 17:40 CET:
* Log4j 2.16 has been released 2021-12-13
* 2.16 is now the recommended version to install.
* Version 2.16 removes message lookups altogether and disables JNDI by default (even for JMS use cases). This removes the attack surface and mitigate special cases mentioned below.
* Version 2.15 can trigger JNDI calls under certain circumstances, but is unlikely to be vulnerable to any practical attacks due to 2.15 introducing a host filter in JNDI calls.
* Using flags such as log4j2.formatMsgNoLookups in versions < 2.15 (disabling message lookup) should only be done if upgrading is not possible, and while being aware of limitations below.
* Flags or properties do not fully mitigate the issue for certain (unusual) cases where user provided data is used as part of the message pattern. This is especially true if that data is likely to not be strictly validated prior to logging.
* Such scenarios happen when the user can control data that is not part of the actual log message in the log statement, but rather gets added when the statement is written (providing context to the log row). Such patterns can happen in applications that enrich their log statements based on user provided data using a thread context.
* If vulnerable it can lead to JNDI lookups even if lookups have been disabled for messages using flags or environment variables (which only affects the messages).
* This is a slightly different issue than the original Log4Shell vulnerability, but has similar vulnerable inputs and effects, although lower likelihood.
* Systems are less likely to be vulnerable than to “traditional Log4Shell” where user controlled messages are affected.
* If you suspect that your app uses user controlled thread context in logging, you should upgrade to 2.16 as soon as possible, or potentially remove the vulnerable classes or log patterns.
Update 2021-12-13 21:20 CET:
* Serialization-based JNDI exploits are now being reported in the wild (as discussed previously in the blog post).
* Added Truesec video discussing the vulnerability.
* Update mentioning details of the exfiltration vectors (reported to log4j 2021-12-10).
* A note about rudimentary detection techniques being surpassed by other means.
[Update 2021-12-13: For an up-to-date view on the vulnerability, see our video ‘What you Need to Know About the Log4Shell / Apache Log4j Injection Vulnerability (CVE-2021-44228)’ below]
While this vulnerability was initially presented on Twitter as if all users of log4j were vulnerable to the proof of concept RCE, it seems highly likely that the number of systems applicable for that vector is much smaller, while still being very large.
[Update 2021-12-13: Many additional exploit vectors are now available in the wild.]
The vulnerability is described at the Log4j vulnerability list and in the 2.15 announcement. Further discussions regarding the initial fix contain additional information.
The effect of the RCE can potentially be very large. There are both complicating and mitigating factors involved.
Complicating Factors
- Log4j is traditionally the most chosen log framework for Java applications. It is everywhere.
- Log4j is likely to be present in a large number of products, including appliances where patching can be problematic or impossible.
- Log statements are vulnerable even if they use a parametrized format.
Both log.info(“variable: “ + variable) and log.info(“variable: {}”, variable) are vulnerable.
So log4j can be vulnerable even if message patterns are not concatenated, which separates this from a traditional format string injection attack. - [Update 2021-12-14: See note above about other limitations of formatMsgNoLookups] The flag “log4j2.formatMsgNoLookups” does not disable the functionality for log4j version < 2.10.
- Using a release candidate/snapshot version was recommended on Twitter before 2.15 was released, but make sure to install the proper release. Some of these RC-versions are likely to have simple workarounds and are not fully protected from the RCE.
- Truesec has identified other risks with the lookup functionality even if RCE will not trigger on your system.
Mitigating Factors
- [Update 2021-12-13: Serialization exploitation is now being reported in the wild. As mentioned from the first version of this blog post we should not rely on Java versions to fix this issue.] Java version 8u191 (and to some extent 8u121) and later will not execute the first reported RCE vulnerability/PoC, but is potentially vulnerable to serialization vulnerabilities that could lead to RCE, among other vectors. The protection from the initial exploits was due to a change in Java where arbitrary classes are not executed based on LDAP and RMI responses. However, the call to an external LDAP server will happen, and complex parsing happens. It is not unrealistic to assume that there might be other RCE vectors relating to the parsing of the response (depending on JVM and classpath context). For example, using techniques similar to JNDI exploits previously demonstrated by Veracode.
- [Update 2021-12-14: See note above about other limitations of formatMsgNoLookups] For log4j versions 2.10-2.14 the flag “log4j2.formatMsgNoLookups” can be set to “true” to disable the vulnerable functionality.
- [Update 2021-12-14: See note above about other limitations. Also note that it is difficult to verify that lookups are actually disabled] For log4j versions 2.7+ you can change the pattern layout to disable lookups by outputting the message as “%m{nolookups}” (instead of for example %msg% or %m in your log pattern)
- Many modern applications use logback as logging backend instead of log4j (even if the log4j-api is used). In those cases, the vulnerable log4j-core library is not used.
This will be a vulnerability that will be exploited for many years as legacy systems and client software is likely to never get the patch.
Recommendations
- [Update 2021-12-14: See note above about other limitations of formatMsgNoLookups] Patch log4j or disable the format message lookup if running a vulnerable version (note limitations/risks involved in disabling).
- Verify if you are likely to have been vulnerable to the RCE (see mitigating factors).
- If possible, isolate third-party applications running the vulnerable versions. Both in terms of reducing the number of systems that can reach the application, and reducing the ability for the application to call out to the Internet.
It is recommended to patch the functionality even if the system is not known to be vulnerable to RCE.
[Update 2021-12-13: Payloads can be nested. This leads to the ability to exfiltrate environment variables either over the initial ldap/rmi channel or over DNS in environments blocking other protocols. Such environment variables can be highly sensitive, such as access keys to cloud environments and SaaS services.]
For environments that are not known to be vulnerable to RCE, in addition to the general risk of the LDAP/RMI logic involved and potential Server-Side Request Forgery (SSRF) attacks, we have identified an additional technique to exfiltrate potentially sensitive data. We want to urge everyone to quickly patch even if not vulnerable to the RCE attack.
Detection Techniques
For more information on developments, vulnerable systems and detection, see our other blog post: Log4j / Log4Shell Explained – All You Need to Know
[Update 2021-12-13: This section was written before more sophisticated detection techniques were generally available. Refer to other articles for more up-to-date methods.]
Detections are likely to increasingly be available in monitoring software. The list below is meant as inspiration for defenders looking for exploitation. Some simple things can be performed to improve detection:
- Look for patterns containing “${jndi” in incoming data and log data.
- Look for new outbound connections from the machine hosting the JVM.
- Look for child processes created by the JVM process. Note: In most successful attacks a second stage will create a child process to run malicious code. It is not necessarily the case, as the threat actor could utilize the JVM process to run arbitrary code instead.