Application Security

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.

<p><span><strong><span>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.</span></strong></span></p>

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

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.

Advertisement. Scroll to continue reading.

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

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version