Trellix logo
Trellix Introduction Video
Trellix Introduction

A living security platform with a pulse that is always learning and always adapting.

Gartner Magic Quadrant for Endpoint Protection Platforms
Gartner MQ (Endpoint)

Download the Magic Quadrant report, which evaluates the 19 vendors based on ability to execute and completeness of vision.

Gartner Marketplace Guide (XDR)
Gartner® Report: Market Guide for XDR

As per Gartner, "XDR is an emerging technology that can offer improved threat prevention, detection and response."

Critical Flaws in Widely Used Building Access Control System
Critical Flaws in Widely Used Building Access Control System

At Hardwear.io 2022, Trellix researchers disclosed 8 zero-day vulnerabilities in HID Global Mercury access control panels, allowing them to remotely unlock and lock doors, modify and configure user accounts and subvert detection from management software.

Trellix Threat Labs Research Report: April 2022
Trellix Threat Labs Research Report: April 2022

Our report on the rise of cyberattacks in the fourth quarter and Ukraine in the start of the new year.

Trellix CEO
Our CEO on Living Security

Trellix CEO, Bryan Palma, explains the critical need for security that’s always learning.

Trellix Introduction Video
Trellix Introduction

A living security platform with a pulse that is always learning and always adapting.

Stories

The latest cybersecurity trends, best practices,
security vulnerabilities, and more

Log4Shell Vulnerability is the Coal in our Stocking for 2021

Overview

On December 9, a vulnerability (CVE-2021-44228) was released on Twitter along with a PoC on GitHub for the Apache Log4j logging library. The bug was originally disclosed to Apache on November 24 by Chen Zhaojun of Alibaba Cloud Security Team.

The impact of this vulnerability has the potential to be massive due to its effect on any product which has integrated the Log4j library into its applications, including products from internet giants such as Apple iCloud, Steam, Samsung Cloud storage, and thousands of additional products and services. This is just the beginning as Java is heavily used in applications spanning nearly every industry, but there are precautions and strategies businesses can employ like proactive protection to build resiliency and safeguard against these more modern and prevalent threats.

What is it?

The vulnerability exists due to the way the Java Naming and Directory Interface (JNDI) feature resolves variables. When a JNDI reference is written to a log, JNDI fetches all requirements to resolve the variable. To complete this process, it downloads and executes any remote classes required. This applies to both server-side and client-side applications since the main requirements for the vulnerability are any attacker-controlled input field and this input being passed to the log.

To orchestrate this attack, an attacker can use several different JNDI lookups. The most popular lookup currently being seen in both PoCs and active exploitation is utilizing LDAP; however, other lookups such as RMI and DNS are also viable attack vectors. It’s worth noting that the simplistic LDAP/RMI attack vectors only work with older JDK versions. There are publications that have demonstrated methods to circumvent this limitation to achieve code execution, albeit with added complexity to the attack.

Java object deserialization vulnerabilities are not a new breed of vulnerabilities or attacks. Previous offensive research such as “marshalsec” can be applied to this vulnerability making code execution simplistic.

How it is evolving + what is being done

  • On December 14, it was confirmed that Log4j version 1.2 is vulnerable to similar attacks through the JMSAppender component and was issued CVE-2021-4104. It is important to note this is not as easily exploitable as versions 2.0-alpha1 through 2.16.0. For exploitation to occur, JMSAppender must be enabled, and set with TopicBindingName or TopicConnectionFactoryBindingName configurations allowing JMSAppender to perform JNDI requests. This is not the default configuration.

Following this confirmation, Apache released a new version of Log4j, version 2.16.0. This update disabled JDNI by default requiring a user to explicitly turn the JNDI feature on and completely removed support for message lookups.

  • Then, on December 18, a new denial of service (DoS) vulnerability, CVE-2021-45105 was discovered affecting versions 2.0-alpha1 through 2.16.0 of Log4j. To mitigate the original Log4j vulnerability, Apache completely disabled JNDI lookups in version 2.16.0, however self-referential lookups remained a possibility under non-default configurations. When a nested variable is substituted by the StrSubstitutor class, it recursively calls the substitute() class. When this nested variable recursively references the variable being replaced, it leads to an infinite recursion and a DoS condition on the server. Current research shows this does not lead to code execution, like the previous vulnerabilities.

From here, Apache released a new version of Log4j, version 2.17.0, to address the latest DoS vulnerability. Two additional classes were created from StrSubstitutor to manage parsing strings that may contain user input. These additions do not allow recursive evaluation. Due to exploitation of this vulnerability leading to a DoS, it is considered less critical than the previously reported Log4j vulnerabilities which can lead to remote code execution.

It is important to note, for exploitation to be successful there are several non-standard conditions that need to be met. As the Log4j situation is continuing to evolve, we recommend upgrading to version 2.17.1, where possible, in addition to taking this time to review overall security strategies and practices as we embark on this new year.

A positive outlook ahead

There is a lot of information about different ways to mitigate this vulnerability, with the potential for humans and machines to learn and adapt together in an always-on way. As threats become more dynamic, strategies and processes need to as well to ensure business operations are optimized and protected. Log4j represents an actionable opportunity for businesses to shift from thinking about threats as an inevitable detriment, and instead view them as an opportunity for growth, learning, and adaptation to build resiliency and a business advantage moving forward.

We have been closely tracking this vulnerability since it became known, as we recognize how critical it is for security to be a living entity to keep pace with fast-evolving threats like Log4j. Our initial goal was to determine the ease of exploitation using the public PoC, which we have reproduced and confirmed. This was done using the public Docker container and a client/server architecture leveraging both LDAP and RMI, along with marshalsec to exploit Log4j version 2.14.1.

Going forward we plan to test variations of the exploit delivered using additional services such as DNS. In the meantime, We have released a network signature KB95088 for customers leveraging NSP (Network Security Platform). The signature detects attempts to exploit CVE-2021-44228 over LDAP. This signature may be expanded to include other protocols or services, and additional signatures may be released to complement coverage.

Looking for more resources?

Full coverage for this vulnerability can be tracked from our Security Bulletin here and a growing list of PoCs and tools can be found here:

最新情報を入手する

サイバー セキュリティは私たちの得意とするところです。とはいえ、私たちは新しい会社です。
これから進化してまいりますので、最新情報をお見逃しなきよう、お願いいたします。

有効な電子メール アドレスを入力してください。
迷惑メールゼロ。配信はいつでも停止できます。