Learn about this Log4j vulnerability and how to remediate it

Learn Log4Shell

Wendy Rodriguez

What is the Log4j vulnerability?

Have you ever heard of or found a crack in the system? A gap that allows you to bypass a law? This is known as a loophole. You can track down a loophole in almost every field humans are involved in, waiting to be found and exploited or fixed. CVE-2021-44228, or Log4Shell vulnerability, is one such, a dangerous loophole in the security measures of a system that needs to be addressed to maintain its integrity and safeguard against potential cyberattacks. The Log4Shell vulnerability is found in the broadly-used logging tool Log4j, a software component used across the world in millions of apps, making Log4Shell one of the most critical vulnerabilities ever.

The Log4j vulnerability known as "Log4Shell" is a critical remote code execution (RCE) vulnerability in the Apache Log4j logging library versions 2.0-beta9 to 2.14.1. It was first disclosed in December 2021, and it is considered to be one of the most serious software vulnerabilities in recent years. Attackers are able to execute arbitrary Java code on systems that are using vulnerable versions of the Apache Log4j library thanks to the Log4Shell remote code execution flaw, which, in turn, allows malicious actors to take control of servers or systems, steal data or install malware.

What is Log4j?

Log4j was created to address the needs for flexible and configurable logging or tracing API for Java applications. It was developed as an open-source logging framework and, after several improvements, evolved into the Log4j we know today. Its distributor, Apache Software Foundation, released this utility in 2001. It’s widely used because of its flexibility, as it is suitable for a wide range of applications with different logging requirements; also because of its performance, as it aims to minimize the impact of logging on the applications that generate a large number of log messages. Other reasons include that it’s easy for developers to use as it offers a wide range of configuration options, and it’s an open-source project, which allows for anyone to use and contribute to it.

What is Log4j2?

Log4j2 is a logging framework for Java applications and it was released as an upgrade to Log4j with several improvements, like:

  • Performance: Log4j2 is significantly faster than Log4j, especially in multi-thread applications.

  • Flexibility: Log4j2 provides a wider range of configuration options, allowing users to tailor the logging behavior to their needs.

  • Security: Log4j2 includes a number of security features, like a configuration to use a whitelist of allowed log levels.

  • Community support: Log4j2 is a popular logging framework, there is a large community of users and developers who provide support, questions are answered, features are added and fixes are shared.

When was Log4Shell discovered?

The vulnerability was first exploited in the popular gaming service Minecraft by sending a single line of malicious text to the game's chat, allowing the game's servers to be compromised, but it wasn't until November 2021 that Chen Zhaojun, a security researcher at Alibaba, reported the vulnerability to the Apache Software Foundation. It was already being discussed in the computer security communities, and furthermore, a demonstration of how to exploit this vulnerability was made publicly available. On December 9, 2021, Apache reported a zero-day vulnerability, which was initially issued privately. By December 10, Log4Shell was publicly disclosed and an initial patch was released. That same day, CVE published its first report about it, naming it CVE-2021-44228 and providing almost daily updates on findings and fixes.

Get started with Fluid Attacks' Vulnerability Management solution right now

Why was Log4Shell so critical?

Java stands as one of the leading programming languages being used for many backend systems, from small business servers to organizational automation systems and IoT devices. The majority of these systems implement logging by different means. The simplest way to do this has been to use the Log4j library. After it was reported that the library contained a vulnerability, many declared it a critical breach because:

  • Log4Shell, being a zero-day vulnerability, was something cybercriminals took advantage of before anyone knew about it. Evidence indicates that the attackers first exploited it a few days prior to its public announcement.

  • About 40% of all networks across the world could be vulnerable to log4j flaws. At the time, the most affected commercial services included Amazon Web Services, iCloud, Cloudflare, Minecraft: Java Edition, Tencent QQ, Steam and many others. The Washington Post called it “the most serious security breach ever” and the fallout is said to last for years.

  • Java is also used in equipment for industries, governments, hospitals and other customized devices. The Log4j library is known to be used by these devices as well as conventional computers and servers.

  • The well-known VMware Horizon desktop and app software solution was highly exploited, receiving a lot of attacks that successfully breached this software.

  • This is a hypothetical, but Log4j is an open-source library that can be used by many developers, who might not follow licensing norms and not inform of its usage. Meaning, Log4j could’ve been implemented in applications that don’t know they’re using it, thus rendering them vulnerable without the users' or owners' knowledge.

How does Log4shell work?

The vulnerability exploits a feature in Log4j called JNDI lookup, which is a mechanism that allows Java applications to look up resources on remote servers. Log4j uses JNDI lookup to resolve log message patterns. Log4Shell occurs when Log4j is configured to use JNDI lookup to resolve log message patterns that contain malicious LDAP URLs. The attacker would need to send a specially crafted log message to a vulnerable system, and when Log4j tries to resolve these URLs, it will connect to the attacker’s LDAP server and execute the malicious payload. This payload can be anything the attacker wants, from a simple “shutdown -r” command, to more complex code that allows the attacker to gain control of the targeted system.

How to detect the Log4Shell vulnerability?

Log4Shell deserves the full attention of organizations and developers, and now that some time has passed and it’s been better understood, there are effective ways to detect Log4j vulnerabilities. The very useful scanning tools can discover them by going through a system and looking for known Log4j vulnerabilities. There are even tools, some free, designed to look for Log4j vulnerabilities, like Palantir’s Log4j-sniffer and the CERT Coordination Center’s scanner, among other options. Fluid Attacks offers its software composition analysis (SCA) technique, which scans for and discovers cybersecurity risks related to open-source and third-party components, including Log4j (start a 21-day free trial and discover this testing technique). Tools and techniques facilitate the task, but security teams, like ethical hackers or pentesters, could go beyond automated scanning tools due to Log4Shell hiding deep in dependency chains, which with a more hands-on method like pentesting, can be targeted with greater efficiency.

Manual testing is executed by ethical hackers or pentesters who are more than capable of looking for deeply hidden Log4Shell, and they can help their cause with tools like Apache Maven in order to generate dependency trees to map all of an application's dependencies. Other useful guidelines are the Cybersecurity and Infrastructure Security Agency’s (CISA) Apache Log4j vulnerability guidance and the list of software known to be affected by Log4Shell.

How to fix Log4j vulnerability?

Remediating or mitigating the Log4Shell vulnerability is the next logical step after detecting it, and depending on the circumstances, solutions can be applied. To remediate, one should update the Log4j library to a patched version that addresses the specific vulnerability. Upgrading to Log4j version 2.17.10 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6) will fix CVE-2021-44228 and other vulnerabilities. Checking the official Log4j website or security advisories can help find if a vulnerability exists in a specific version. After updating the Log4j library, the application’s Log4j configuration must be reviewed to ensure it follows the best practices for security. Removing unnecessary or excessive loggers could also help, as well as auditing the log message content to prevent the inclusion of untrusted or, what could be, malicious data.

In cases where upgrading to the newer version of the Log4j library is not a possibility, learning how to mitigate the vulnerability is the best bet:

  • Disable JNDI message lookups in vulnerable applications. By manually disallowing message lookup substitutions in the Log4j configuration, it will prevent successful RCE by the attacker.

  • Use a web application firewall (WAF) to block malicious traffic, which helps block usual used protocols like RMI or LDAP. IP addresses linked to attacks should also be blocked as soon as they are identified.

  • Implement monitoring and detection mechanisms to identify suspicious or malicious log messages. It should also include the monitoring of unusual activity, such as new processes or files being created, or changes to system configurations.

A single-pane of glass in which vulnerabilities can be managed goes a long way. A strategically organized platform that assesses risk exposure, promotes and controls the remediation procedure, checks the progress and status of a system’s security, provides up-to-date reports, and offers support via live chat. It’s not too much to ask because here at Fluid Attacks it’s exactly what we offer. Our platform, where our vulnerability management solution solution comes to life, can effectively help in situations when Log4Shell is present and in many more.

It’s important to keep in mind that Log4j vulnerabilities may be discovered over time, so it’s essential to stay informed about the latest security advisories and the best practices for securing applications.

We recommend our clients review this remediation guideline to comprehend how to prevent log injections.

Managing vulnerabilities with Fluid Attacks

You need to keep your open-source dependencies safeguarded. But knowing which applications use Log4j and are therefore vulnerable is a time-consuming task. We help you solve this issue quickly and with accuracy. The combination of advanced scanning software and our ethical hacking team improves the identification and report of issues like Log4shell or other zero-day vulnerabilities. That is a part of Fluid Attacks' vulnerability management solution, which, after vulnerability detection, makes it easier for clients to review, categorize and prioritize data, making it possible for everyone involved to remediate vulnerabilities faster. One of the benefits we offer with our Continuous Hacking is that our clients can test their applications constantly, and are therefore aware if they’re using a third-party library that has a recently known vulnerability.

Contact us now to get started with our solutions and take advantage of our Advanced plan that will ensure an extra edge in the protection against cyberattacks.


Start your 21-day free trial

Discover the benefits of our Continuous Hacking solution, which hundreds of organizations are already enjoying.

Start your 21-day free trial
Fluid Logo Footer

Hacking software for over 20 years

Fluid Attacks tests applications and other systems, covering all software development stages. Our team assists clients in quickly identifying and managing vulnerabilities to reduce the risk of incidents and deploy secure technology.

Copyright © 0 Fluid Attacks. We hack your software. All rights reserved.