December 14, 2021
We are providing you additional updates on CVE-2021-44228, CVE-2021-4104 and CVE-2021-45046, and now CVE-2021-45105 related to Log4j.
A new vulnerability, CVE-2021-45105 was discovered on Friday, December 17th in the Apache logging framework, log4j. CVE-2021-45105 is a denial of service (DoS) vulnerability that affects all versions of Log4J from 2.0 up through 2.16.0. This latest flaw received a CVSS score of 7.5, making it a high priority fix and is addressed in version 2.17.0 of Log4J.
On Friday, December 17th additional information was released about the severity of CVE-2021-45046, as well as an additional security patch for Log4J itself. The CVSS score for CVE-2021-45046 released earlier this week has increased from 3.7 to 9.0, making it now a critical severity.
Balbix strongly recommends that organizations upgrade to version 2.17.0 (for users of Java 8.0 or later) as soon as possible, as version 2.16 does not protect against CVE-2021-45105. Version 2.17.0 will address all reported vulnerabilities to date including CVE-2021-45046 and CVE-2021-45105.
Earlier today, CISA updated its guidance regarding log4j, noting that “on December 13, 2021, Apache released Log4j version 2.16.0 in a security update to address the CVE-2021-45046 vulnerability. A remote attacker can exploit this second vulnerability Log4j to cause a denial-of-service (DOS) condition in certain non-default configurations,” and furthermore that, “affected organizations that have already upgraded to Log4j 2.15.0 will need to upgrade to Log4j 2.16.0 to be protected against both CVE-2021-44228 and CVE-2021-45046.
We recommend that organizations upgrade to version 2.16.0 (for users of Java 8.0 or later) as version 2.15 is incomplete. While the second vulnerability, CVE-2021-45046, is only rated 3.7 out of a maximum of 10 on the CVSS rating system, it does affect all 2.x versions of Log4j, including version 2.15. This vulnerability can be used “to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack,” according to Apache. We also recommend disabling the JNDI class lookup if your application permits as doing so is proving to be an effective short term mitigation strategy for CVE-2021-45046.
The critical vulnerability CVE-2021-44228 was found in the Java logging library Log4j versions 2.0 to 2.14.1. An exploit known as “Log4shell” was publicly disclosed on December 9th and is being actively exploited in the wild. It is highly recommended this flaw be patched as soon as possible.
In the first few days since the exploit was made public, it has become clear that many organizations face some stiff challenges remediating this vulnerability in a timely manner. Log4j is used in many different systems, and is often buried beneath layers of applications. There are also different paths to remediation depending on the version of 2.x deployed (and don’t forget about 1.x). The intent of this blog is to provide guidance to navigate these complexities and efficiently remediate this vulnerability.
In addition, the US federal government has also provided a timeline for remediation for its civilian agencies. According to CISA, “In accordance with BOD 22-01, federal civilian executive branch agencies must mitigate CVE-2021-44228 by December 24, 2021.”
Log4j is a logging framework written in Java, which is distributed under the Apache Software License. It is configurable through external configuration files at runtime.
Log4j views the logging process in terms of levels of priorities and offers mechanisms to direct logs to storage and analytical frameworks such as databases, files and syslog among others; and security tools such as SIEM. Log4j has three main components and functions:
Additional information on the Log4j architecture and application can be found here:
The exploitation of this vulnerability leads to RCE (Remote Code Execution) – This can lead to root access and complete control of the server.
Log4shell CVE-2021-44228 has been described by a number of bodies:
The only known exception is if the asset in question has a newer Java Runtime. For assets with Java Runtimes later than 8u121, the asset is not vulnerable to the exploit, however the vulnerability still exists.
The vulnerability impacts all versions of Log4j from 2.0-beta9 to 2.14.
To discover vulnerable Log4j instances, you need to search according to the 3 deployment scenarios below:
A list of affected Log4j 2 versions with md5sum can be found here.
The following list (not comprehensive) outlines commonly used applications that are potentially affected:
The Balbix research team also notes that there are several variants of Log4j that exist in our customer environments such as RHEL-specific versions, cloud-provider-specific versions, etc. These variants will be shown in the Balbix search results for Log4j along with the standard version and it is recommended that these variants be updated as well (given that a patch is available).
Balbix customers with the Balbix host analyzer (HA) installed can find affected assets on which Log4j has been installed directly via standard installers (Windows and OS X) or package managers (Linux) by performing a filtered search as follows:
The Swiss Government CERT has provided the following helpful diagram explaining the attack and remediation:
The primary means to remediate systems is to upgrade the Log4j to version 2.15 (latest version) where the application dependencies permit on all these assets. If upgrading is not possible, then ensure the system property log4j2.formatMsgNoLookupsis is set to “true” on both client- and server-side components.
From a prioritization standpoint, all internet facing servers that have Log4j 2 software like Apache Struts need to be fixed due to risk of RCE and the ability for the attacker to do lookups on arbitrary servers.
The mitigation steps vary by version. Apache provides the following guidance:
While remediating systems, security teams should also look for any exploitation attempts, starting with internet facing servers.
Don’t forget about version 1.x. Any version released prior to 2.0.0 (version 1.x) is an older version that is no longer maintained. We recommend that security teams take this opportunity to upgrade these versions of the software.
Fortunately, Log4j 1.x is not affected by CVE-2021-44228. According to one of the founders of the log4j projects: “Log4j 1.x does not offer a look up mechanism. Log4j 1.x sends an event encapsulating a string message to a JMS server. That is it. The attacker can supply whatever string he chooses but it remains a String. So not the same.”
However, since Log4j 1.x is no longer supported, and a bug related to Log4Shell, CVE-2021-4104 (CVSS 8.1), exists in this version (as pointed out by Red Hat), we recommend that security teams upgrade these instances.
Balbix has performed an extensive assessment of our platforms to determine whether our infrastructure is susceptible to CVE-2021-44228. Our investigation has validated that the Balbix infrastructure is not vulnerable to Log4shell.
As a best-practice countermeasure, we have deployed additional controls and mitigations to identify and block potential exploit attempts.
My team and I continue to monitor the situation.