BT’s guide to the Log4j vulnerability

On the 9 December 2021 a vulnerability was discovered in a piece of software called Log4j, which is used in the Java development language. 

This software is very commonly used in commercial, enterprise and open-source deployments which means that many internet-facing and publicly accessible servers could be affected. The vulnerability allows a remote attacker to run malicious code on an otherwise-secure server by injecting specific text strings into log messages.

BT has seen a significant spike in scanning and malicious actors looking to exploit the vulnerability, with several examples of malicious and proof of concept code being freely available on the internet. The combination of the prevalence of this software within all industries, its regular use in internet-facing environments, and the fact that a proof-of-concept exploit for the code has been published, means this issue has been given a very high vulnerability rating to reflect its seriousness.
 

What can you do about it?

Protect

A software patch to take the Log4j code to a version that is not affected by this vulnerability is now widely available. You are advised to update any instance of Log4j that you can.

1. Current advice is to move to a version of software 2.17.0 or above on any services or servers that use Log4j. There will be a special new version, currently under development, (2.12.2) for those dependent on Java 7 who can't upgrade to the most up to date versions which require Java 8. For vendor-provided solutions which may embed this code and for which an upgrade is harder to achieve, please work with the vendor to identify and upgrade path / solution.
2. Use firewalls, WAF and IPS to control and detect any abuse of the vulnerability. Use EDR and endpoint firewalls and IPS to further harden any at-risk deployments which cannot be patched.
3. If immediate patching is not possible, then for versions greater or equal to 2.10 it is possible to make a configuration change to the Log4j settings which will mitigate the vulnerability. Details of this mitigation can be found (here).

Remember when upgrading software, be careful to only use legitimate software.

Detect

1. Most major security vendors have started to release IPS and WAF detections for Log4J exploits and you should ensure that permitter and web facing controls have been updated to detect abuse of the vulnerability.
2. You should seek to identify any instances of Log4j that you may have in-use, and especially those which are internet facing. A vulnerability scanner or perimeter scan can help with this if your scanner can detect components and versions.
3. Indicators of Compromise for the vulnerability have been published and these could be useful to additionally configure SIEM to detect and trap any logs which indicate abuse of the vulnerability. If you have log-searching capability on your web and application servers, the Indicators may be useful to additionally identify any instances of attack within the application logs.
4. You should work with your solution providers and software suppliers to identify any products they use that may contain Log4J to understand if they may be impacted. Most major vendors are already publishing impact statements, but some software vendors may not report their use of this component. A list of possibly impacted vendors that may help with this activity has been referenced by the UK NCSC (here).

A blend of detection, scanning and supplier management should be used to build up a full picture of any impacted devices and the risk these pose.

We can help you at every stage of your security journey, to assess and test your defences and select the solutions that match your security needs - whether that requires building an entirely new security strategy or upgrading your protections to combat the latest threats and trends. Find out more about our Security Advisory Services here.