Log4Shell vulnerability: What it is and how to stay protected

The Log4Shell vulnerability gained global attention when it was discovered in late 2021. Affecting the widely used Log4j logging library, this flaw made it dangerously easy for attackers to remotely execute code on a large number of targets.

In this guide, you’ll learn what made Log4Shell so disruptive, how it worked, and which systems were at risk. We’ll also cover how ExpressVPN handled the incident and address the wider lessons that can be learned from the whole affair.

What is the Log4Shell vulnerability (CVE-2021-44228)?

Also known as CVE-2021-44228, Log4Shell was a critical security flaw in Log4j, an open-source logging tool that’s used in a majority of Java applications and web servers. Many systems also rely on it to monitor system status and assist with development and troubleshooting.

Publicized in December 2021, Log4Shell was one of the most serious vulnerabilities ever reported. Systems using updated versions of Log4j are no longer at risk, but the prevalence of this logging library means that it can’t be said that the threat has totally gone away.

Affecting many versions of Log4j, Log4Shell went undetected for several years. Cybercriminals exploiting the vulnerability were able to execute arbitrary code on a targeted system. In turn, this enabled them to steal data, deploy malware, or even take full control of a system.

How the Log4Shell exploit works in vulnerable systems

The flaw exploits how earlier versions of Log4j handle two features: Java Naming and Directory Interface (JNDI) lookups and Message Lookup Substitution. On their own, these functionalities are essential and generally harmless. Message lookups replace variables such as “${java:version}” with real values before saving them as logs, while JNDI lookups fetch resources from external servers.

The flaw appears when these two features are used together. Taking advantage of the vulnerability involves crafting a log entry that tells Log4j to fetch and run code from a remote server. An attacker can place a malicious lookup command into anything that gets logged, such as a form field or browser header. When the targeted system receives a malicious input, Log4j records the log.

Next, Message Lookup processes the special characters injected by the attacker, which in turn triggers JNDI to perform a remote resource lookup. When the targeted system records the log, it inadvertently connects to the attacker’s server and downloads the payload, usually a malicious Java class.

Even in cases where execution is not possible, data can still be leaked out due to Message Lookup performing substitution before the JNDI lookup happens. Because substitution happens first, the resolved lookup string can contain things like usernames, hostnames, environment variables, session IDs, tokens, or other context that the logging code inserts. If the logging code then performs a network lookup to the attacker’s URL, those resolved values go along with the request (in the path, query, or protocol metadata).

For cybercriminals, taking advantage of the Log4Shell involves crafting a string and sending it to a victim’s system. In practice, this can be as simple as creating a new account on a public website or messaging a chatbot. Using the former as an example, a cybercriminal may name their account using Log4j’s standard JNDI and substitution syntax, plus a string pointing to an address hosting malware. Just as it is designed to do, Log4j logs the creation of the new account. In the process, it may run whatever code the hacker has linked to, possibly infecting the host server.

Why CVE-2021-44228 was considered a critical security risk

Before security patches were deployed, Log4Shell posed an enormous threat for three reasons: it was trivially easy to trigger remote code execution, the number of systems susceptible was massive, and the potential damage was severe.

As demonstrated in the example above, exploiting the flaw was exceptionally simple. An attack could be executed without advanced technical knowledge, niche tools, or special access. And with cybercriminals able to install malware, exfiltrate sensitive data, or even take over a target device or system, the negative effects could be drastic.

Log4j, the underlying tool that Log4Shell exploits, is built into all kinds of software published and used by major companies like Apple, Amazon, Microsoft, Cloudflare, and Cisco. Tenable, a cybersecurity company specializing in vulnerability management, reported that roughly 10% of the assets they assessed were vulnerable, while cloud security startup Wiz (in collaboration with Ernest & Young) found that about 93% of more than 200 cloud environments they examined were exposed to the threat when it was initially discovered. To make matters worse, many companies weren’t even aware they were using Log4j and therefore vulnerable. This was because Log4j is often introduced as a dependency of another library.

For all the above reasons, security professionals worldwide treated it as a top priority.

Using remote code execution (RCE) to gain control

In the worst cases, Log4Shell is classed as an unauthenticated remote code execution (RCE) vulnerability, meaning it allows anyone to essentially execute anything they want without providing any authentication. Providing credentials may be a requirement for penetrating certain systems, but it’s not a universal requirement.

In any case, RCE vulnerabilities allow cybercriminals to run their code on a system from anywhere in the world, as if they had direct access.

How attackers abuse LDAP, RMI, and DNS protocols

To carry out attacks, cybercriminals rely on communication protocols that are widely used for legitimate purposes. Among other options, attackers could exploit:

• Lightweight Directory Access Protocol (LDAP): A general protocol that helps applications connect to directory services, like user databases. Cybercriminals can trick systems into using LDAP to load malicious code from their servers.
• Remote Method Invocation (RMI): A method of running Java programs across networks. Attackers can hijack it to make the system run harmful code.
• Domain Name System (DNS): The means by which human-readable website names are translated into the numerical addresses used by computers. Exploited by Log4Shell, DNS can be used by hackers to quietly exfiltrate data.

Examples of real-world Log4Shell attack scenarios

As soon as Log4Shell became public, cybercriminals moved quickly to exploit the vulnerability. Minecraft was one target: players discovered they could trigger the exploit using the game’s chat feature.

Beyond gaming, cybercriminal groups used Log4Shell to infect cloud services and enterprise systems with ransomware. Some threat actors scanned the internet for exposed servers and injected commands that installed backdoors, programs enabling them to return later without being noticed.

What versions of Log4j are affected?

The Log4Shell vulnerability (CVE-2021-44228) affects Log4j versions 2.0-beta9 through 2.14.1. Version 2.15.0 mitigated the vulnerability, and subsequent patches provided further fixes for related vulnerabilities (see below).

While not vulnerable to Log4Shell, Log4j 1.x iterations contain other serious security risks and are no longer supported. Anyone using anything before 2.17.1 should update Log4j immediately.

Related vulnerabilities: CVE-2021-45046, 45105, and 44832 explained

After the initial Log4Shell fix, researchers found more issues tied to Log4j:

• 45046: This flaw was discovered after the first patch addressing Log4Shell (2.15.0). Investigators found that certain configurations could still allow remote code execution and lead to data leaks. Apache, the foundation behind Log4j, released version 2.16.0 to fix the problem.
• 45105: This vulnerability made systems susceptible to Denial-of-Service (DoS) attacks. It didn’t allow code execution but could crash systems by overloading them with recursive input. It was fixed in version 2.17.0.
• 44832: This was a lower-risk issue found in Log4j 2.17.0. It required more specific conditions to exploit, like having access to the system’s logging configuration. The issue was fixed with version 2.17.1.

How to protect against Log4Shell (and other threats)

Shielding yourself and systems from Log4Shell primarily comes down to updating Log4j. If you can’t do so right away, disabling JNDI lookups may offer a degree of temporary protection. You may also want to use a vulnerability scanner to determine if you're at risk.

The severity of Log4Shell points to the importance of cybersecurity and demonstrates that systems may not be as secure as they seem. Even for everyday users who don’t directly interact with Log4j, the incident showcases important practices that everyone can benefit from adopting. These include:

• Updating software to the latest version: With Log4Shell, deploying an update is the main solution. This is also true for many other security risks: vulnerabilities are regularly found in all kinds of software. When discovered, these are patched with updates. Whenever an app or your operating system notifies you about an update, it’s best to install it immediately.
• Implementing endpoint hardening: Tools like firewalls and antiviruses are a key part of any security setup. Though they only provide very limited protection against Log4Shell, both can be quite effective against many other threats. Firewalls can block traffic from malicious domains (among other things), while antiviruses will often stop malware from deploying.
• Use a VPN: By routing traffic through a secure server in a remote location, consumer VPNs enhance privacy for everyday users. Though not effective against Log4j, they can provide protection against various kinds of network-based attacks. Some options (including ExpressVPN) add an extra layer of protection by blocking connections to domains known to be malicious.

How ExpressVPN responded to Log4Shell

ExpressVPN took the threat of Log4Shell very seriously. Upon learning of the exploit, we were able to determine that our perimeter systems had not been affected. Nevertheless, emergency safeguards were activated, and we initiated an environment-wide patching process.

To protect our customers and infrastructure while updates were underway for their systems, we temporarily deployed additional controls to block LDAP and RMI traffic. This port-based solution was rolled out within days and provided an extra protective layer until a permanent solution was implemented in the form of Log4j updates.

In parallel, we devoted extra resources to threat intelligence, using our SIEM systems to monitor our entire environment for signs of compromise.

How ExpressVPN responds to threats

As a core part of our commitment to security, ExpressVPN has procedures for detecting and responding to zero-day vulnerabilities and other threats. Incident response protocols ensure our security teams handle new threats in a structured and methodical manner. Paired with hardware security measures, build verification systems, and a rigorous code review process, this framework significantly reduces the likelihood of serious incidents. We also maintain vulnerability disclosure and bug bounty programs to complement our internal security systems.

Our responses to threats such as Log4Shell and TunnelVision demonstrate the effectiveness of these systems, which are critical to achieving our goal of helping customers protect themselves.