Broad Exposure to Log4shell CVE-2021-44228 Highlights How the Attack Surface Has Exploded

Update – December 20, 2021 9:30 AM PT

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.

The reason for the increase in criticality for CVE-2021-45046 is the discovery of a new, more dangerous attack vector that enables attackers to exploit Log4shell on servers locally using a JavaScript WebSocket connection. This can result in information leak and remote code execution in some environments and local code execution in all environments. We also still 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, however this will not provide protection against the newly discovered CVE-2021-45105.

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.

——————————————————————–

Update – December 15, 2021 11:00 AM PT

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.”

What is Log4j – How is it used?

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:

• Loggers: Capture logging information
• Appenders: Publish logging information to subscribers and configured destinations
• Layouts: Formats logging information

Additional information on the Log4j architecture and application can be found here:

• https://logging.apache.org/log4j/2.x/
• https://logging.apache.org/log4j/1.2/faq.html

What is Log4shell – CVE-2021-44228?

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:

• It is classified by NIST as a vulnerability allowing improper input validation.
• It is classified as a Common Weakness Enumeration under CWE-20.
• According to JNDI (Java Naming and Directory Interface), Log4j “lookup” commands wrapped in ${…} sequences can do live runtime lookups to arbitrary servers, both inside and outside the network.
• Apache describes the vulnerability as follows: “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,” and notes that, “from log4j 2.15.0, this behavior has been disabled by default.”

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.

What software is affected by this vulnerability?

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:

1. Bundled with several third-party software and custom-built applications. E.g. Log4j is very commonly used in conjunction with Apache Struts
2. Heavily used Java components and development frameworks that are dependent on the Log4j logging framework including, but not limited to, Apache Struts2, Apache Solr, Apache Druid, Apache Flink, ElasticSearch, etc.
3. Custom applications that are built using Java typically use Log4j as the default framework for logging

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:

Sources:

• https://kb.vmware.com/s/article/87068
• https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
• https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
• https://access.redhat.com/security/cve/cve-2021-44228
• https://ubuntu.com/security/CVE-2021-44228

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).

I’m a Balbix customer, how do I search for affected assets?

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:

1. “Installed Software” – “equals” – “Log4J.”
2. Filter the version(s) for anything 2.0.0 or later.

How do I remediate my systems?

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:

• In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. Also, disable Log4J Lookups. Setting the system property “log4j2.formatMsgNoLookups” to “true”

How do I look for exploitation attempts?

While remediating systems, security teams should also look for any exploitation attempts, starting with internet facing servers.

• For uncompressed folders: /var/log and all sub folders:
  • sudo egrep -I -i -r ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+’ /var/log

• For compressed folders: /var/log and all sub folders:
  • sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+’

Source: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

What about Log4j 1.x?

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.

What has Balbix done to protect its systems?

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.