Our Approach

Definitive Guide to Ransomware

Log4j:
Best Practices

This page provides a high-level overview of the critical Log4j security issue and a framework for next steps. This page is updated as the Hunt & Hackett security analysts discover new insights.

If you have any questions, please contact us using our 24/7 Incident Response Hotline:

Call +31 70 222 0000

Contact us

What is the Log4j issue?

A high-risk security issue in Log4j was publicized on December 10, with reference CVE-2021-44228. This security issue allowed attackers to easily abuse this software to run malicious programs, thus fully controlling affected systems. In risk management terms:

  • The impact of this vulnerability is very high: full compromise of the affected application;
  • The likelihood of this vulnerability is very high: it is trivial to exploit this vulnerability and will likely generate an attack-wave where attack-groups are looking to establish (initial) footholds.

A specific problem in this scenario is that Log4j is a widely used software subcomponent in applications. Most organizations probably do not know (or did not know) that they are users of this code. Addressing the risk of this vulnerability is therefore dependent on the application that uses the Log4j component, which may or may not be under your direct control.

log4j

The core of the problem lies in the ‘enrichment’ function of Log4j. At its core, Log4j receives log entries from other components to process them and store them in log files. During the processing of a log entry, the data is enriched, allowing the log message to be more useful. Unfortunately, a specially crafted log message can pull in malicious programs and run them, as part of the enrichment step. Therefore, an attacker only needs to ‘sprinkle’ malicious log entries, hoping that they get enriched by Log4j.

log4j-flowchart_vv copy

Inventory & patch

The most sensible step is to assess the impact of this Log4j vulnerability for your organization by making an inventory of affected systems. If you have an up-to-date CDMB this is a great starting point.

For systems you control yourselves you can use vulnerability scanning technology to quickly find affected versions. Log4j versions 2.15 and older require an update to 2.16.

For embedded use of Log4j you can use lists of affected applications online:

Patching this vulnerability is the best way forward.

Monitor

Due to the nature of the vulnerability, it is hard to monitor for successful exploit attempts. There is no indication if an attempt is successful or not.

Two main ways of detection are useful:

  • Monitoring of exploitation attempts within the boundaries of your organization. If this happens, attackers have found a way to deliver the exploit further down the line.
  • Monitoring vulnerable systems for post-exploitation behavior. When the attack is successful, an attacker will start to move laterally through the network or communicate with the outside world. This behavior should be monitored closely

Detection of exploit attempts is well documented. The basic pattern to look for is the string ‘${jndi:’. There are however a large amount of variations to this pattern. Details of detection patterns can be found at:

Prevent

The exploit for this Log4j vulnerability can be identified and blocked to a certain degree, so that it does not reach vulnerable systems. Possible prevention steps are:
  • Enable IPS on edge devices to block malicious Log4j requests. Most NGFW and WAF products have support for this by now;
  • Block outbound network connections from systems that use Log4j. If an exploit is successful, at least block the retrieval of malicious code;
  • If you can control the applications that use the Log4j components, additional steps are available for preventing misuse of this vulnerability:
    • Block the start of processes by Log4j component using endpoint security products. This is not a trivial task since Log4j is embedded as a component;
    • Set an environment variable that prevents external lookups (set formatMsgNoLookups to True)
    • Remove vulnerable libraries of the Log4j component, specifically the JndiLookup.class within the Log4j ‘jar files’.

How can we help?

Hunt & Hackett can help you to control your Log4j risk:

Get in touch