Apache Log4j Vulnerability Called Log4Shell Actively Exploited | What you need to know

Apache Log4j Vulnerability Called Log4Shell Actively Exploited | What you need to know | Log4j (CVE-2021-44228) RCE Vulnerability Explained

The vulnerability is largely being called 'Log4Shell’ or LogJam and the name of the Java logging system where it has been found is 'log4j2'. It is referred to as a zero-day vulnerability as bad actors or hackers might have known about it before it was discovered by researchers and experts around the world. Additionally, it might have been exploited without any record or information, making it even more dangerous. 

Affected applications include Elastic Search, Elastic LogStash, GrayLog2, Minecraft (client and server), Neo4J, many Apache projects (Druid, Dubbo, Flink, Flume, Hadoop, Kafka, Solr, Spark, Struts, Tapestry, Wicket), many VMware products (Horizon, vCenter, vRealize, HCX, NSX-T, UAG, Tanzu), Grails, and dozens if not hundreds of others. Log4J versions since 2.0 are reported to contain this vulnerability, which was originally disclosed to Apache several weeks ago by the security team at Alibaba Cloud.

Log4J is commonly used in servers and development frameworks. In the last four months, Log4j has been downloaded more than 84 million times. Many of the Java projects maintained by the ASF use Log4J for logging, such as the popular Apache Struts project. Given the popularity of Log4J and Apache's projects, the list of organizations with vulnerable applications is staggering and includes organizations such as Apple, Twitter, Amazon, and ElasticSearch. Organizations may not even know they are running Log4j as it may be used by a third-party framework or toolset.

This particular vulnerability lies in Log4J's handling of JNDI (Java Naming and Directory Interface) and a service such as LDAP. JNDI allows Java to access naming and directory services, such as LDAP, DNS, and RMI. Most importantly, JNDI can be used in conjunction with LDAP to retrieve an object containing directory service information needed by a Java program, even if the object resides on a different machine. Log4J recently added support for JNDI property substitution in logging statements. This means that if an attacker can send a JNDI command that Log4J will log, it will be executed.

MITIGATION:
In terms of remediation, the first step is to scan your applications to check whether you are using vulnerable Log4j versions 2.14.1 or under. If a vulnerable version is detected, update to fixed version 2.15.0 to avoid an exploit.

Patches are also now available to prevent code execution (Log4J version 2.15.0), but these patches do not disable inline message lookup, which can expose things like environment variables and system configuration settings to an attacker that can observe the generated logs.

For mitigations that folks can take immediately, Apache has offered some guidance.
For Log4J versions 2.10 and newer, the lookup functionality can be disabled three ways:
By setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true at the process level.

For older Log4J releases (2.0-beta9 to 2.10.0), mitigating this issue requires removal of the JndiLookup class from the jars in the classpath: