Responding to Log4Shell vulnerability

Background

On December 9th 2021, a critical vulnerability was identified in Apache Log4j, a popular Java logging library.

The vulnerability (CVE-2021-44228), also referred to as Log4Shell, is affecting all Log4j2 versions prior to 2.15.0.

IMPORTANT UPDATE (15/12/2021):

A second vulnerability (CVE-2021-45046) has been discovered. Log4J versions below 2.16.0 are subject to a Denial of Service vulnerability, even when the -Dlog4j2.formatMsgNoLookups=true or LOG4J_FORMAT_MSG_NO_LOOKUPS was set to mitigate the previous vulnerability (CVE-2021-44228). Both vulnerabilities can be mitigated by following our updated mitigation steps below.

IMPORTANT UPDATE (17/12/2021):

The second vulnerability (CVE-2021-45046) has been upgraded from a CVSS score of 3.7 (limited DoS) to a CVSS score of 9.0 (limited RCE). The mitigation steps below are still sufficient.

IMPORTANT UPDATE (18/12/2021):

A third vulnerability (CVE-2021-45105), causing Denial of Service, has been found (CVSS score of 7.5), the Apache Software Foundation has released Log4j 2.17.0. The mitigation steps below are still sufficient.

UPDATE (20/12/2021):

Elasticsearch has released version 6.8.22 that updates Log4j to 2.17.0, fully mitigating the vulnerabilities. More information about updating Elasticsearch can be found here.

DataMiner impact

While DataMiner itself does not rely on Log4j, some databases used with DataMiner, i.e. Elasticsearch databases, may be affected. Cassandra databases are not affected.

DataMiner is typically deployed with Elasticsearch version 6.8.X. You can verify this by browsing to “http://<your elastic IP>:9200/”.

We strongly encourage users running Elastic 6.X to follow the steps mentioned in the Mitigation section below to mitigate the vulnerability.

Elasticsearch version 7.2 or higher, bundled with JDK11 or higher, is not affected by this vulnerability and requires no extra steps. You can verify your Java version by executing “java -version“.

Elasticsearch versions deployed with Java 8 are subject to an information leak vulnerability. If you use such a version, you can disable the vulnerability by executing the steps in the Mitigation section below.

For more information, see Zero-day-exploit in log4j2 which is part of elasticsearch.

Mitigation

Please be advised that the previously published mitigation steps are no longer sufficient as they do not mitigate the newly discovered vulnerability.

UPDATED STEPS (15/12/2021):

Both vulnerabilities can be mitigated by removing org/apache/logging/log4j/core/lookup/JndiLookup.class from the log4j-core-*.jar file. This file can be found in C:\Program Files\Elasticsearch\lib on Windows and in /usr/share/elasticsearch/lib/ on Linux.

Follow the updated steps to mitigate both vulnerabilities:

1. Locate your log4j-core-*.jar file
2. Make a copy of the file
3. Extract the .jar file
4. Remove org/apache/logging/log4j/core/lookup/JndiLookup.class from the extracted archive
5. Recreate the .jar archive
6. Shut down Elasticsearch, replace the original log4j-core*.jar file and delete the copy
7. Start your Elasticsearch again

The vulnerability should be mitigated after you restart both the Elastic service and your DataMiner application.

Note: Updating to Elasticsearch 6.8.22 should mitigate all vulnerabilities as well. More information about updating your Elasticsearch can be found here.

For more information see: Introducing Elasticsearch 6.8.22 release.

We encourage users to scan their entire infrastructure and application stack for vulnerable apps/devices. A list of affected vendors can be found on github.

For any further questions or concerns, please contact infosec@skyline.be.