How to detect and patch a Log4J vulnerability             

The Log4j vulnerability, or “Log4Shell,” is considered one of the most catastrophic software flaws ever. Apache patched the flaw in December 2021, yet it remains a concern for security teams. In fact, it is still among the most exploited security vulnerabilities.

Log4Shell persists because the Apache Log4j 2 software package it affects is one of the world’s most widely used logging libraries. Finding and fixing every instance of Log4Shell is expected to take a decade, according to the US Department of Homeland Security.

In the meantime, security teams can take some steps to speed up Log4Shell mitigation and remediation in their networks.

Before delving into 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) that records information and events in a program. Log4j isn’t standalone software but a package of code that developers can plug into their own Java apps. The Apache Log4j framework is used in some of the biggest services on the web, ranging from network infrastructure like Amazon Web Services (AWS) and Cisco solutions to popular apps like Twitter and Minecraft.

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

Log4Shell is a result of how vulnerable versions of Log4j handle the Java Naming and Directory Interface (JNDI), an API that Java apps use to access resources hosted on external servers. Threat actors can take almost total control of vulnerable systems by sending malicious JNDI lookup commands through Log4j. These commands trick the app into running arbitrary code that can do almost anything: steal data, install ransomware, knock devices offline, and more.

A typical Log4Shell cyberattack works like this:

1. A hacker sets up a server using a common protocol, like Lightweight Directory Access Protocol (LDAP) or Domain Name System (DNS). 
2. The hacker stores malware or some other malicious payload on the server.
3. The hacker sends a JNDI lookup to an app running Log4j, directing the app to the hacker’s server.
4. The JNDI lookup causes the app to connect to the hacker’s server, download the malicious payload, and execute the malicious code.

As Apache worked to patch Log4Shell, security researchers identified a handful of related flaws in some versions of Log4j. These include:

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

Finding every vulnerable instance of Log4j in a network can be difficult. Log4j appears in an estimated millions of apps, meaning security teams have a lot of assets to inspect.

Furthermore, Log4j is often present as an indirect dependency. That means it isn’t directly contained in the source code of an asset, but it appears as a dependency of a software package or integration the asset relies on. Google reports that most vulnerable Log4j instances are more than one level deep in the chain of dependencies, and some are as many as nine levels deep.

That said, security teams can detect Log4j vulnerabilities with the right tactics and tools.

Every version of Log4j 2 from 2.0-beta9 through 2.17 is vulnerable to Log4Shell or a related flaw. Put another way, security teams must find and address any version of Log4j earlier than 2.17.1.

Log4Shell and its related flaws are only present in “Log4j-core” files, which provide the core functionality of Log4j. The flaws are not present in “Log4j-api” files, which control the interface between apps and Log4j loggers.

Log4j can appear in assets the company controls, third-party assets the company uses (e.g., cloud services), and assets used by service providers with access to the company network. While Log4j is most likely to appear in Java-based apps, it can also be present in non-Java apps through dependencies and integrations.

Within Java apps, libraries like Log4j are often packaged in Java Archive files, or “JAR files.” JAR files can contain other JAR files, which in turn can contain their own JAR files, and so on. To find all vulnerable versions of Log4j, security teams must inspect all levels of JAR files, not only the top-level files.

Experts recommend using a combination of techniques for finding Log4j vulnerabilities.

Manual searches. Security teams can manually search for Log4j flaws. They can use development tools like Apache Maven to generate dependency trees that map all dependencies in an app, 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 suffer from Log4Shell. The list is available on GitHub .

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. Following Log4Shell’s discovery, some organizations released free tools designed to find Log4j vulnerabilities. Examples include Palantir’s Log4j-sniffer and the CERT Coordination Center’s scanner, among many others.

While specialized scanners are still available, many standard security solutions like vulnerability scanners, attack surface management (ASM) platforms and endpoint detection and response (EDR) solutions can now detect Log4j vulnerabilities.

Because Log4Shell can hide deep in dependency chains, security teams may supplement automated scans with more hands-on methods, like penetration tests.

Threat hunting. According to CISA, attackers have been known to use Log4Shell to break into a network and then patch the asset they compromised to cover their tracks. For that reason, it’s recommended that security teams assume a breach has already happened and actively hunt 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, like strange log entries or suspicious traffic patterns. Security teams should launch full incident response and investigation procedures for any possible hint of Log4Shell, given how serious the consequences of an attack can be.

Security teams have a few options when addressing Log4j vulnerabilities.

For complete remediation of Log4Shell and related flaws, organizations must update all instances of Log4j in their networks to the latest version (or at least to version 2.17.1). The latest versions of Log4j remove the functions attackers can exploit, and they remove support for commonly abused protocols like LDAP.

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

Security researchers agree that patching is the ideal solution. If patching isn’t feasible, organizations can use other mitigation steps to minimize the chances of an attack.

Disallowing message lookups in vulnerable apps. Attackers use a feature of Log4j 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 setting the value of the “LOG4J_FORMAT_MSG_NO_LOOKUPS” environment variable to “true.”

While removing the message lookup substitution function makes it harder for attackers to attack, it’s 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. In Log4j, the JNDIlookup class governs how the logger handles JNDI lookups. If this class is removed from Log4j’s directory of classes, then JNDI lookups can no longer be performed.

Apache notes the following command can be used 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 doesn’t stop attackers from mounting other exploitation attempts, like 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. Security teams can also block IP addresses associated with attacks or the strings that attackers commonly use in malicious requests, such as “jndi,” “ldap” and “rmi.”

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

Quarantining affected assets. If all else fails, security teams can quarantine affected assets while they wait for a patch. One way to do this is by placing vulnerable assets in an isolated network segment that cannot be accessed directly from the internet. A WAF can be placed around this network segment for extra protection.

One of the tricky things about remediating Log4Shell is that it doesn’t always stay patched. In November 2022, Tenable reported that 29% of the assets still vulnerable to Log4Shell were “recurrences,” meaning they were patched, but the flaw reappeared. Recurrences happen when developers accidentally use software libraries that contain unpatched versions of Log4j to build or update apps.

While developers can scrutinize the frameworks they use more closely, it’s easy to miss vulnerable versions of Log4j when they’re several levels deep in JAR files.

Implementing formal vulnerability management and patch management programs can offer security teams a more effective way to monitor assets for the return of Log4j vulnerabilities. Regular vulnerability scanning and penetration testing can help quickly catch new vulnerabilities, Log4Shell or otherwise. Patch management ensures new vulnerabilities are closed as soon as vendors release fixes.