Exploits Swirling for Major Security Defect in Apache Log4j
Enterprise security response teams are bracing for a hectic weekend as public exploits — and in-the-wild attacks — circulate for a gaping code execution hole in the widely used Apache Log4j utility.
The remote code execution flaw is already being exploited to compromise Minecraft servers but, with such a massive attack surface at organizations around the world, experts warn that widespread exploitation is inevitable.
The vulnerability, flagged as CVE-2021-44228, was first discovered and reported by the Alibaba cloud security team on November 24 this year. Less than two weeks later, exploitation was spotted in the wild and prompted the release of a high-priority patch.
The open-source Apache Foundation released an advisory to warn of the critical nature of the issue and notes that all versions from Log4j 2.0-beta9 to 2.14.1 are affected.
The raw details from the Apache advisory:
Descripton: Apache Log4j2 <=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 messages 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.
Mitigation: In previous releases (>=2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 protects against RCE by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”.
Because the Log4j Java logging framework is deployed at internet infrastructure at thousands of major organizations (here’s a tracker of the expanding attack surface), there is growing urgency to stand up an emergency response organization to mitigate the issue.
Randori, a company that sells red-teaming services, says the vulnerability is reachable via a multitude of application specific methods. “Effectively, any scenario that allows a remote connection to supply arbitrary data that is written to log files by an application utilizing the Log4j library is susceptible to exploitation.”
“This vulnerability is highly likely to be exploited in the wild and is likely to impact thousands of organizations. This vulnerability poses a significant real world risk to affected systems,” Randori warned, noting that default installations of widely used enterprise software remain vulnerable.
“The vulnerability can be exploited reliably and without authentication,” Randori added.
The Alibaba research team that found the bug also confirmed that vulnerability exploitation does not require any special configurations.
“After verification by the Alibaba Cloud security team, Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc. are all affected,” the researchers said.
Related: GitHub Confirms Another Major NPM Security Defect
Related: Years Later, Hackers Still Target Apache Struts Flaw
Related: Critical Apache Struts 2 Flaw Allows Remote Code Execution
Ryan Naraine is Editor-at-Large at SecurityWeek and host of the popular Security Conversations podcast series. He is a journalist and cybersecurity strategist with more than 20 years experience covering IT security and technology trends.
Ryan has built security engagement programs at major global brands, including Intel Corp., Bishop Fox and Kaspersky GReAT. He is a co-founder of Threatpost and the global SAS conference series. Ryan’s career as a journalist includes bylines at major technology publications including Ziff Davis eWEEK, CBS Interactive’s ZDNet, PCMag and PC World.
Ryan is a director of the Security Tinkerers non-profit, and a regular speaker at security conferences around the world.
Follow Ryan on Twitter @ryanaraine.
Tags:
