A Zero Day vulnerability exploit in the popular Java logging library log4j (version 2) was discovered that results in Remote Code Execution (RCE) by logging a certain string.
Given how ubiquitous this log4j library is, the impact of the exploit is quite severe, it gives full server control, and it is so easy to exploit this vulnerability.
This zero day vulnerability exploitation is called "Log4Shell" in short.
A critical remote code execution vulnerability in the popular Apache Foundation Log4j library has been disclosed. It could allow an attacker to completely take control of an affected server. It can be leveraged in default configurations by an unauthenticated remote attacker to target applications that make use of the Log4j library. This vulnerability, tracked as CVE-2021-44228, received a CVSS severity score of a maximum 10.0, and is currently exploited in the wild by cyber attackers.
Apache Foundation Log4j is a logging library designed to replace the built-in log4j package. It is often used in popular Java projects, such as Apache Struts 2 and Apache Solr.
This vulnerability exists in the JNDI component of the LDAP connector, which allows an attacker to retrieve a payload from a remote server and execute it locally. Several proofs-of-concept and vulnerability walkthroughs have already been published. This vulnerability can be triggered to retrieve and execute a malicious class file. The vulnerability resides in the Java Naming and Directory Interface (JNDI) implementation and can be triggered using an LDAP request like the example below.
The bug find has been credited to Chen Zhaojun of Alibaba. It’s been assigned the maximum CVSS score of 10, given how relatively easy it is to exploit, attackers’ ability to seize control of targeted servers and the ubiquity of Log4j.
Because Log4j is included in a number of web applications and used by a variety of cloud services, the full scope of this vulnerability won’t be known for some time. However, at the time this blog post was published, some products and services that were confirmed to be vulnerable include:
Apache has released an updated version, Log4j 2.15.0. We encourages all customers to investigate their internal and third-party usage of Log4j for vulnerable configurations and take remediation actions. If you are uncertain or unable to determine if your implementation is vulnerable, patch aggressively.
If it's not possible to update them, the Apache Foundation recommends the following mitigations:
Organizations that don’t have an effective security tool to scan and monitor this vulnerability exploitation can sign up for a free trial of AlienVault USM.