Post Syndicated from Greg Wiseman original https://blog.rapid7.com/2021/12/14/using-insightvm-to-find-apache-log4j-cve-2021-44228/

There are many methods InsightVM can use to identify vulnerable software. Which method is best depends on the software and specific vulnerability in question, not to mention variability that comes into play with differing network topologies and Scan Engine deployment strategies. When it comes to a vulnerability like CVE-2021-44228, affecting a software library (Log4j) that is used to build other software products and may not expose its presence in an obvious way, the situation gets even more complicated. For in-depth analysis on the vulnerability and its attack surface area, see AttackerKB.

The intent of this post is to walk InsightVM and Nexpose users through how to best approach detecting exposure to Log4Shell in your environment, while providing some additional detail about how the various checks work under the hood. This post assumes you already have an operational deployment of InsightVM or Nexpose. For additional documentation on scanning for Log4j CVE-2021-44228, take a look at our docs here.

Before (or while) you scan

Even before a vulnerability check has been made available, it can be possible to get a sense of your exposure using InsightVM features such as Query Builder, or Nexpose’s Dynamic Asset Groups. Because we use generic fingerprinting techniques such as querying Linux package managers and enumerating software found in Windows Registry uninstaller keys, the software inventory for assets may include products that are not explicitly supported. Using the search predicate software.product CONTAINS log4j will show packages on Linux systems that have been installed via package managers such as rpm or dpkg.

An alternative approach to this is using an SQL Query Export using the following query:

SELECT
    da.sites AS "Site_Name",
    da.ip_address AS "IP_Address",
    da.mac_address AS "MAC_Address",
    da.host_name AS "DNS_Hostname",
    ds.vendor AS "Vendor",
    ds.name AS "Software_Name",
    ds.family AS "Software_Family",
    ds.version AS "Software_Version",
    ds.software_class AS "Software_Class"
FROM
    dim_asset_software das
JOIN
    dim_software ds USING(software_id)
JOIN
    dim_asset da ON da.asset_id = das.asset_id
WHERE
    ds.software_class like'%'
  AND
    ds.name ilike '%log4j%'
ORDER BY
    ds.name ASC

Authenticated and agent-based assessments

The most reliable way to find vulnerable instances of CVE-2021-44228 on non-Windows machines as of December 13, 2021 is via our authenticated check (check ID: apache-log4j-core-cve-2021-44228), which does a complete filesystem search for JAR files matching log4j-core.*.jar. At this time, the unzip command must be available on systems in order to extract the version from the JAR’s manifest file. An upcoming release (expected December 15) will add the capability to extract the version information from the filename if available.

For the find command to run and locate vulnerable JARs, scans must be configured with root credentials (either directly or via a privilege elevation mechanism) in the Site Configuration interface. There is currently no generic JAR detection available on Windows systems.

This functionality requires product version 6.6.118 or later. For Agent-based assessments, assets must be running version 3.1.2.36 of the Insight Agent or later. Use the Agent Management interface to determine the version of the Agent being used in your environment.

Remote scanning

A remote (unauthenticated) check for CVE-2021-44228 was published in a content release on December 12 9pm ET with Check ID apache-log4j-core-cve-2021-44228-remote. This check is platform-independent (and currently the 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)
• THEN 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.

Note: We have received some reports of the remote check not being installed correctly when taking a content update. Product version 6.6.119 was released on December 13, 2021 at 6 PM EST to ensure the remote check is available and functional.

Product-based checks

We know that many downstream vendors will issue security advisories of their own in the coming days and weeks. We continue to monitor several vendors for related security advisories. We will have checks for affected products included in our recurring coverage list as vendors provide details about affected and/or fixed versions. Users can also adapt the Query Builder or SQL Export queries provided above to find products of concern in the meantime, with the caveat that they may not be visible if they use non-standard installation mechanisms.

Container security

Customers who are worried about vulnerable images in their container repos have been able to scan for CVE-2021-44228 using InsightVM’s Container Security since December 10 at 2pm ET, thanks to our integration with the Snyk vulnerability database. It is also possible to rerun an assessment on any images that are particularly sensitive to be sure of up-to-date results.