Apache Log4j Java Library
Description
The Apache Log4j Java Library is an open-source java logging library developed and maintained by the Apache Software Foundation. The library is widely used in many commercial and open-source products as a logging framework for Java.
Problem
On the 24th Nov 2021, the technology company Alibaba Group Holding Limited, reported a zero-day security vulnerabilitiy, it had discovered in the Apache Log4j Java Library, to the Apache Software Foundation. The discovery was publicly disclosed on the 9th Dec 2021 in Common Vulnerability Exposure (CVE) Report CVE-2021-44228. Three (3) further security vulnerabilities were discovered in the Apache Log4j Java Library and were subsequently publicly disclosed. See Apache log4j java library security vulnerability - CVE Reports & CVSS Metrics below, for details.
Systems & Standards for reporting and assessing the severity of security vulnerabilities
| No. | System | Description |
|---|---|---|
| 1. | Common Vulnerabilities and Exposures (CVE). | The CVE system is used to identify, define, catalog and publicly disclosed known information-security vulnerabilities and exposures. |
| 2. | The Common Vulnerability Scoring System (CVSS) | CVSS is a free and open industry standard for assessing the severity of computer system security vulnerabilities. It provides a numerical (0-10) representation of the severity of an information security vulnerability. |
Apache log4j java library security vulnerability - CVE Reports & CVSS Metrics
| No. | CVE Report | CVSS Metrics | Date Disclosed |
|---|---|---|---|
| 1. | CVE-2021-44228 | 10.0 | 09 Dec 2021 |
| 2. | CVE-2021-45046 | 9.0 | 13 Dec 2021 |
| 3. | CVE-2021-45105 | 5.9 | 15 Dec 2021 | 4. | CVE-2021-44832 | 6.6 | 28 Dec 2021 |
CVE-2021-44228: This is a zero-day security vulnerability, it has been given the descriptor "Log4shell". This security vulnerability could lead to information leaks and be exploited for remote code execution (RCE) attacks. Apache Log4j java library versions 2.0-beta9 to 2.14.1 are affected. Java Naming and Directory Interface (JNDI) features used in the configuration, log messages, and parameters can be exploited by a malicious actor to perform RCE. Specifically, a malicious actor who can control log messages or log message parameters, can execute arbitrary code loaded from Lightweight Directory Access Protocol (LDAP) servers when message lookup substitution is enabled. This vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.
CVE-2021-45046: This security vulnerability allows the Apache Log4j Java Library to be exploited for a Denial of Service (DoS) attack against a third party. The vulnerability is exploitable in non-default configurations. A malicious actor can send a crafted request that contains a recursive lookup which can result in a DoS condition. It was subsequently discovered that additional exploits against the Log4j 2.15.0 release could lead to information leaks, remote code execution (RCE) and local code execution (LCE) attacks. All version from 2.0-beta9 to 2.15.0, excluding 2.12.2 of the Apache Log4j java library are affected.
CVE-2021-45105: This security vulnerability allows the Apache Log4j Java Lirary to be exploited for a Denial of Service (DoS) attack against a third party. The vulnerability is exploitable in non-default configurations. An attacker can send a crafted request that contains a recursive lookup which can result in a DoS condition. Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) are affected. To address this vulnerability, Apache released Log4j2 version 2.17.0 and 2.12.3.
CVE-2021-44832: This security vulnerability allows for Remote Code Execution (RCE) in Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4). A malicious actor with permission to modify the logging configuration file can construct a malicious configuration using a Java Database Connectivity (JDBC) Appender with a data source referencing a Java Naming and Directory Interface (JNDI) Uniform Resource Identifier (URI) which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
Background Information - Apache Log4j Java Library
Log4j is an open-source Java logging library developed by the Apache Foundation which is widely used in many applications. It is frequently included as a default log handler in enterprise Java applications and is commonly included as a dependency component in other Java projects. Log4j is also used in many Software -as-a-Service (S-a-a-S) and cloud services.
Log4Shell Vulnerability
When an operation attempts to write messages to logs, Log4j allows lookups to provide additional information to the log messages. This could include retrieving and adding to the message content, modifying timestamps, or changing environment details to give developers the clues they need if asked to debug the software. This information can be retrieved locally, or it can be retrieved from a remote machine. For the remote lookup, Log4j uses the Java Naming and Directory Interface (JNDI), which provides developers the means to look up objects using different services and protocols such as LDAP, DNS, RMI, and CORBA.
The Apache Log4j Java Naming and Directory (JNDI) Attack
The chart below was developed by the Swiss Government Computer Emergency Emergency Response Team (GovCERT). It provides a visual guide to the mitigation options to the Apache Log4j JNDI Attack.
Solution
Upgrade to Apache Log4j 2.3.3 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).
Apply all new software patches and updates for the Log4j java library suite when released by the Apache Software Foundation.
If it is not possible to apply the latest software patches and updates to the Apache Log4j Java Library Suite, the following mitigation measures may be considered as a temporary solution.
Temporary Solution for the Mitigation of the Log4j Zero-Day Vulnerability
| No. | Action | Explanation |
|---|---|---|
| 1. | Disable Apache Log4j library. | Disabling software using the Apache Log4j library is an effective measure, favoring controlled downtime over adversary-caused issues. This option could cause operational impacts and limit visibility into other issues. |
| 2. | Disable JNDI lookups or disable remote codebases | his option, while effective, may involve developer work and could impact functionality. Disconnect affected stacks. Solution stacks not connected to agency networks pose a dramatically lower risk from attack. Consider temporarily disconnecting the stack from agency networks. |
| 3. | Isolate the system. | Create a “vulnerable network” VLAN and segment the solution stack from the rest of the enterprise network. |
| 4. | Deploy a properly configured Web Application Firewall (WAF) in front of the solution stack. | Deploying a WAF is an important, but incomplete, solution. While threat actors will be able to bypass this mitigation, the reduction in alerting will allow an agency SOC to focus on a smaller set of alerts. |
| 5. | Apply micropatch. | There are several micropatches available. They are not a part of the official update but may limit agency risk. |
Additional Information
Apache Log4j Security VulnerabilitiesShadowserver Special Reports - Vulnerable Log4j Servers
Abnormal - Attackers Use Email + Log4j - Vulnerability to Efficiently Exploit Email Infrastructure
MANDIANT - Log4Shell Initial Exploitation and Mitigation Recommendations
GitHub - CISA Log4j (CVE-2021-44228) Vulnerability Guidance
GitHub - CVE-2021-44228_Scanner
CVE-2021-44228
CVE-2021-45046
CVE-2021-45105
ED 22-02: Apache Log4j Recommended Mitigation Measures
Appache Software Foundation - Logging Services - Architecture
GovCERT.ch - Zero-Day Exploit Targeting Popular Java Library Log4j
Ref:[GovCERT.CH and US-CERT]