Risk Advisory: Log4Shell Remote Code Execution Vulnerability

Tuesday, 14 December, 2021

A pile of logs

Cydea’s risk advisories are intended for senior management to aid their understanding of current events and the cyber risk posed to their organisations.

What has happened?

A popular open-source tool has a design flaw which means attackers can remotely run commands on a device. The Apache Software Foundation’s Log4j is a software library used by software developers to log the actions taken by applications written in the Java programming language.

This sort of reusable component generally improves speed and quality of development, however when issues like this are discovered they may affect every application where they are used, resulting in a lot of knock-on security issues.

The problem is exacerbated because many organisations do not know, and vendors may not disclose, what components or libraries like this are used within their software.

The flaw identified in Log4j is a serious one, a ‘remote code execution’ vulnerability, that essentially allows remote control of servers accessible to an attacker, without them needing a username or password.

Details of how to exploit the vulnerability were published on 9th December 2021, prior to a patch being available to remedy the issue, making it a so-call ‘zero-day’ vulnerability.

Due to the pervasiveness of Log4j in enterprise applications, and seriousness of the issue, it has received widespread attention and quickly been tested by both legitimate security researchers and cybercriminals as a way to gain access to vulnerable systems.

It is commonly referred to as ‘Log4Shell’ (CVE-2021-44228) because ‘shell’ is a term for the command prompt on a computer, and affects applications using the open-source Java logging library, Apache Log4j, between versions 2.0 and 2.14.1.

What is the risk?

This vulnerability provides a quick, easy and reliable way for attackers to gain unauthorised remote access to a system. This remote code execution can be used by attackers to access servers running vulnerable applications, change their configuration, run malware, and use it as a ‘beachhead’ for onward access to other connected resources and systems.

While cybercriminals’ activity has been seen, ‘good samaritan’ security researchers are also scanning for this vulnerability and, if they find it within your organisation’s applications, may be in touch to advise of the issue, especially if your organisation operates a vulnerability disclosure, or ‘bug bounty’ programme.

Source:

External / Criminals
External / Security researchers

Risk events:

System Intrusion (software exploit)

Consequences:

Financial (unplanned response costs; bug bounties)
Operations (business disruption)

How may it evolve?

Logging is a basic function of an application and it’s likely that many organisations, and indeed vendors, will not realise or know that their apps are using a vulnerable version of the Log4j library. As a result, this issue will likely persist, and be the cause, of many incidents in the weeks and months to come.

Criminal groups will start looking for vulnerable applications as a way to gain access to an organisation to steal data or conduct ransomware attacks.

Source:

External / Criminals

Risk events:

Information Breach (unauthorised access to systems; unauthorised access to information)
Malware (ransomware)
Fraud / misuse of resources (for example, to run crypto-mining software)

Consequences:

Financial (unplanned costs)
Operations (business disruption)
Strategic (damaged reputation; embarrassing reporting)
Compliance (regulatory fines)

What action is required?

A patch that remedies the vulnerability has been made available by the Apache Software Foundation, and there are also other workarounds available to mitigate the risk. However, for many organisations the primary action - and challenge - will be identifying vulnerable applications.

Actions are recommended to both address the immediate, acute issue, and also to improve your organisation’s long-term cyber health.

Actions to address the acute issue

This should be the primary activity of your technology teams in relation to this issue, however it may take time for them to collect the information, especially where they are reliant on feedback from your software vendors.

Establish what applications you use that may be vulnerable to ‘Log4Shell’

_This process can be shortened by ensuring that teams focus on:

shortlisting applications written in the Java programming language
cross-referencing the list of vulnerable software being maintained by the Netherlands cyber security agency (below), and
identified using the command in the NCSC guidance (below)_

For applications developed in-house:

Apply the patch issued by the Apache Software Foundation to prevent the vulnerability from being exploited.

Update Log4j to version 2.15.0 or newer (Java 8 is required for this patched version of Log4j, and this may cause issues for legacy applications).
Consider other configuration options to mitigate the issue and harden your infrastructure.

For applications developed by third-party software vendors:

Check for communications or security bulletins from your vendors and prioritise installation of their updates
If they have not released a patch, other configuration options may be applied to mitigate the issue.

In either case

Review outbound firewall rules to restrict server access to uneccessary Internet addresses

Actions to improve long-term resilience

The complexity of modern software and development practices make this sort of issue likely to become more prevalent. Understanding which third-party libraries and components are used within your applications will help to minimise the time to understand if future issues apply to your organisation.

Develop an inventory of software and its components

For in-house applications this inventory should be a requirement on software engineering teams, and will also help to ensure compliance with software licensing requirements.

When purchasing third-party software, begin to ask the vendor for a ‘software bill of materials’ (SBOM) to accompany the application. (This practice has recently been introduced by the U.S. government for all future software purchases, and will become more common across industry, too).