Log4j - 0 day vulnerability

Update on December 15, 2021: ReversingLabs is aware of a second CVE for log4j, CVE-2021-45046. Because our remediation removes the class from the JAR in addition to setting the command-line option, we are not susceptible to this new vulnerability and no action is required if the remediation steps below have been applied.

A zero-day vulnerability in the Apache Log4j utility (CVE-2021-44228) was made public on December 9, 2021 which can be easily exploited to perform remote code execution. Log4j version 2.x is susceptible to the vulnerability.

From Log4j CVEs detail: “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 impact from this vulnerability is very widespread. Threat actors are actively engaged in mass Internet scanning to identify servers vulnerable to exploitation. 

ReversingLabs is actively investigating the potential risks posed by this vulnerability to customers using our products and services. 

ReversingLabs has identified:

*A1000 version <6.1 is not susceptible to the Log4j vulnerability as it’s using log4j version 1.x.

A1000 v6.1 can be, under certain circumstances, susceptible to the Log4j vulnerability as log4j was upgraded to 2.x version.

Steps taken for A1000 instances hosted by ReversingLabs

ReversingLabs immediately (morning of December 10th) mitigated the Log4j vulnerability on all hosts, including all hosted A1000 instances. Furthermore, investigation showed that vulnerability can be used only in certain circumstances (e.g. having an authenticated session on the A1000).

As of December 13, 2021, ReversingLabs has observed no indicators of compromise in the environment.

Remedies for on premise deployed instances

Only A1000 version 6.1. is vulnerable to Log4j. You can check the version by identifying the version at the bottom of the A1000 screen.

To mitigate the vulnerability, please perform the following steps in a shell on the A1000:

1. Removal of the JndiLookup.class from the vulnerable log4j-core libraries

$ zip -q -d /usr/share/solr7/server/lib/ext/log4j-core-2.11.0.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

$ zip -q -d /usr/share/solr7/contrib/prometheus-exporter/lib/log4j-core-2.11.0.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

2. Setting the -Dlog4j2.formatMsgNoLookups=true parameter

$ echo 'SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"' >> /etc/sysconfig/solr7

$ systemctl restart solr7

3. Updating the configuration template to preserve the configuration change

$ echo 'SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"' >> /opt/tcbase/install/templates/etc/sysconfig/solr7

TitaniumCloud 

ReversingLabs security team performed security analysis and determined that there is low exposure, there aren’t any external facing services using Log4j. Compensating controls have been implemented on the internal systems that use Log4j.