Log4j vulnerability in Kofax FraudOne

Issue

CVE-2021-44228 was discovered on 2021-12-10, the question remains if FraudOne modules are affected by this critical security vulnerability.
More details about the vulnerability can be found on the Apache website: https://logging.apache.org/log4j/2.x/security.html

Cause

The Apache Log4j2 RCE vulnerability allows to execute remote code via Log4j's JNDI API which ranked as a critical vulnerability.

Solution

FraudOne does not use Log4j library directly.

The included log4cxx library (C++ port of log4j) cannot be used to perform LDAP lookups for log strings.

There is only one dependency in our ThinClient called esapi-2.0.1.jar (OWASP Enterprise Security API) that transitively references log4j:1.2.16 only when configured in Esapi.properties (SignPlus.war\WEB-INF\classes\):
# Log4JFactory Requires log4j.xml or log4j.properties in classpath - http://www.laliluna.de/log4j-tutorial.html
#ESAPI.Logger=org.owasp.esapi.reference.Log4JLogFactory
ESAPI.Logger=org.owasp.esapi.reference.JavaLogFactory -> default value

However, this setting is not enabled by FraudOne by default. Moreover, Log4j 1.x does not offer a lookup mechanism, it does not suffer from CVE-2021-44228)!

In addition, Professional Service found no references to Log4j 2.x library in customizations for customers.

General possible mitigations include:

• Upgrade Apache Log4j to version 2.15.0 or higher.
• Block the possibility of JNDI to communicate with non-trusted servers.
• For releases >=2.10 the configuration value log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS can be set to true.
• For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
• For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Level of Complexity 

High

Applies to  

References