Apache Log4j

About this guide

This guide walks through detecting and reporting on CVE-2021-44228. The same steps can be used for additional checks related to Log4Shell such as CVE-2021-45046 and CVE-2021-45105.

Rapid7's response to Apache Log4j vulnerabilities (Log4Shell)

Rapid7 is continuously monitoring our environment for Log4Shell vulnerability instances and exploit attempts. At this time, we have not detected any successful exploit attempts.

- For further information and updates about our internal response to Log4Shell, see our blog post.
- For in-depth analysis on the vulnerability and its attack surface area, see the AttackerKB article.

Where did this vulnerability come from?

On December 6, 2021, Apache released version 2.15.0 of their Log4j framework, which included a fix for CVE-2021-44228, a critical (CVSSv3 10) remote code execution (RCE) vulnerability affecting Apache Log4j 2.14.1 and earlier versions. The vulnerability resides in the way specially crafted log messages were handled by the Log4j processor. Untrusted strings (e.g. web application search boxes) containing content like ${jndi:ldap://example.com/a} would trigger a remote class load, message lookup, and execution of the associated content if message lookup substitution was enabled.

On December 13, 2021, Apache released Log4j 2.16.0, which no longer enables lookups within message text by default.

What is the impact of this vulnerability?

Successful exploitation of CVE-2021-44228 can allow a remote, unauthenticated attacker to take full control of a vulnerable target system. CVE-2021-44228 is being broadly and opportunistically exploited in the wild as of December 10, 2021. Multiple sources have noted both scanning and exploit attempts against this vulnerability. Rapid7 researchers have developed and tested a proof-of-concept exploit that works against the latest Struts2 Showcase (2.5.27) running on Tomcat. We expect attacks to continue and increase: Defenders should invoke emergency mitigation processes as quickly as possible. CISA has also published an alert advising immediate mitigation of CVE-2021-44228.

A huge swath of products, frameworks, and cloud services implement Log4j, which is a popular Java logging library. Organizations should be prepared for a continual stream of downstream advisories from third-party software producers who include Log4j among their dependencies.

Detecting Log4Shell vulnerabilities

You can scan your environment for Log4Shell vulnerabilities with a customized scan template and quickly determine and report on impact using the Specific Vulnerability dashboard template.

Product version 6.6.121 includes updates to checks for the Log4j vulnerability. After installing the product and content updates, restart your console and engines.

Step 1: Configure a scan template

You can copy an existing scan template or create a new custom scan template that only checks for Log4Shell vulnerabilities.

  1. Make a copy of the "Full audit without Web Spider" scan template.

    1. In your security console, go to the Administration tab.

    2. Under the Scans area, click Manage scan templates.

    3. In the Full audit without Web Spider scan template row, click the Copy scan template icon.

    4. On the General tab, enter an easily identifiable name, such as Apached Log4j.

      Copy scan template

  1. (Optional) Enable scanning on Windows devices using the authenticated check.

    For authenticated scanning in Windows environments, you need to enable Windows file system search in the scan template to allow scan engines to search all local file systems for specific files.

    1. On the General tab, select the Enable Windows File System Search checkbox.
    2. Review the warning text to determine whether you want to enable this option.
    3. To enable this feature, click Yes. To cancel enabling, click No.

    Searching file systems increases scan time and resource utilization

    Searching entire file systems across all of your Windows assets is an intensive process that increases scan times and resource utilization.

  1. (Optional) Enable Nmap Service Detection to scan additional ports using the unauthenticated check.

    To use an unauthenticated check to detect Log4Shell on assets that use HTTP(S) on alternative ports, enable Nmap Service Detection.

    1. On the Service Discovery tab, select the Nmap Service Detection checkbox.

    Nmap Service Detection may extend scan times.

    Nmap Service Detection may negatively impact scan times.

  1. On the Vulnerability Checks tab, customize your checks.
    1. Expand the By Category dropdown and click Add Categories.
    2. Select Apache Log4j and click Save.
    3. (Optional) If you're also using the Insight Agent to assess for vulnerabilities, improve efficiency by allowing the scan engine to Skip checks performed by the Agent.
  1. Click Save at the top right corner of the Scan Template Configuration.

Log4j vulnerability scan template

Step 2: Scan your network

Prepare for and understand authenticated and unauthenticated (remote) checks

  • Authenticated: apache-log4j-core-cve-2021-44228-2_12_2 and apache-log4j-core-cve-2021-44228-2_16 authenticated vulnerability checks perform a complete filesystem search for JAR files matching log4j-core.*.jar.

    Prepare for scanning with the authenticated check

    You must add a root credential to site configuration for all checks that require authentication. Scanning Windows systems using the authenticated check requires that WMI be enabled.

    1. Edit one or more site configurations by adding a root credential (either directly or with a privilege elevation mechanism).

  • Unauthenticated: apache-log4j-core-cve-2021-44228-remote unauthenticated vulnerability check attempts to trigger a connection back to the scan engine to determine vulnerability.

    Prepare for scanning with the unauthenticated check

    The unauthenticated (remote) check is platform-independent and relies on a bidirectional connection with port 13456. The scan engine attempts to run the Log4Shell check against TCP ports 80, 443, 8080, and 8888 to determine if they are open. If ports are open, the scan engine attempts to exploit the vulnerability and make the scan target open a connection to the engine on port 13456.

    If Nmap Service Detection is enabled in the scan template, you can add more ports. Nmap Service Detection may negatively impact scan times.

    log4j Remote scanning workflow

    1. Create a rule in your firewall (or Layer 3 switch) to allow your Windows Asset / Network Segment (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

      • You should already have a rule from your scan engine to allow scanning 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

      • If you are not seeing any response back or finding zero vulnerabilities, check firewall logs for the Windows Asset / Network Segment that is attempting to talk to your scan engine on Port 13456. Ensure that your Scan Engine is allowed to make the request to your Network Segments on ports 80, 443, 8080, and 8888 to initialize the trap/attack.

Scan your network with the new scan template

The following steps use CVE-2021-44228 as the example. The same steps can be used for additional checks related to Log4Shell such as CVE-2021-45046 and CVE-2021-45105.

  1. Run a scan with the scan template you updated or created.
  2. When the scan completes, in the Security Console, search for CVE-2021-44228.
  3. To continually monitor any assets that are vulnerable to Log4Shell, create a Dynamic Asset Group based on the same CVE ID you searched for.
    Your filtered asset search looks for exact matches to the CVE ID itself (CVE ID = is = CVE-2021-44228).

Other ways to detect Log4Shell in your environment

Insight Agent assessment

We are rolling out Insight Agent version 3.1.2.38, which includes collection support for Log4j JAR files so that vulnerability assessments of the authenticated check for CVE-2021-44228 will work for updated agent-enabled systems.

If you rely on the Insight Agent for vulnerability management, consider setting the Throttle level to High (which is the default) to ensure updates are applied as quickly as possible. For more information, see Agent Management Settings in the Insight Agent documentation.

Limitations

To reduce the impact on agent-enabled systems, the timeout for this search is 10 minutes. On very busy machines with large numbers of files, the check will not result in found vulnerabilities.

This search relies on the WMI service. If this service is disabled on machines, the search will not run.

Container Assessments

InsightVM customers utilizing Container Security can assess containers that have been built with a vulnerable version of the library.

Step 3: Report on the impact of Log4Shell

Use the Specific Vulnerability dashboard with the Log4j query

This report shows the presence and impact of a specific vulnerability or vulnerabilities in your environment.

  1. In Query builder, apply the Log4j vulnerability by CVE ID query.
    1. In the Helpful Queries section, select log4j vulnerability by CVE ID.
    2. Click Apply Query.
    3. When the query loads, click Save.
  2. In the Dashboard tab, click the dashboard dropdown menu and select the Specific Vulnerability Dashboard.
  3. On your new dashboard, click Load Query.
  4. Select log4j vulnerability by CVE ID.
  5. Review the results to determine impact.

Specific vulnerability dashboard

Find other affected software

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.

You can also adapt the Query Builder or SQL Export queries provided below to find products of concern in the meantime, with the caveat that they may not be visible if they use non-standard installation mechanisms.

Create a query to use in dashboards

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.

Query Builder for log4j in applications

Generate a SQL query report
You can use a **SQL query** to report on CVE-2021-44228 in your network.

  1. In the Security Console, click Reports.

  2. In the Create a Report section, name your report and select the Export tab.

  3. Navigate to and select the SQL Query Export template. You can also filter for the template by typing sql in the template search field.

  4. In the template, in the Query field, enter the following SQL script:

     
    1
    SELECT
    2
        da.sites AS "Site_Name",
    3
        da.ip_address AS "IP_Address",
    4
        da.mac_address AS "MAC_Address",
    5
        da.host_name AS "DNS_Hostname",
    6
        ds.vendor AS "Vendor",
    7
        ds.name AS "Software_Name",
    8
        ds.family AS "Software_Family",
    9
        ds.version AS "Software_Version",
    10
        ds.software_class AS "Software_Class"
    11
    FROM
    12
        dim_asset_software das
    13
    JOIN
    14
        dim_software ds USING(software_id)
    15
    JOIN
    16
        dim_asset da ON da.asset_id = das.asset_id
    17
    WHERE
    18
        ds.software_class like'%'
    19
      AND
    20
        ds.name ilike '%log4j%'
    21
    ORDER BY
    22
        ds.name ASC

  5. Click Validate to test that the script will be read correctly.

  6. (Optional) If you want to report on a specific scan, site, or asset group, you can define the scope of the report just below the query field.

  7. (Optional) Click Preview to retrieve the first ten records that respond to the query. When you're finished previewing, click Done.

  8. Click Save & Run the Report.

Detect mitigation

You can automatically detect whether the JNDILookup class was removed from log4j-core.jar files on Unix and Windows systems to mitigate Log4Shell vulnerabilities. The mitigation detection can help reduce false positives.

Prerequisites

  • Linux
    • SSH is enabled
    • Bash is the default shell
  • Windows
    • WMI (port 135) is enabled on targets. This is required for the scan engine to be able to search for log4j-related JAR files.
    • Either SMB (port 445) or WINRM (port 5986) is enabled on targets. This is required for the scan engine to detect the JNDILookup class removal mitigation.

Mitigation check results

In all identified log4j-core.jar files, InsightVM looks for JNDILookup in the class path: org/apache/logging/log4j/core/lookup/JndiLookup.class

  • If the JNDILookup class is not in the log4j-core.jar file, a new zero-risk vulnerability is visible with one of the following vulnerability IDs:
    • Unix: apache-log4j-core-jndilookup-mitigated
    • VMWare vCenter: vcenter-log4j-vmsa-2021-0028-9-mitigated
  • If the JNDILookup class is detected in the log4j-core.jar file, the result is VULNERABLE.
  • If InsightVM did not inspect the contents of the log4j-core.jar, the result is VULNERABLE.