Apache: Log4j Remote Code Execution (Log4Shell, CVE-2021-44228)
On December 9th, 2021, the security community became aware of active exploitation attempts of a vulnerability in Apache Log4j. The vulnerability, also known as “Log4Shell”, is trivially exploitable with the exploit code available in the public domain.
Log4j is a java- based logging utility used in many products. This includes Apache products like Struts, Solr, and Flink to security products like ElasticSearch, Logstash, and Kafka. Many applications can have a dependency on Log4j without it being expressly stated – meaning that identifying vulnerable applications may be challenging.
Apache have released a new version of Log4j, Log4j 2.15.0. which addresses the security vulnerability CVE-2021-44228.
At the time of writing, reports indicate that there have been exploit attempts that have led to commodity cryptominer payloads or other known and commodity post-exploitation methods in the wild.
We recommend that businesses investigate their potential exposure to this vulnerability with urgency and apply appropriate patching as quickly as possible if necessary.
- Apache Log4j2
- From version 2, up to and including version 2.14.
Apache Log4j <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log message contents or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar
It may not be immediately obvious where Log4j is being used in your environment as this component is used in a variety of products. This includes Apache products like Struts, Solr, and Flink to security products like ElasticSearch, Logstash, and Kafka.
The first step is to:
1. Find all code within your network that is written in Java, check whether it uses the Log4j library.
A resource that may help this is a community-sourced list of impacted applications and services https://github.com/YfryTchsGD/Log4jAttackSurface
Once you have identified all instances then:
2. Ensure that any out of date versions of Log4j are updated as soon as possible
Alternately, if it is not possible to update Log4j:
According to Apache’s 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.
Cygliant SOC is currently working in collaboration with our SIEM vendors to ensure all avenues of detection are covered in order to develop alert content for detection purposes.
- Actions taken based on the recommendations in this advisory are at your own discretion.
- The IOC-List (if provided) and other information is time-sensitive in nature and may be overridden in subsequent updates as new information is obtained