Security notice for Log4j CVE-2021-44228 vulnerability

Update on 16 February 2022

The Log4j 1.2.17 library is replaced with the latest 2.17.1 library in the latest release of the software (9.6.17). Customers concerned about the vulnerabilities of Log4j 1.2.17 can now upgrade their environment to the latest version. Only a full upgrade is available, patches cannot be provided. We are still unaware of any Log4j vulnerability for version 1.2.17 which would affect the previous installations.

 

Am I affected

The Verint security team is actively investigating the impact of the Apache Log4j2 Vulnerability CVE-2021-44228 across all Verint products and cloud services. The team has determined that the current version of Verint Financial Compliance (Verba) as provided to our customers is not vulnerable to the Apache Log4j2 Vulnerability CVE-2021-44228 based on identified indicators of compromise by industry experts. As more information is released, we continue to review our offerings and follow manufacturer recommended remediations for all systems and services.

The Verint Financial Compliance (Verba) product does not use Log4j 2.x, it uses an earlier version of the library (1.2.17). 

 

Summary & Impact

Apache Log4j <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.

Versions Affected: all log4j-core versions >=2.0-beta9 and <=2.14.1For more information, see https://logging.apache.org/log4j/2.x/security.html

 

Note on Log4j CVE-2019-17571 vulnerability affecting 1.2.x

Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This vulnerability does not affect the system, because the system does not allow using remote logging via the network at all.

 

Was this article helpful?
4 out of 4 found this helpful
Have more questions? Submit a request

Comments

12 comments
  • No, you should not delete the Log4j library because the system will stop working. The known vulnerability in Log4j 1.2 does not affect the system because the system does not use the vulnerable SocketServer class, it is not enabled. We understand that the security scanners are flagging this version of the Log4j library and we are currently assessing when and how we can move to the latest version of the library. We will update this article when we can share more details.

    4
    Comment actions Permalink
  • In the https://logging.apache.org/log4j/2.x/security.html article you linked to, please see the top section regarding Log4j 1.x:

    "Please note that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes."

    We think this means that since going EOL in 2015, Log4j 1.x is not checked for new vulnerabilities but is still likely to be vulnerable. Our scanning also flagged our VFC servers running Log4j 1.2.5 as vulnerable as proof of this. Can you please look again?

    3
    Comment actions Permalink
  • CVE-2021-4104 = JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default

    And does Verba use JMSAppender.CLass?

    1
    Comment actions Permalink
  • @Hamzeh Tahat, no, Verba does not use the JMSAppender class

    0
    Comment actions Permalink
  • Had this from Verba Support on 1.x

    "We are aware of that vulnerability and based on our understanding it only affects systems where remote logging is used by opening a server socket to receive log messages. This feature is not used or enabled in the Verba product."

    0
    Comment actions Permalink
  • Hi, could we know if the Verint V11.x recording solution is impacted with this Log4j?

    0
    Comment actions Permalink
  • Has this log4j file been addressed in a recent update yet? I understand you it has been stated that it is not vulnerable, but we are wanting to stop this from alerting from our scanner and will pursue an upgrade to the latest version if this has been addressed.

    0
    Comment actions Permalink
  • @Xaforn Wong, no, the Log4j library cannot be changed without updating certain parts of the application itself, we are working on this and will share more details soon

    0
    Comment actions Permalink
  • So does it mean, that we can delete the Verba\Bin\Log4j-1.2.17.jar ? If its not used... Otherwise every Vulnerability Scanner will alert... Or do we can download a Update from Verba Site ? 2.5X

    0
    Comment actions Permalink
  • can customer manually upgrade the log4j to 2.17.1? or it must need bundle with the VFC package for the installation?

    0
    Comment actions Permalink
  • 0
    Comment actions Permalink
  • @Brian Jones yes, we have updated Log4j to the latest version in v9.6.17

    0
    Comment actions Permalink

Please sign in to leave a comment.