On December 10, 2021, cyberspace got flooded with a critical vulnerability in the popular java-based logging package log4j. The vulnerability is now called Log4Shell and published as CVE-2021-44228 with a CVSS v3 score of 10 - which is already the highest risk score. The vulnerability, if exploited, could allow attackers to obtain remote code execution (RCE), thus providing them an opportunity to execute arbitrary commands on the remote server.
This blog post aims to share details and the required workaround to understand the log4j2 vulnerability (CVE-2021-44228). Currently, the critical vulnerability is exploited in the wild, and bad actors are actively scanning cyberspace for vulnerable assets.
Apache log4j is also used in many frameworks such as Apache Struts 2, Apache Druid, Apache Flink. Spring and Spring Boot applications are only vulnerable to the flaw in case they have switched the default logging system to Log4j2.
The patch to fix the vulnerability was released earlier in v2.15.0 but later on, it was disclosed that the fix had some vulnerability traced to (CVE-2021-45046) with CVSS score 3.7 which existed due to incertain non-default configurations.
As soon as the flaw was discovered in v2.15.0, a new patch update of log4j v2.16.0 was promptly released by Apache. But later on, v2.16.0 was found vulnerable to CVE-2021-45105, DoS attack. Consequently, Apache has released another patch update v2.17.0 to mitigate the new vulnerability in v2.16.0.
If you use Java-based products that use log4j, you should do the remediation as soon as possible to mitigate the risk.
Log4j is a Java-based logging framework (APIs) distributed under the Apache Software License. Today, it is being used in a wide range of cloud services, enterprise applications, tools, and frameworks such as Apache Struts 2, Apache Druid, Apache Flink, etc.
Log4j uses multiple lookup plugins to access various information. Back in 2013, the log4j version 2.0-beta9 added the JNDILookup plugin to its framework. The JNDI (Java Naming and Directory Interface) is a directory service that allows Java programs to find Java objects through a directory such as LDAP (Lightweight Directory Access Protocol), and it has been present in Java since the late 1990s. At the same time, Lookups provide a way to add values to the Log4j configuration at arbitrary places.
Most of the time, the plugins do not create any insufficient scenarios as the obtained values are stored in the application log and usually not displayed. However, in the case of this vulnerable version of log4j, the attacker can call the information and log it while using the JNDI to connect to an instance using an LDAP URL and log it.
Once the attacker knows the input is logged with log4j, he can set up an LDAP server and return a compiled class file to execute malicious code on the remote system; this attack can be further stealthy by hiding the input in the HTTP call header since they are often logged by the app servers using log4j.
Here’s to remember that the attacker only needs to trigger a log event that contains a malicious string to exploit the vulnerability and once it is done, it would allow an attacker to remotely execute codes on the server.
The flaw was triggered because the message lookup substitution was enabled, allowing the attacker to control the log message or log parameters. The simplest way to remediate the vulnerability was to upgrade to the log4j v2.15.0, which then by default, disable the lookup behavior. CVE-2021-4428 affected the log4j version 2.0-beta9 and <= 2.14.1 and was patched by the maintainers in the log4j 2.15.0 update.
However, on December 14, 2021, it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. The previous mitigations involve configuration such as setting the system property log4j2.formatMsgNoLookups to true, but in the case of v2.15.0 update, it does not mitigate this specific vulnerability i.e., CVE-2021-45046 entirely.
The flaw in the v2.15.0 could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Content Lookup (for example, {ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or%MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.
As soon as v2.16.0 was released and become available to remediate the missing security countermeasure in v2.15.0, independent security researchers discovered that Apache log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. The vulnerability was immediately traced to CVE-2021-45105 with CVSS 7.5 and high severity, which could allow attackers to trigger a Denial of Service (DoS) attack.
Though the JNDI lookups were previously disabled in the v2.16.0, however, under certain circumstances the previous version can be fed patterns that are infinitely recursive.
As published by Apache, “when the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, {ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.”
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
find / -name "*log4j*2*"
to identify if vulnerable version of log4j is in use.