What is Log4j?

Log4j is an open source Java library for logging features developed and released by the Apache Foundation group. Such library is used as dependency of many applications and services used globally in Java applications as it is included in several Apache Frameworks like Apache Struts2, Apache Solr, Apache Druid, Apache Flink and Apache Swift, but also, used by Netty, MyBatis and the Spring Framework.

What is the Log4j vulnerability about?

An application is vulnerable if it passes a non-validated user input to the Log4j logging library of the affected versions. The Log4j vulnerability allows to execute remote code without authentication from version 2.0-beta9 to 2.14.1. Below is explained how the Log4j vulnerability is exploited.

Prioritized actions for Log4j mitigation

Install the latest updates where Log4j instances are known. First step is to detect any Log4j instances in your organization and apply latest updates from official repositories.

Apply WAF policy rules in order to protect your deployed applications. Using Web Application Firewalls in your organization can improve the monitoring and blocking the exploitation of this vulnerability. Just ensure to block requests where the URLs contains strings like “jndi:ldap”. Please note that variants could bypass the current WAF rules or applications where such LDAP feature is used can be not usable. Ensure to have them updated.

Please consider to use ZEVENET as Web Application Firewall for Log4j mitigation.

Is ZEVENET affected by the Log4j vulnerability?

ZEVENET appliances or public services are not affected as Apache frameworks are not being used.

How to protect my applications against Log4j vulnerability with ZEVENET Web Application Firewall

Once a virtual service or farm for our application is created, then apply the following steps in order to create the WAF rule:

Create a new ruleset
Create a new Action rule in the new ruleset. The rule configuration should be:

     Resolution: Deny (Cut the request and not execute rules left)
     Phase: Request headers are received

Create a Condition in the rule with the following configuration:

     Variables: REQUEST_URI, REQUEST_HEADERS
     Transformations: lowercase, urlDecodeUni
     Operator: strContains
     Operating: jndi:ldap

Finally, start the ruleset and apply it to the desired farms.

Note that with this ruleset, every HTTP request where the URLs and headers will be analyzed looking for the vulnerable string.