Apache Log4j 1.x Multiple Vulnerabilities.
After upgrading to CUM4 last week; the following vulnerability has been found. Need assistance in mitigating.
A logging library running on the remote host has multiple vulnerabilities.
According to its self-reported version number, the installation of Apache Log4j on the remote host is 1.x and is no longer supported. Log4j reached its end of life prior to 2016. Additionally, Log4j 1.x is affected by multiple vulnerabilities, including :
- Log4j includes a SocketServer that accepts serialized log events and deserializes them without verifying whether the objects are allowed or not. This can provide an attack vector that can be exploited. (CVE-2019-17571)
- Improper validation of certificate with host mismatch in Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender. (CVE-2020-9488)
- JMSSink uses JNDI in an unprotected manner allowing any application using the JMSSink to be vulnerable if it is configured to reference an untrusted site or if the site referenced can be accesseed by the attacker.
Lack of support implies that no new security patches for the product will be released by the vendor. As a result, it is likely to contain security vulnerabilities.
Upgrade to a version of Apache Log4j that is currently supported.
Upgrading to the latest versions for Apache Log4j is highly recommended as intermediate versions / patches have known high severity vulnerabilities and the vendor is updating their advisories often as new research and knowledge about the impact of Log4j is discovered. Refer to https://logging.apache.org/log4j/2.x/security.html for the latest versions.
Path : D:\Program Files (x86)\CA\SOI\wso2registry.bak\lib\log4j-1.2.13.jar
Installed version : 1.2.13
Release : SOI 4.2 CU4
During the upgrade, the wso2registry folder is backed up to a folder named wso2registry.bak.
This contains older log4j files that are not in play, but may trigger a file or version scan.
You may remove the wso2registry.bak folder.
I suggest moving it out of the /opt/CA path and saving it for a week or 2 to insure no issues with backed-up files or keystores being needed.