Log4j is a Java-based open-source logging library built and maintained by The Apache Software Foundation (ASF). Log4j is used by many devices and services.
CVE-2021-45105 is a 7.5/10-rated bug that was present in Log4j2 versions 2.0-alpha1 through 2.16.0. The fix is version 2.17.0 of Log4j.
If this vulnerability is not fixed, attackers can break into systems, steal passwords and logins, extract data, and spread malicious software.
Log4j vulnerability requires limited expertise to exploit.
It vulnerability affects a range of organisations, governments and individuals.
To protect yourself make sure your devices and apps are up to date and continue to update them regularly.
For business and enterprise customers, it is not easy to identify how your servers, applications, devices and other software and hardware use Log4j. Hence it is important to pay attention to updates and fixes released by software vendors.
The Rapid7 Insight VM platform is built on a library of vulnerability research, exploit knowledge, global attacker behaviour, public data, exposure analytics, and real-time reporting to provide a fully available, scalable, and efficient way to collect your vulnerability data and turn it into answers. InsightVM leverages this platform for live vulnerability and endpoint analytics.
Methods for detecting Log4j:
1) Authenticated and agent-based assessments:
The most reliable way to find vulnerable instances of Log4j on non-Windows machines is using authenticated checks (check ID: apache-log4j-core-cve-2021-44228), which does a complete filesystem search for JAR files matching log4j-core.*.jar. The ‘unzip’ command must be available on systems in order to extract the version from the JAR’s manifest file.
For the find command to run and locate vulnerable JARs, scans must be configured with root credentials in the Site Configuration interface. There is currently no generic JAR detection available on Windows systems.
For Agent-based assessments, assets must be running version 188.8.131.52 of the Insight Agent or later. Use the Agent Management interface to determine the version of the Agent being used in your environment.
2) Remote scanning:
A remote (unauthenticated) check for CVE-2021-44228 was published in a content release with Check ID apache-log4j-core-cve-2021-44228-remote. This check is platform-independent (only option for Windows systems) and works as follows:
If any of the following TCP ports are found open: 80, 443, 8080, 8888 – or, alternatively, if: Nmap service fingerprinting detects HTTP or HTTPS running (note that enabling Nmap service fingerprinting may negatively impact scan times) the Scan Engine will attempt to exploit the vulnerability and make the scan target open a connection to the Engine on port 13456.
The Engine does not open a TCP listener but does a packet capture to identify connection attempts against 13456/TCP. If a connection attempt to the Engine is detected, this indicates that the target is vulnerable, and the check will fire accordingly.
This approach relies on bi-directional networking and requires the scan engine and scan target to be able to “talk” to each other. In some cases, such as scanning through a VPN, NAT, or firewall, that required bi-directional networking is not available.
3) Product-based checks
Many vendors will issue security advisories and patches for the Log4j vlunrability. Users can also adapt the Query Builder or SQL Export to find products of concern to be upgraded, with the caveat that they may not be visible if they use non-standard installation mechanisms.
4) Container Security:
The following link (https://docs.rapid7.com/insightvm/apache-log4j/ ) from Rapid7 provides a detailed guide on how to scan for Log4J. Rapid7 also has a blog (https://www.rapid7.com/blog/post/2021/12/14/using-insightvm-to-find-apache-log4j-cve-2021-44228/ ) that lists the various methods by which Insight VM can help detect Log4j.
To help get started on your journey with Rapid7 InsightVM and other Rapid 7 solutions contact us at firstname.lastname@example.org