The following advice was extracted from the NCSC live blog on the 15/12/21.
The NCSC is advising organisations to take steps to mitigate the Apache Log4j vulnerability.
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:
ONE: 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:
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.
TWO: 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.
THREE: 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:
If you need further advice or help contact us today: hello@coolspirit.co.uk
