10 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
CHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
9.3 High
CVSS2
Access Vector
NETWORK
Access Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:N/AC:M/Au:N/C:C/I:C/A:C
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.
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
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
, apache-log4j-core-cve-2021-44228-2_16
), 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.
Read more about scanning for Log4Shell here or visit our Customer Resource Center.
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:
Source 192.168.1.10 Service TCP 13456 Destination 10.10.190.4
Source 10.10.190.4 Service 80/443/8080/8888 Destination 192.168.1.255
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.
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.
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.
We hope these additions will help InsightVM users respond to the threat of Log4Shell and reduce friction in identifying its impact to their environments.
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:
Get the latest stories, expertise, and news about security today.
Subscribe
10 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
CHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
9.3 High
CVSS2
Access Vector
NETWORK
Access Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:N/AC:M/Au:N/C:C/I:C/A:C