Using InsightVM to Find Apache Log4j CVE-2021-44228

Last updated at Wed, 29 Mar 2023 23:22:24 GMT

Last updated: February 23, 2022

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 is via our authenticated checks (check IDs: apache-log4j-core-cve-2021-44228-2_16, apache-log4j-core-cve-2021-44228-2_12_2, apache-log4j-core-cve-2021-44228-2_3_1), which perform a complete filesystem search for JAR files matching log4j-core.*.jar. The authenticated checks support both Linux and Windows scanning as of version 6.6.121 released December 17, 2021. Note: Searching entire file systems across Windows assets is an intensive process that may increase scan time and resource utilization. To allow this, you can enable Windows file system searching in the scan template in order to use the authenticated check for Log4j on Windows systems.

In addition to enabling Windows file system search, WMI must be enabled for the authenticated check to run in Windows environments. The check looks for Log4j version information in the JAR filename. On Linux systems, when the unzip command is available, that command is used to extract the version from the JAR's manifest file. There is also a fallback mechanism that allows the scanner to attempt to extract the version information from the filename. Customers should ensure they are running version 6.6.121 of the Scan Engine and Console.

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. On Windows systems, scans should run with local administrator privileges for the most comprehensive results.

Windows scanning functionality requires product version 6.6.121 or later. Insight Agent collection on Windows for Log4j has begun rolling out in version 3.1.2.38 as of December 17, 2021. It will take several days for this roll-out to complete. If you are using the Insight Agent to assess your assets for vulnerabilities and you are not yet on version 3.1.2.38, you can uncheck the “Skip checks performed by the Agent” option in the scan template to ensure that authenticated checks run on Windows systems. Use the Agent Management interface to determine the version of the Agent being used in your environment.

As of January 25, 2022, the scanner will also take into account whether the mitigation of removing the JndiLookup class from vulnerable JAR files has been applied. The regular vulnerability will not be reported in these cases; however, a new vulnerability (apache-log4j-core-jndilookup-mitigated), which carries a CVSS score of zero, is available to flag files that have not been updated but have had the vulnerable class removed. Mitigation detection is also available on Windows systems as of version 6.6.128. The Insight Agent also supports mitigation detection on Windows, Linux, and macOS.

Read more about scanning for Log4Shell here or visit our Customer Resource Center.

Remote scanning

IMPORTANT: For the unauthenticated remote check to correctly identify log4shell occurrences in your environment, target assets must be able to communicate back to your scan engine on port 13456.

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 (will work against Linux, Windows, and other operating 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. No data is returned from the scanned asset itself; the Engine is only monitoring for connection attempts, and not any additional data.
• 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.

Further information on enabling bi-directional communication

1. Create a rule in your firewall (or Layer 3 switch) to allow your Windows Asset / Network Segment (so in this case 192.169.1.10) to respond BACK to your Scan Engine (10.10.190.4) on TCP 13456.
   Source 192.168.1.10 Service TCP 13456 Destination 10.10.190.4
2. You should already have a Rule from your Scan Engine to allow scan on ports 80,443,8080 and 8888 to your Windows Asset / Network Segment.
   Source 10.10.190.4 Service 80/443/8080/8888 Destination 192.168.1.255
3. If you are not seeing any response back or seeing that you are finding ZERO vulnerabilities it is very possible that the issue is with the firewall rule (or network configuration). Check your firewall logs for any drops from the Windows Asset on Port 13456 attempting to talk to your Scan Engine. Also make sure that your Scan Engine is allowed to make the request to your Network Segments on ports 80,443,8080,8888 to initialize the trap/attack.

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.

As of February 4, 2022, there are several product-specific checks:

• Package manager (authenticated) checks based on advisories published by various Linux distributions such as Debian, Amazon Linux, SUSE, and Ubuntu.
• A product-specific authenticated check for VMware Workspace ONE Access
• A product-specific remote check for VMware vRealize
• A product-specific check for VMware Horizon Connection Server that is a bit unusual, as it uses system authentication to determine the patch level in conjunction with a remote detection to determine whether the vulnerable service is running. (The remote detection does not rely on the callback mechanism described above.) There is also a product-specific check available for VMware Horizon Agent.

Specific vulnerability dashboard and Log4j helpful query

Rapid7 released the Specific Vulnerability Dashboard template and the “Log4j by CVE ID” helpful query in the Query Builder on Tuesday, December 13, 2021. Our intent is to allow customers to quickly and easily report on the Log4j vulnerability. More importantly, this gives us a dashboard template that we can leverage in the event of other urgent vulnerability notices.

The Helpful Query searches a customer’s environment for Log4j via the corresponding CVE ID (not paradoxically). Users can apply this query to the Specific Vulnerability dashboard template to create a view into how their environment is being affected.

Follow these steps to create and focus this new dashboard template on Log4j.

• Navigate to the query builder.
  • Click on the add button.
  • Go to the helpful queries section and select the Log4j by CVE ID query.
    
  • Click the Select Query button.
  • Click Save As for the new query.
    • Give the query a name.
• Click the Save button.
• Go to the Dashboards page.
  • Click on the Down Arrow next to the Dashboard name.
  • Select Specific Vulnerability Dashboard.
    
  • Edit the information provided if desired
  • Click the OK button
• To filter the dashboard for Log4j
  • Click the Load Dashboard Filter button
  • Search for your saved Log4j query
  • Click on the name of the query
    

InsightVM users may also create a report that’s based on the Specific Vulnerability dashboard template and have this generated on a recurring basis (N number of days, weeks or months). Follow these steps in order to create this report.

• Navigate to the query builder.
  • Click on the Add button.
  • Go to the helpful queries section and select the Log4j by CVE ID query.
    
  • Once loaded, click the Create Report button.
  • In the report wizard, select Pre-built Reports as the report type.
    
  • From the list that appears, select Specific Vulnerability Dashboard.
    
  • Enter in the relevant information in the Configure selection.
    • Select "I want to schedule and run a recurring report" to have the report generated multiple times.
    • Click the checkbox titled “Permit users who do not have access to console,” and enter an email address or addresses to have this report automatically delivered as it’s generated.
  • Once ready, click the Save and Complete button

We hope these additions will help InsightVM users respond to the threat of Log4Shell and reduce friction in identifying its impact to their environments.

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. Retrieve results via the Container API or the Containers Dashboard: