Log4Shell vulnerability – advice and recommendations

A new vulnerability, Log4Shell, is putting organisations around the world at risk as threat actors look to exploit it in order to carry out ransomware attacks or sensitive data exfiltration.

The vulnerability, which has been described as critical and high level, is found in Java based logging tool Log4j developed by the Apache Foundation and affects all organisations that incorporate Java within the software they use and develop.

First disclosed by a security researcher last week, the vulnerability is now being investigated by researchers and also actively exploited by a range of actors including nation states, criminal groups, and crypto miners.

At NCC Group, we’ve set up a live research blog to track the development of the vulnerability and here, we outline practical advice for how organisations can defend themselves against it.

What is Log4j?

Log4j is a popular logging framework for Java and has a feature that enables it to integrate with JNDI (Java Naming and Directory Interface), an API providing abstraction around naming and directory services that enables Java applications to look up resources as Java objects.

It is this integration, which is accessible to essentially any string input being logged through Log4j, that is being abused to exploit systems. The flexible nature of JNDI, and the flexibility of templating given to logged strings, means that exploitation attempts are difficult to detect or investigate.

What should organisations do?

Many organisations may not know whether their software incorporates Log4j so the crucial first step is to find out and then put measures in place to identify and respond to any threats so attackers can’t use the vulnerability as an entry point to their systems.

Our current recommendations are:

1.Identify vulnerable software/devices via:

• asset inventories
• software bill of material manifests
• software build pipeline dependency manifests (e.g. Maven etc.) 
• vendor bulletins (see below)
• file system discovery (see below) on Windows / Linux to identify class files 
• log file analytics to identify log4j like entries 
• exploitation (see below)

2.Software developers should 

• Ensure they strictly enforce via Gradle and similarly non vulnerable versions of log4j to mitigate transient dependencies 

3.When encountering Log4Shell/Log4J/CVE-2021-44228 related artefacts, please consider doing the following:  

• Create a machine snapshot or create clone of virtual servers. Include memory, if possible, successful exploits might run in-memory only   
• Secure firewall logs   
• Secure flow logs   
• Secure proxy logs 

4.Patch vulnerable software for which patches are available (see vendor bulletins)

• Hot patch also exists (see below) 

5.Limit network egress from hosts where vulnerable software exists when possible

6.Mitigate through configuration changes as specified in our Research blog 

7.Ensure protective monitoring via extensive scanning of

• Network for remote class loading 
• On host for remote class loading 
• On host for unexpected command execution 
• For a mitigation hotfix, also see our Research blog

Ollie Whitehouse, Global CTO, NCC Group comments:

“The wide usage of Log4j means that exploitation of the vulnerability could have a range of impacts if exploited and organistions may be compromised as a result. The bug affects all organisations utilising Java based technology from large and small vendors alike, so it is crucial that they are confident in their ability to identify and respond to any threats.

By identifying the presence of Log4j vulnerability as soon as possible coupled with deploying robust detection & response capabilities, organisations can protect themselves and avoid becoming a victim of an attack.”

For up-to-date technical information about the vulnerability and a simple method to mitigate it, see our research blog which will be updated as the situation develops:

https://research.nccgroup.com/2021/12/12/log4shell-reconnaissance-and-post-exploitation-network-detection/

https://research.nccgroup.com/2021/12/12/log4j-jndi-be-gone-a-simple-mitigation-for-cve-2021-44228/