Description
Like the rest of the security community, we have been internally responding to the critical remote code execution vulnerability in Apache’s Log4j Java library (a.k.a. Log4Shell). We have been continuously monitoring for Log4Shell exploit attempts in our environment and have been urgently investigating the implications for our corporate and production systems. Log4Shell has kept the security community extremely busy for the past several days, and we are no exception. At this time, we have not detected any successful Log4Shell exploit attempts in our systems or solutions. We will continue monitoring our environment for new vulnerability instances and exploit attempts and will update this page as we learn more.
Rapid7 solutions
In terms of Rapid7’s solutions, we prioritized remediation efforts on the Insight Platform and other hosted web application products (e.g. non-Insight branded products such as Logentries). We have remediated the Log4Shell vulnerability in our deployed application services’ code.Customers do not need to take action for any of our hosted web solutions.
Update for December 17, 2021: All hosted solutions that were updated to Log4j-core 2.15 have now been updated to Log4j-core 2.16.
Update for December 20, 2021: We are aware of a new denial-of-service (DoS) vulnerability discovered in Log4j-core 2.16 (CVE-2021-45105) and are working on updating our codebases to use Log4j-core 2.17. We will update this blog post once completed.
Customer action required
There is no action for most customers using our solutions. However, for those using on-premise solutions, the following products and product components have been patched but require customers to take action to fully remediate Log4Shell in their environments. We strongly urge all customers using vulnerable versions of these products and product components to apply updates immediatelysince this vulnerability is being actively exploited and could result in highly impactful remote code execution.
Product or Component | Affected Version(s) | Remediation and Mitigation Instructions |
---|---|---|
InsightOps r7insight_java logging library | Versions <= 3.0.8 | Upgrade r7insight_java to 3.0.9 |
Logentries le_java logging library | All versions: this is a deprecated component | Migrate to version 3.0.9 of r7insight_java |
Logentries DataHub | Linux version <= 1.2.0.820 |
Windows version <= 1.2.0.820 |Linux: Install DataHub_1.2.0.822.deb using the following instructions.
Windows: Run version 1.2.0.822 in a Docker container or as a Java command per these instructions.
You can find more details here.
InsightOps DataHub | InsightOps DataHub <= 2.0 | Upgrade DataHub to version 2.0.1 using the following instructions.
No customer action required
We have confirmed the following on-premise products and product components arenot affected:
- Alcide kArt, kAdvisor, and kAudit
- AppSpider Pro
- AppSpider Enterprise
- Insight Agent
- InsightIDR Honeypots
- InsightIDR Network Sensor
- InsightIDR/InsightOps Collector & Event Sources
- InsightAppSec Scan Engine
- InsightCloudSec/DivvyCloud
- InsightConnect Orchestrator
- InsightOps non-Java logging libraries
- InsightVM Kubernetes Monitor
- InsightVM/Nexpose
- InsightVM/Nexpose Console
- Installations of the InsightVM/Nexpose have “log4j-over-slf4j-1.7.7.jar” packaged in them. This is a different library than log4j-core and is not vulnerable to Log4Shell.
- InsightVM/Nexpose Engine
- Installations of the InsightVM/Nexpose have “log4j-over-slf4j-1.7.7.jar” packaged in them. This is a different library than log4j-core and is not vulnerable to Log4Shell.
- IntSights virtual appliance
- Metasploit Pro
- Metasploit Pro ships with log4j but has specific configurations applied to it that mitigate Log4Shell. A future update will contain a fully patched version of log4j.
- Update for December 17, 2021: Metasploit Pro version 4.21.0-2021121601 now ships with v2.16 of Log4j.
- Metasploit Framework
- tCell Java Agent
- Velociraptor
Further reading and recommendations
Our Emergent Threat Response team has put together a detailed blog post about general guidance about how to mitigate and remediate Log4Shell. We will continue updating that post as we learn more about Log4Shell and new mitigation strategies and tactics.