Logfile Vulnerability Log4Shell for RCE

Source: security-flashcards.com

This article briefly describes a critical zero-day vulnerability called Log4Shell that existed in the widely used Java logging library Log4j used by millions of Java applications reachable from the Internet. The vulnerability can be exploited by even unskilled attackers and results in a remote code execution (RCE) when Log4j is used to write user controlled data into a log file.

The vulnerability is one of the worst ones in 2021 and was rated as very critical. It received a CVSS score of 10. CVSS is basically a metric to rate vulnerabilities and 10 is the maximum value that can be assigned to a vulnerability.The vulnerability was assigned the CVE number CVE-2021–44228.

Last update: 20th December, 2021

How Can an Attacker Exploit the Vulnerability?

Let’s assume you have a web application written in Java that logs the user agent of each request. You log this data because you use the data to create browser statistics for your web site in order to better optimize the web site.

If you use a vulnerable Log4j to log the user agents, an attacker could set the following string as the user agent of a request:


When your application logs this string, Log4j by default tries to interpret the string. Here, Log4j performs a JNDI lookup and sends a request to the attacker’s controlled host attacker.wtf through the Java Naming and Directory Interface (JNDI). The response contains malicious code that is executed.

Why Is It possible?

Log4Shell is possible because Log4j has a feature called lookups. According to the documentation “Lookups provide a way to add values to the log4j configuration at arbitrary places”. These arbitrary places also include a log message itself. On the one hand lookups can be very simple. For instance, if the string ${java:version} is logged, it is replaced by the Java version (e.g. “Java version 11.0.11”). On the other hand, Lookups can be quite complex and even network communication can be involved to resolve a Lookup. The JNDI Lookups is such a Lookup.

Who Is Affected by Log4Shell?

If you can answer all of the following conditions with yes, you are affected by Log4Shell:

  • You’re Java application logs user controlled data as is into a logfile.
  • You’re using a Log4j version ≤ 2.14.1 to log user controlled data.
  • The application which logs the data can connect to a host controlled by an attacker to download the malicious code.

What Java Versions Are Affected?

All Java versions are affected. The vulnerability is not limited to particular versions.

It was reported that Java versions not greater than 6u211, 7u201, 8u191 and 11.0.1 are not affected by the vulnerability because loading remote code via LDAP is disabled by default for these Java versions. This is correct for the LDAP attack vector. However, an attacker is not limit to use LDAP only. It is also possible to use RMI (remote method invocation) to load the malicious code as RMI is not disabled by default even in recent Java versions. An attacker just needs to use “jndi:rmi” instead of “jmdi:ldap”.


Update Log4j to version ≥ 2.16.0. This version is available on Maven Central here and from Apache here.

If you can’t update, disable JNDI lookups. You have two options.

Option 1: If you use Log4j version ≥ 2.10, disable lookups by setting the property:


Option 2: Remove the JndiLookup class from the log4jar file

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Can I Block Particular Ports to Block Loading Malicious Code?

An attacker is not limited to use a specific port of the outgoing connections such as ports used for LDAP (ports 389 and 636 for LDAP over TLS) and RMI (port 1099). The attacker can specify arbitrary ports right after the hostname, e.g. attacker.wtf:12345. Thus, configuring a firewall to block particular ports for outgoing connections can easily be bypassed.

Best Practices

In general it is a good idea to follow these best practices:

  • Do not log user controlled data. If you need to log user controlled data, escape or sanitize the data first. In general all special and control characters should be escaped or sanitized. To mitigate Log4Shell it’s sufficient to remove characters such as ‘$’, ‘{‘, and ‘}’.
  • Block all connections initiated by your application to untrusted hosts.





Dev-Sec-ML — https://twitter.com/_etzold — Creator of Security Flashcards https://security-flashcards.com

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Best Jailbreak Tweaks for Hackers 2021

Voting for NEST Protocol to win $NEST

Pegasus Referrals Program

COOKIES: Are they sweet or bitter?

It’s 9am — Do You Know Where Your Data Are?

Lock Liquidity for Trust Trade

Critical Vulnerability in F5’s BIG-IP (CVE-2020–5902)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Daniel Etzold

Daniel Etzold

Dev-Sec-ML — https://twitter.com/_etzold — Creator of Security Flashcards https://security-flashcards.com

More from Medium

“Tricking” our developers into liking application security

Protect Your Data in a Vulnerable Information Security Era

PicoCTF \\ Static ain’t always noise \\ General Skills

Solving reversing challenges from MalwareTech.com