On December 9th 2021, Apache published a zero-day vulnerability (CVE-2021-44228) for Apache Log4j2 being referred to as “Log4Shell.” This vulnerability has been classified as “Critical” with a CVSS score of 10, allowing for Remote Code Execution with system-level privileges.
Tripwire has investigated all currently supported versions of the following software regarding the Log4j2 vulnerability:
Products confirmed as NOT impacted
Tripwire has concluded that these products do not use vulnerable versions of the Log4j2 package:
- Tripwire® Enterprise
- Tripwire IP360™
- Tripwire LogCenter®
- Tripwire Industrial Visibility
- Tripwire State Analyzer (on-prem)
- Tripwire Apps
- Tripwire Console Orchestrator
- Dynamic Software Reconciliation
- Event Sender
- Tripwire File Analyzer
- IP360 Commander
- Tripwire Password Manager
- TE Commander
- Tripwire Integration Framework (TEIF)
- Note:The BMC Remedy module requires customers to download Remedy API JAR files (including Log4j2) which are loaded by TEIF. These JAR files are not included in TEIF or provided by Tripwire.
- Whitelist Profiler
- Tripwire Configuration Compliance Manager (CCM)
- Tripwire for Servers (TFS)
- Tripwire Industrial Sentinel (While initially listed under “impacted products” further investigation has found that Tripwire Industrial Sentinel was not and is not impacted by logj42.)
Impacted Products
These products are known to be impacted by CVE-2021-44228.
For products with time stamps in the mitigated column: Tripwire has mitigated the CVE-2021-44228 vulnerability by modifying the following products or environments. “Fixed version” updates for remaining vulnerable packages are still in progress.
| Product | Security Mitigations Deployed to Counter Exploitation |
|---|---|
| Tripwire Connect (on-prem) | Upgrading to 4.5.0.1 is recommended, but manual mitigation is available for Connect 4.4 and 4.5** |
| Tripwire Connect SaaS (cloud) | Dec 16, 2021 3:30 pm PST |
| Tripwire Configuration Manager (SaaS) | Dec 15, 2021 4:06 am PST |
| Tripwire Anyware SCM (SaaS) | Dec 15, 2021 4:06 am PST |
| Tripwire State Analyzer (SaaS) | Dec 15, 2021 4:06 am PST |
| Tripwire ExpertOps* | Dec 16, 2021 3:30 pm PST |
Committed To Your Security Posture
Tripwire takes this issue seriously and we continue to monitor evolving Log4j developments and analyze and improve our products accordingly. CVE-2021-4428 is the primary focus of this page as our investigation has identified no instances of CVE-2021-45046. Our teams have identified the use of Log4j 1.x in third party components in some our products. While Log4j 1.x is not impacted by these CVEs, we are working to update our products to the latest, most secure versions. For status updates on these please visit the Tripwire Customer Center.
- *A note on our managed services security posture:
We utilize a SIEM with telemetry signatures for Log4j2 which includes IDS/IPS and our 24/7 SOC and security teams actively hunting for exploit attempts. Further controls are in place using behavioral based AV solutions that has coverage for CVE-2021-44228 and will block known vulnerabilities. We further have boundary controls in place to limit the outbound connections per best practices, along with firewall security coverage to drop traffic related to this vulnerability. - **For Connect v4.4 or v4.5, if unable to upgrade to v4.5.0.1, contact Tripwire Support to perform the manual Tripwire Connect remediation::
- Create TCC Ticket: https://tripwireinc.force.com/customers/TCC_CaseList
- https://www.tripwire.com/support for more information
- **For Connect v4.3 upgrade to v4.5.0.1
- **For upgrading older versions of Connect, please contact Support for guidance.
How Can Tripwire Help You Address Log4j2 Vulnerabilities?
Tripwire IP360 Users:
Tripwire IP360 can be configured to detect the vulnerability through application scanning. IP360’s ASPL-978 includes multiple checks for identifying instances of the Log4Shell vulnerability (CVE-2021-44228) using either DRT or non-DRT scanning.
The following content checks are available:
- DSA-5020: apache-log4j2 CVE-2021-44228 Vulnerability
- IBM WebSphere Application Server CVE-2021-44228 Vulnerability
- Apache Log4j2 LogShell Remote Code Execution Vulnerability via Classpath Registry Keys
- Elasticsearch CVE-2021-44228 Information Disclosure Vulnerability
- VMSA-2021-0028: CVE-2021-44228 vCenter Server Apache Log4j Remote Code Execution Vulnerability
If you need help applying these content checks, please visit our IP360 Coverage Guide, located here within our Tripwire Customer Center.
Tripwire continues to work on additional checks to help you address Log4j2 and we will continue to update this page as they are available.
Tripwire Enterprise Users:
Tripwire Enterprise has added detection for the vulnerable Log4j2 to the policies listed:
- High Impact Vulnerabilities Linux
- High Impact Vulnerabilities Windows
More information can be found here, within our Tripwire Customer Center.
Workarounds/General Guidance
Tripwire recommends applying the latest security updates from Apache and mitigative actions outlined below.
Security Updates from Apache:
- Apache CVE: CVE-2021-44228
- Apache security advisory: Apache Log4j2 Security Vulnerabilities
If sensitive devices are identified, Tripwire recommends attempting to mitigate the risk until patches can be applied. The following mitigations are recommended by Apache but should not be considered a complete solution:
- In case the Log4j2 vulnerable component cannot be updated, Log4j2 versions 2.10 to 2.14.1 support the parameter log4j2.formatMsgNoLookups to be set to ‘true’, to disable the vulnerable feature. Ensure this parameter is configured in the startup scripts of the Java Virtual Machine: -Dlog4j2.formatMsgNoLookups=true.
- Alternatively, customers using Log4j2 2.10 to 2.14.1 may set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to force this change.
- Users since Log4j2 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
- For releases from 2.0-beta9 to 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
In addition to the workaround and patches, the following simple mitigative actions can be taken:
- Configuring a firewall to allow outgoing traffic to a trusted whitelist of addresses and protocols will prevent an attacker from communicating outside of the network
- Ensuring that logs are stored under different privileges will make it harder for attackers to cover their tracks.
- Exploitation attempts can be detected by inspecting log files for the characteristic URL pattern ${jndi:ldap://.