What is it?
Log4j2 open source logging framework for Java is subject to a vulnerability which means untrusted input can result via LDAP, RMI and other JNDI endpoints in the loading and executing of arbitrary code from an untrusted source.
CrowdStrike has identified exploitation of log4j vulnerability by threat actors that more closely resembles targeted intrusion consistent with advanced attackers, such as deploying web shells and conducting lateral movement.
The vulnerability impacting Apache Log4j versions 2.0 through 2.14.1 was disclosed on December 9, 2021. The flaw has been dubbed “Log4Shell,”, and has the highest possible severity rating of 10.
Where is it used?
Log4j 2 is an open-source Java logging library developed by the Apache Foundation. It is widely used in many applications and is present in many services as a dependency. This includes enterprise applications , including custom applications developed within an organisation, as well as numerous cloud services.
The Log4j 2 library is frequently used in enterprise Java software and is included in Apache frameworks including:
- Apache Struts2
- Apache Solr
- Apache Druid
- Apache Flink
- Apache Swift
Other large projects Including Netty, MyBatis and the Spring Framework also make use of the library.
An application which consumes untrusted user input and passes this to a vulnerable version of the Log4j logging library may also be exploited.
Version 1 of the Log4j library is no longer supported and is affected by multiple security vulnerabilities. Developers should migrate to the latest version of Log4j 2.
What do we need to do?
The NCSC recommends following vendor best practice advice in the mitigation of vulnerabilities. In the case of this vulnerability CVE-2021-44228, the most important aspect is to install the latest updates as soon as practicable:
- If you are using the Log4j 2 library as a dependency within an application you have developed, ensure you update to version 2.15.0 or later
- If you are using an affected third-party application, ensure you keep the product updated to the latest version
- The flaw can also be mitigated in previous releases (2.10 and later) by setting system property “log4j2.formatMsgNoLookups” to “true” or removing the JndiLookup class from the classpath
What are Consider IT doing?
We’re currently working our way through all supported endpoints to verify whether they are affected or not. For those with a remediation available, we are applying it immediately. For any servers where remediation is not as easy and could cause other issues, we’ll be in touch in the next day or two (if we haven’t already contacted you over the weekend).
The really technical details
On versions (>= 2.10.0) of log4j that support the configuration FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS, this value is set to True disabling the lookup mechanism entirely. On older versions, the payload searches all existing LoggerContexts and removes the jndi key from the Interpolator used to process ${} fields.
Do not rely on a current Java version to save you. Update Log4 (or remove the JNDI lookup). Disable the expansion (seems a pretty bad idea anyways).
Mitigation
Other than patches it is possible to mitigate through configuration change.
For AWS WAF and CloudFront (be mindful of bypasses):
Finding vulnerable hosts:
JAR file hashes
Class file hashes (2.15.0 is not vulnerable but included)
JAR and Class hashes
Go vulnerability scanner using .class hashes
PowerShell
gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path
a highly parallel PowerShell from u/omrsafetyo :
Linux
find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}"
A set of YARA rules for detecting versions of log4j which are vulnerable to CVE-2021-44228 by looking for the signature of JndiManager prior to 2.15.0.
Log4j detector
Using Canary tokens to detect susceptibility
ActiveScan++ 1.0.23 added Log4Shell detection for Burp:
Online reflective vulnerability tester:
NMAP NSE:
