Last updated (15/12/21)
(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.
An unauthenticated remote code execution vulnerability (CVE-2021-44228) affects Apache Log4j versions 2.0-beta9 to 2.14.1. The NCSC is aware that scanning and attempted exploitation is being detected globally, including the UK.
Proof-of-concept code has been published for this vulnerability.
The NCSC has published further information explaining the Log4j vulnerability.
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.
An application is vulnerable 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 (currently Log4j 2.16.0).
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 – 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 in previous releases of Log4j (2.10 and later) by setting system property “log4j2.formatMsgNoLookups” to “true”. The JndiLookup class can also be removed from the classpath. However, this has limitations and should not be relied upon:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Organisations should routinely run vulnerability scanning across their networks, to detect when updates are available.
-
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 or mitigated.
-
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.
Additional information
CVE-2021-45046
The NCSC is aware of a denial of service vulnerability (CVE-2021-45046) affecting all versions of Log4j2 from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0. The NCSC’s advice has not changed and updating to the latest version of Log4j (currently Log4j 2.16.0) addresses this vulnerability.
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: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
- 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 and services 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.
