This is the MOST RECENT update to our previous research blog:
APACHE LOG4J REMOTE CODE EXECUTION – CVE-2021-44228
On December 9th the most critical zero-day exploit in recent years was disclosed, affecting most of the biggest enterprise companies. This critical 0-day exploit was discovered in the extremely popular Java logging library log4j which allows RCE (Remote code execution) by logging a certain payload.
The vulnerability was given the nickname “Log4Shell”, which has a CVSS (Common Vulnerability Scoring System) score of 10 – the highest risk possible and was published by GitHub advisory with a critical severity level.
EXPLOIT SCOPE
Log4Shell was being exploited for a few days before its public disclosure. Furthermore, log4shell scanning attempts were discovered up to two weeks beforehand. Attackers were able to install cryptominers, create botnets, and steal sensitive data and system credentials. As of today, it is estimated to have affected over a million machines.
RELEVANT CVES
Since its disclosure, and up to the creation of this article, five CVEs (Common Vulnerabilities and Exposures) concerning Log4j2 and Log4j1 were published:
LOG4J2: CVE-2021-44228
Log4j2 versions 2.0-beta9 through 2.15.0 (excluding 2.12.x after 2.12.1) are vulnerable to remote code execution using its LDAP (Lightweight Directory Access Protocol) JNDI parser. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. The initial vulnerability designated CVE-2021-44228 was supposedly fixed in versions 2.12.2 and 2.15.0. The fix includes disabling JNDI by default and by restricting LDAP access via JNDI in log4j2’s named object lookup and JNDI manager
This vulnerability has received the highest CVSS score possible – 10 and it affects the following packages, which are available through Maven Package Manager:
- org.apache.logging.log4j:log4j-api
- org.apache.logging.log4j:log4j-core
notes – The vulnerability itself is in log4j-core. The Logger class itself, which is used to trigger the exploit, as used in POCs (proof of concept) by calling Logger.error(), is defined in log4j-api. To detect such a usage with the exploitable path, and to secure our customers as much as possible, we added the Logger’s methods as vulnerable methods (which eventually trigger the vulnerability according to the research). This approach is reflected in Github’s Advisory page for this vulnerability.
LOG4J2: CVE-2021-45046
On December 11th, 2021, it was discovered that CVE-2021-44228’s fix was incomplete in certain non-default configurations, which could allow attackers with specifically crafted malicious input data using a JNDI lookup pattern resulting in information leak and RCE in some environments and LCE (Local Code Execution) in all environments. RCE is also possible in some macOS environments. This complementary vulnerability was designated CVE-2021-45046 and was fixed in versions 2.12.2 and 2.16.0 by disabling JNDI by default, and by removing message Lookup.
As this vulnerability was initially regarded as allowing for only DOS (Denial of Service) attacks, the CVSS score assigned for this vulnerability was 3.7. Since it was later discovered as a much more severe threat (RCE), the CVSS score was raised to 9.0.
This vulnerability is an extension of CVE-2021-44228, thus the affected packages are the same.
Mitigation options for CVE-2021-44228 and CVE-2021-45046:
- Users requiring Java 8 (or later) should upgrade to release 2.16.0 or above.
- Users requiring Java 7 should upgrade to release 2.12.2 or above.
- Remove the JndiLookup class from the classpath:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
LOG4J2: CVE-2021-45105
It was discovered on December 15th, 2021, that log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.x from 2.12.3) is vulnerable to DOS attacks, since it does not protect from uncontrolled infinite recursion of self-referential lookups. These in turn result in a Stack Overflow error that will terminate the process. This vulnerability was published at NVD on December 18th, 2021, under CVE-2021-45105 and was fixed in version 2.17.0 by fixing string substitution recursion and limiting JNDI to only java protocol. According to GitHub Advisory and previous fixes for log4Shell’s variants, the fix for Java7 users should be released in upcoming version 2.12.3. The CVSS score assigned to it by Apache is 5.9.
Mitigation options for CVE-2021-45105
- Users requiring Java 8 (or later) should upgrade to release 2.17.0 or above.
- Users requiring Java 7 should upgrade to release 2.12.3 or above.
- Users requiring Java 6 should upgrade to release 2.3.1 or above.
- In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
- in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.
LOG4J2: CVE-2021-44832
The Checkmarx Security Research Team publicly disclosed a new vulnerability they recently discovered on December 28th, 2021. This vulnerability allows for ACE (Arbitrary Code Execution) in versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4).
When an attacker gains control over the logging configuration (via MITM attack since there is a feature to load a remote config file in log4j) can construct a malicious configuration using JDBC Appender with a data source referencing a JNDI URI, which can then execute remote code.
This vulnerability was fixed in version 2.17.1 by limiting JNDI data source names to the java protocol and it was assigned the CVSS score of – 6.6, a slightly lower severity score because it is more complex to exploit than previous log4Shell variants. CVE-2021- 44832 solely affects the log4j-core package.
Mitigation options for CVE-2021-44832
- Users requiring Java 8 (or later) should upgrade to release 2.17.1 or above.
- Users requiring Java 7 should upgrade to release 2.12.4 or above.
- Users requiring Java 6 should upgrade to release 2.3.2 or above.
- In Prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.
Important note for log4j2 vulnerabilities: only the log4j-core JAR file is impacted by these vulnerabilities. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted. Apache Log4j is the only Logging Services subproject affected. Other projects like Log4net and Log4cxx are not impacted by these vulnerabilities.
LOG4J1: CVE-2021-4104
Disclosed on December 13th, 2021, and published on December 14th, 2021, on NVD under CVE-2021-4104, it was discovered that log4j1 was also vulnerable for log4Shell vulnerability – previously believed to only affect log4j2.
The root cause of this vulnerability is in the org.apache.log4j.net.JMSAppender class that is vulnerable to deserialization of untrusted data when the attacker has Write access to the Log4j configuration. The attacker can provide malicious payloads to the configuration parameters causing JMSAppender to perform JNDI requests that result in remote code execution. This affects non default configurations of Log4j 1.2 since the JMSAppender configuration is disabled by default.
The CVSS score assigned for this vulnerability is 6.6, which is lower than CVE-2021-44228 since attacker must have write access to log4j configuration to exploit.
The vulnerability affects the log4j:log4j package, which is available through Maven Package Manager:
Mitigation options for CVE-2021-4104:
- Users should upgrade to Log4j2, either 2.12.4, 2.3.2, 2.17.1, or above, as it addresses numerous other issues from the previous versions.
- Ensure to not expose to untrusted callers any mechanism that might allow access to JMSAppender class or make any changes and configuration to instances of it.
- Comment out or delete the JMSAppender in log4j configuration if it is used
- Delete the JMSAppender classpath:
zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class
Important note: Apache Log4j 1.2 reached end of life in August 2015.
Detecting Log4Shell with Checkmarx SCA
Checkmarx SCA provides fast and easy detection of the above mentioned Log4Shell vulnerabilities in open source dependencies. The following screenshots display our SCA scan results of code with vulnerable 3rd party dependencies.
Figure 1 – SCA’s overview page, with a list of detected packages and risks
Today, it’s clear. Software Composition Analysis (SCA) solutions are a requirement for organizations that consume open source software. Checkmarx SCA enables your organization to address open-source security issues earlier in the SDLC to identify and manage risk more effectively.
To learn more about Checkmarx SCA, you can request a live demo here, or download our Ultimate Guide to SCA here.