Broad Exposure to Log4shell CVE-2021-44228 Highlights How the Attack Surface Has Exploded
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:
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:
- Bundled with several third-party software and custom-built applications. E.g. Log4j is very commonly used in conjunction with Apache Struts
- 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.
- 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:
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:
- “Installed Software” – “equals” – “Log4J.”
- 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.
*** This is a Security Bloggers Network syndicated blog from Blog – Balbix authored by Vinay Sridhara. Read the original post at: https://www.balbix.com/blog/broad-exposure-to-log4shell-cve-2021-44228-highlights-how-the-attack-surface-has-exploded/