Identifying and Remediating the Log4j2 Zero-Day Vulnerability

[et_pb_section fb_built=”1″ _builder_version=”3.22″ da_disable_devices=”off|off|off” global_colors_info=”{}” da_is_popup=”off” da_exit_intent=”off” da_has_close=”on” da_alt_close=”off” da_dark_close=”off” da_not_modal=”on” da_is_singular=”off” da_with_loader=”off” da_has_shadow=”on”][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” global_colors_info=”{}” custom_padding__hover=”|||”][et_pb_text _builder_version=”4.14.4″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” global_colors_info=”{}”]

Log4j Vulnerability – December 2021 Updates

 

In December 2021, a serious vulnerability was identified (CVE-2021-44228) that affects Log4j2 versions 2.0 to 2.14.1. This vulnerability highlights the challenges of mitigating risk within enterprise software and will require those organizations to develop their own patches to fix the issue. That is assuming the enterprise is able to identify all of the places they’re using Log4j2 to start.

The Log4j2 vulnerability has been remedied in 2.15.0, but if you are unable to update to the latest version, you can follow the information below to check if you are using the web app in your environment and how to remediate it.

 

What is the Vulnerability?

Apache Log4j2 is included within the Spring Boot framework, which is used by the UI backend of enterprise Java software for debugging and logging errors.

On Dec. 9, 2021, a remote code execution (RCE) vulnerability in Apache Log4j2 was identified being exploited in the wild. Public proof of concept code was released and a subsequent investigation revealed that exploitation was incredibly easy to perform.

By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker is able to instruct that system to download and subsequently execute a malicious payload.

Due to the ease of exploitation, the broad reach of the software, and the challenge of enterprise IT and security having blindspots – it is likely we will see ransomware threat actors quickly taking advantage of this vulnerability.

 

How to check if you use Log4j in your web app

• Running the following maven command will list top-level dependencies and dependencies pulled transitively
  • mvn dependency:tree
• Search for Log4j, in this project Log4j library was pulled in from spring-boot-start-logging dependency.
  • [INFO] +- org.springframework.boot:spring-boot-starter-logging:jar:2.2.7.RELEASE:compile[INFO] | +- ch.qos.logback:logback-classic:jar:1.2.3:compile[INFO] | | \- ch.qos.logback:logback-core:jar:1.2.3:compile[INFO] | \- org.apache.logging.log4j:log4j-to-slf4j:jar:2.12.1:compile[INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.12.1:compile
• If the Log4j version is 2.X and lower than 2.15.0 then you will need to update it to 2.15.

 

How to Fix it

• Explicitly specifying the latest version 2.15.0 for Log4j related dependencies in pom.xml will resolve this issue:
  • <dependency><groupId>org.apache.logging.log4j</groupId><artifactId>log4j-api</artifactId><version>2.15.0</version></dependency>

    <dependency>

    <groupId>org.apache.logging.log4j</groupId>

    <artifactId>log4j-to-slf4j</artifactId>

    <version>2.15.0</version>

    </dependency>

• Running list dependency command again:
  • mvn dependency:tree

You will see that the Log4j jar got pulled explicitly as top-level dependencies, while in the above example project spring-boot-starter-logging dependency will not pull Log4j jar anymore:

[INFO] +- org.apache.logging.log4j:log4j-api:jar:2.15.0:compile

[INFO] +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.15.0:compile

[INFO] | \- org.slf4j:slf4j-api:jar:1.7.30:compile

[INFO] +- org.springframework.boot:spring-boot-starter-logging:jar:2.2.7.RELEASE:compile

[INFO] | \- ch.qos.logback:logback-classic:jar:1.2.3:compile

[INFO] | \- ch.qos.logback:logback-core:jar:1.2.3:compile

 

How to avoid this in the future

One of the reasons why clients enjoy using Lucidum is that they can rapidly respond to vulnerabilities once they are identified, knowing where each instance of a vulnerability may exist. The Lucidum platform allows our customers to identify their unknowns and reduce their mean time to respond (MTTR).

Worried you’re still running vulnerable software? In less than five minutes you can create a dashboard in Lucidum that shows:

• The number of assets running a vulnerable version of Log4j
• Asset ownership information for the vulnerable asset (e.g. Security Groups, Owner)
• Summary data of vulnerable assets that provide patching prioritization (e.g. which are public and have listening services)

Below are screengrabs of the Lucidum platform showing the Log4j locations within the dashboards for fast and easy identification and triage.

 

 

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]