Alert: Apache Log4j vulnerabilities
The NCSC is advising organisations to take steps to mitigate the Apache Log4j vulnerabilities.
A number of vulnerabilities have been disclosed that affect multiple versions of Apache Log4j. Scanning and attempted exploitation has been detected globally, including in the UK. The NCSC is also aware of several cases where actors have exploited vulnerable instances of VMware Horizon, MobileIron and Ubiquiti Unifi Network Application (not an exhaustive list).
Proof-of-concept code has also been published for these vulnerabilities.
Further reading
As well as the technical guidance provided in this Alert, the NCSC suggests further reading:
Details
Log4j is an open-source Java logging library developed by the Apache Foundation. It is widely used in many applications and is present in many services as a dependency. This includes enterprise applications, including custom applications developed within an organisation, as well as numerous cloud services.
The Log4j library is frequently used in enterprise Java software and is included in Apache frameworks including: Apache Struts2, Apache Solr, Apache Druid, Apache Flink and Apache Swift. Other large projects including Netty, MyBatis and the Spring Framework also make use of the library.
In December 2021, a number of vulnerabilities were reported in Log4j:
- CVE-2021-44228 - referred to as the "Log4shell" vulnerability, affects Log4j versions 2.0-beta9 to 2.14.1. It allows remote code execution and information disclosure if exploited.
- CVE-2021-45046 - affects versions 2.0-beta9 to 2.15.0, excluding 2.12.2 and was originally reported as a Denial of Service when organisations are running a vulnerable non-standard configuration. Later research found that the same vulnerable configuration allowed a bypass of the mitigations to Log4shell, allowing remote code execution and information disclosure.
- CVE-2021-45105 - affects Log4j versions from 2.0-beta9 to 2.16.0 – A similar denial of service issue to CVE-2021-45046 when organisations are running a vulnerable non-standard configuration.
An application is impacted by these vulnerabilities if it consumes untrusted user input and passes this to a vulnerable version of the Log4j logging library.
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.
More information is available at:
Recommended priority actions
- 1
Install the latest updates immediately wherever Log4j is known to be used
This should be the first priority for all UK organisations using software that is known to include Log4j.Organisations should update both internet-facing and non-internet facing software.
The Log4j library is frequently used in software and the links below provide a non-exhaustive lists of vulnerable products:
- Github - CISA Log4j vulnerability guidance
- Github - NCSC-NL Log4j overview related software
- Mvnrepository - Artifacts using Apache Log4j Core
If your specific product is not listed, you can use the instructions provided below in Priority Action 2 to try and determine if Log4j is present. If your product is listed, please follow vendor advice on updating the software or applying mitigations. You should also keep refreshing the list in case a new product has been added.
If your product is not listed and is vulnerable, you can request it be added to the list.
Where a vendor has not provided an update to a product, the vulnerability can be mitigated by removing the JndiLookup class from the classpath. Care should be taken to ensure all instances of Log4j have been mitigated.
zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.classOrganisations should routinely run vulnerability scanning across their networks, to detect when updates are available.
- Github - CISA Log4j vulnerability guidance
- 2
Discover unknown instances of Log4j within your organisation
To support the first priority action above, you also should now determine if Log4j is installed elsewhere. Java applications can include all the dependent libraries within their installation.
A file system search for Log4j can be undertaken. This should include searching inside EAR, JAR and WAR files. For example:
find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null
If a dependency or package manager is used, this can be searched. For example:
dpkg -l | grep log4j
There could be multiple copies of Log4j present, each copy will need to be updated.
On Windows, this PowerShell command can identify nested Log4j:
gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path
- 3
Deploy protective network monitoring/blocking
The following recommendations should be taken to improve network monitoring and blocking:
- Organisations using Web Application Firewalls (WAFs) should ensure rules are available to protect against this vulnerability. These could include blocking URLs containing strings like "jndi:ldap". It should be noted that variants of the exploit string may bypass current WAF rules. This means WAFs should not be relied on as the only control.
- Organisations that understand normal outbound connections from their servers may wish to ensure they're blocking unexpected outbound connections (particularly LDAP, LDAPS and RMI, however exploits may work over arbitrary ports). Putting in place blocks without understanding necessary outbound connections may prevent exploitation, but may also cause services to fail to work if they require outbound connections.
- Organisations using Web Application Firewalls (WAFs) should ensure rules are available to protect against this vulnerability. These could include blocking URLs containing strings like "jndi:ldap". It should be noted that variants of the exploit string may bypass current WAF rules. This means WAFs should not be relied on as the only control.
Additional information
Advice to developers of affected software
It may not always be easy for organisations to identify which products use Apache Log4j software. If you are a developer of any affected software, the NCSC advises early communication with your customers to enable them to apply mitigations or install updates where they are available.
Detection guidance
The following recommendations will help assist in detection of potential malicious activity trying to exploit the Log4j vulnerability.
- Organisations with detection and threat intelligence functions should ensure they’re aware of the current payloads being delivered by exploitation attempts and searching for evidence of them.
- If your organisation is storing netflow data for your network’s internet connections, or you have robust EDR coverage of servers, you should search for internally initiated LDAP, LDAPS, RMI and DNS connections to external destinations not seen before 10 December 2021. This may indicate exploitation and if detected, you should search the initiating host for the presence of Log4j. DNS queries by the server around the suspicious connection should also be reviewed as sensitive information could have been exfiltrated over DNS.
- YARA rules for a variety of scenarios are available should organisations have the tooling to query using them: Log4j RCE Exploitation Detection
- The log files for any services using affected Log4j versions could contain user-controlled strings. For example, “jndi:ldap”.
NCSC tools, services and guidance
The NCSC provides a range of free tools, services and guidance that help to secure systems:
- Follow NCSC guidance including Preventing Lateral Movement
- Sign up for Early Warning
- Central government departments can take advantage of NCSC Host Based Capability
- Vulnerability Disclosure Toolkit – ensure organisations have at least a basic approach to receiving reports from researchers who might discover the presence of vulnerable Log4j systems.
Reporting a compromise
Affected UK organisations should report any evidence of compromise relating to this vulnerability to the NCSC via our website https://report.ncsc.gov.uk/
The NCSC is aware of widespread scanning for this vulnerability and we note that almost all organisations will have received HTTP requests with the JNDI string. We do not require reports of scanning activity. However please notify the NCSC of any cases where you have identified malicious Java being loaded into one of your systems, or where any follow-on activity has occurred.
Updates:
(13/01/22): Information on cases of known exploited services added, latest version type removed
(20/12/21): Alert re-structured - additional vulnerability detail added
(18/12/21): Addition of CVE-2021-45105, a Denial of Service in non-default configurations
(17/12/21): Upgrading of CVE-2021-45046 to a Remote Code Execution issue
(16/12/21): Addition of exploitation information and addition of Windows search string
(15/12/21): Minor updates to mitigation advice and information on CVE-2021-45046
(14/12/21): Minor updates to detection and mitigation advice following feedback
(13/12/21): Includes detection and enhanced mitigation advice
