Source:
Chris Markwell - SOC Engineering Team Lead, Satisnet
CVE: CVE-2021-44228
Severity: Emergency
CVSS 3.0: CVE-2021-44228 : 9.8/10
Background
Apache Log4j2 is a Java-based logging tool. This tool rewrites the Log4j framework and introduces a lot of rich features.
On November 24, 2021, the Alibaba Cloud security team officially reported an Apache Log4j2 remote code execution vulnerability to Apache.
An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
Log4j is incorporated into a host of popular frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink and others. That means that a dizzying number of third-party apps may also be vulnerable to exploits that carry the same critical severity.
Proof-of-concept are available.
Threat actors are already scanning the Internet (https://twitter.com/bad_packets/status/1469225135504650240) for systems vulnerable. Due to the ease of exploitation and the breadth of applicability, we suspect ransomware actors to begin leveraging this vulnerability immediately.
Please refer to the following github page for the Log4J Attack surface: https://github.com/YfryTchsGD/Log4jAttackSurface/blob/master/README.md
Affected Version(s)
All versions from 2.0-beta9 to 2.14.1.
From log4j 2.15.0, this behaviour has been disabled by default.
Plus, you need to check whether the Java application has introduced two jars, log4j-api and log4j-core.
If there is application usage, it is likely to be affected.
Mitigations
If you are using version 2.10.0 you can set a property called formatMsgNoLookups to true to prevent lookups. This can be passed as a parameter, too.
For older versions you will need to modify logging patterns as specified here: https://issues.apache.org/jira/browse/LOG4J2-2109
Plus, note that Java 8u121 (https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Patch for this vulnerability is available on github: https://cybereason.com/blog/cybereason-releases-vaccine-to-prevent-exploitation-of-apache-log4shell-vulnerability-cve-2021-44228
We strongly encourage those who manage environments containing Log4j to update to the latest version.
Patches
Apache published a Log4j release candidate version (2.15.0-rc1), likely containing a fix for this flaw, security researchers already discovered a bypass. So, upgrade all related applications of Apache Log4j2 to the latest log4j-2.15.0-rc2 version.
At the same, upgrade the applications and components that are known to be affected, such as spring-boot-strater-log4j2, Apache Druid, Apache Flink, Apache Solr, Apache Struts, Apache Tomcat, IBM Websphere, Elastic products
It also goes without saying that prioritised patching across the network is also advised as vendors are rolling out patches by the minute.
References and Additional Information
Comments