December 17, 2021

Log4J Critical Vulnerability Advice

TLDR: A critical vulnerability has been identified in the popular Java logging library, Apache Log4j2. This threat has a CVSS score of 10 and should be treated as an utmost priority to mitigate. Impacted systems may still pass a vulnerability test, all indicators of compromise should be reviewed carefully. Seek professional cybersecurity advice if you need support.

On December 10th, a critical vulnerability, CVE-2021-44228, was identified in the popular Java logging library, Apache Log4j2. This Java library is used in a huge range of proprietary and free open source software, varying from personal web servers, ecommerce and gaming platforms, to home appliances and corporate ERP systems. Exploits are already available in the wild, unfortunately this vulnerability is as bad as it gets!

Dubbed Log4Shell by researchers, this vulnerability is being used to implant malicious activity and researchers have detected mass scanning searching for servers using Log4j. Log4j is widely used by developers and incorporated in popular frameworks, such as Apache Struts2, Apache Solr and Apache Spark. With the severity and ubiquity of this vulnerability affecting most organisations today, it is important that vulnerable assets are patched as soon as possible.

An almost endless list of affected products and services can be found here on GitHub.

 

How does the attack work?

The vulnerability allows an unauthenticated remote attacker to execute arbitrary code on an affected system. What that means in plain language is, if an attacker can connect to an at-risk system, they will be able to remote execute any code on that infrastructure.

For example, if a public facing service is reachable by a threat actor then a web message can be sent to the service with a specially crafted string within the request (URI, AgentString etc) with a Base64 encoded instruction. This requires no authentication! The instruction will generally be to establish an outbound connection to a threat actor-controlled machine and retrieve and execute a payload.

Once persistence is obtained then lateral movement and other malicious payloads can be deployed.

Threat actors have even been observed patching affected systems after compromise, to prevent other threat actors from obtaining access to systems they’re targeting, as well as keeping themselves under the radar from vulnerability scans. This style of activity makes it even more challenging to mitigate, as an impacted system may pass a vulnerability scan and therefore be assumed not at risk. Further checks should be undertaken to look for other indicators of compromise.

The malicious code can be anything from simple crypto mining scripts, to ransomware that can propagate further through the network using the compromised system as a jump host. If you have vulnerable systems that are connected to the internet (or any untrusted network), they should be patched immediately.

Vendor responses

Apache has already released a patched version of Log4j 2.15.0. They followed up on December 15th with a new advisory, releasing patch 2.16.0 and superseding 2.15.0. See here CVE – CVE-2021-45046 (mitre.org). Applications using Java 7 will need to be upgraded to Java 8 to allow update to the patched version.

For systems that cannot be upgraded, Microsoft released an advisory on mitigation strategies for disabling the vulnerable logging feature. This blog should be referred to daily as Microsoft add new indicators of compromise and detection methods via Microsoft Defender and Azure Sentinel.

See here guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation – Microsoft Security Blog

On December 16th, Microsoft released a new detection solution for Log4J in Azure Sentinel. Customers can find it added to the Content Hub that provides content to monitor, detect and investigate signals related to exploitation of the vulnerability. See more here.

Recommended actions

As Log4j2 library is so ubiquitous, the biggest challenge for first responders is to identify affected assets. Vulnerability management vendor, Tenable (along with some other vendors) have released plug-ins to detect CVE-2021-44228 using both on-premises and cloud-based vulnerability management platforms.

  • Plugin ID 156014 – Apache Log4Shell RCE detection via callback correlation (Direct Check HTTP) – This remote check can be used to identify the vulnerability without authentication. This plugin is compatible with Tenable cloud scanners.
  • Plugin ID 155998 – Apache Log4j Message Lookup Substitution RCE (Log4Shell) (Direct Check) – This plugin listens for an LDAP BIND connection from a target host. It is not compatible with Tenable.io cloud scanners and may fail to return results in certain networks due to firewall rules or interference from other security devices. We continue to explore options for additional detection and recommend Tenable.io cloud scanner customers use the following four plugins.
    • Plugin ID 155999 – Apache Log4j < 2.15.0 Remote Code Execution
    • Plugin ID 156000 – Apache Log4j Installed (Unix)
    • Plugin ID 156001 – Apache Log4j JAR Detection (Windows)
    • Plugin ID 156002 – Apache Log4j < 2.15.0 Remote Code Execution

Additionally, a comprehensive Tenable.io Web App Scanning (WAS) plugin has been released which can be used to test input fields that can be used to exploit Log4Shell.

  • Plugin ID 113075 – Apache Log4j Remote Code Execution (Log4Shell)

Tenable has released scan templates for Tenable.io, Tenable.sc and Nessus Professional which are pre-configured to allow quick scanning for this vulnerability. In addition, Tenable.io customers have a new dashboard and widgets in the widgets library. Tenable.sc users also have a new Log4Shell dashboard.

Customers who currently don’t have any Tenable products can utilise a free trial of Nessus Professional or Tenable.io.  The accuracy of these plugins will depend on the configuration of the systems and underlying network, thus interpretation of the results by an experienced cyber analyst is key to avoid false-negative assessments.

Compensating controls such as Intrusion Prevention Systems, which usually come integrated into next-gen firewalls, might buy some time for patching, assuming the affected systems either use insecure HTTP protocol or the IPS is able to decrypt HTTPS traffic. It is crucial to understand whether such controls are effective, as in many cases decryption is either not implemented or depends on underlying cryptographic algorithms and protocols used by the web servers, and such mistakes have led to large-scale security breaches in the past.

Consumer grade devices have also been added to the list of affected systems, such as certain wireless controllers, firewalls, IoT devices and modems. As more of us have been working from home this opens-up other security risks for businesses as well. We encourage everyone to check for updates on any device in the home as well.

Step-by-step remediation support from SecurityHQ

To understand how the attack is executed step-by-step, and for a detailed guide on remediation actions. Please see the blog prepared by Data#3 SOC partner, SecurityHQ.

SecurityHQ has also released this video to demonstrate how to mitigate the threat.

We’re here to help

Data#3 has a wealth of experience in cybersecurity domains including vulnerability management, penetration testing, next-gen firewalls, intrusion prevention, security architecture and advisory, controls and compliance assessments, and Managed Security services, including SOC. Our full suite of security products and services can be found here.

If you require any assistance with managing CVE-2021-44228 vulnerability, please reach out to a cybersecurity specialist or contact your Data#3 account manager.

I’d like to acknowledge David Summers and thank him for his contributions to this blog.