Log4j Zero Day Vulnerability Advisory | December 2021

There’s a new critical vulnerability in the popular Java-based logging package Log4j. The package is widely used which creates the potential for widespread attacks. Here's what you need to know.

Updated:  May, 2022

Summary of Key Updates

📌  We have sunset our free Log4j scan tool since we achieved full adoption among our policyholder base. If you have further questions about Log4j not covered in this article, please email us at the address below. 

The latest Log4j patch is version 2.17.1 (released on 12/28).

Corvus offers a free 60 day trial of SentinelOne's endpoint detection and response (EDR) tool available for Corvus policyholders. Send an email to Services@corvusinsurance.com to request the landing page link.

CIS created a helpful Log4j Vulnerability Response Chart.

Background

On December 9, 2021, a security researcher disclosed a critical vulnerability in the popular Java-based logging package Log4j. The Log4j utility is commonly included in Java based third party software and multiple Apache web frameworks such as ApacheStruts2, Apache Solr, Apache Druid and Apache Flink. The initial reported vulnerability allows unauthenticated users to execute malicious commands on systems. The vulnerability impacts a large number of applications. It can impact both Internet facing systems and possibly internal systems depending on the setup of the system. 

Corvus strongly recommends urgency and diligence in remediating this vulnerability. Working exploit code is publicly available and threat actors are actively scanning and exploiting systems. Additional vulnerable applications and systems will be discovered as time passes.

Quick facts: what you need to know now

  • CVEs:  CVE-2021-44228, CVE-2021-45046, CVE-2021-4104, CVE-2021-42550, CVE-2021-45105, CVE-2021-44832
  • Impacted versions:
    • Version 2 of Log4j between versions 2.0-beta-9 and 2.14.1.
    • Version 1 is End of Life (EOL) and should be updated (it is impacted by CVE-2021-4104).
  • Working exploit code is publicly available and threat actors are actively scanning and exploiting systems.
  • An unauthenticated threat actor can execute arbitrary commands on systems leveraging the vulnerable code. This could lead to the full compromise of the underlying system.
  • Even with diligent patching, it is possible your systems could be compromised. Reviewing your systems for evidence of compromise is essential to determine if you were impacted. 
  • Given the large number of third-party products that leverage the vulnerable code, it is unknown the total impact this could have on your environment. It is highly likely that your organization either uses the Log4j package in your own applications or uses products or vendors that rely on Log4j in their applications.

Next Steps:

We encourage your organization to take the following steps to mitigate against potential attack.

Step 1: Assess your internally developed applications

If you manage an application or technology stack using the Log4j package:

  1. If you are unsure if your code is vulnerable, the following techniques can be used to determine if you are vulnerable: 
    1. Use the following tool on the suspected systems:
      https://github.com/CrowdStrike/CAST
      (for more details on the CrowdStrike tool, read this blog post)
    2. Leverage the Huntress tool to test for the vulnerability. Note that this will run the exploit on your systems. CISA has also released a GitHub Log4j Scanner that combines several tools to scan your environment for the Log4j vulnerabilities.
  2. Implement one of the following mitigation techniques, and be on the lookout daily for additional updates:
    1. Patch to the latest Log4j version:
      1. Java 8 (or later) users should upgrade to release 2.17.1.
      2. Java 7 users should upgrade to release 2.12.3. 
    2. If you’re unable to patch to the latest versions, take the following actions:
      1. Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    3. Ensure you do not enable JNDI in Log4j 2.17.1. If the JMS Appender is required, use Log4j 2.12.3.
    4. In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC). Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

Step 2: Assess third party products

  1. Catalog all third party applications and technology.
  2. Verify whether each one is vulnerable.
    1. This resource contains aggregated vendor statements. CISA is also maintaining a central vendor repository. If a product you use is listed, verify whether it is vulnerable. If it is not listed, review the vendor’s website or contact them to determine if they are vulnerable.
  3. Follow the vendor provided guidance on patching or mitigation. Many impacted vendors have or will release updates in the coming days to address this vulnerability. Just as important as checking your own applications is keeping up with vendor updates.

Step 3: Secure, Monitor, and Investigate

  1. Ensure your network security technology is blocking all known indicators for this vulnerability.
    1. If you leverage a web application firewall (WAF), validate with the vendor that they have signatures to protect against the vulnerability.
  2. Ensure EDR technology is running on all servers. Corvus policyholders have access to a 60 day free trial (and discount thereafter) with SentinelOne. Having EDR deployed and properly monitored will allow organizations to more quickly identify indicators of compromise and potentially stop an attack early on. EDR tools will also allow forensic investigators to identify what the threat actors are doing more quickly, and often allow for quicker recovery of endpoints in a ransomware attack. Email the Risk + Response team to request the landing page link for SentinelOne if you don't currently have an EDR tool in place and want this added layer of protection.
  3. Investigate systems to determine if they are impacted:
    1. The following tool can be used to determine if the system has potentially been compromised: https://github.com/Neo23x0/log4shell-detector. Note that while this will identify exploitation attempts, additional analysis will be required to identify whether it was successful.
    2. If you leverage an EDR solution, scan the systems to search for malicious files. EDR vendors should be providing information on how to leverage the tool to identify potential compromise related to Log4j.
    3. Review systems for suspicious outbound communication.
    4. Review systems for the installation of malicious files. This could include scripts, webshells, or executable files.

Identifying the Presence of the Vulnerability and Exploitation Attempts

The following resource has different search terms to use to identify exploitation attempts and potentially vulnerable servers.

https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Looking for a visual to help with your response? CIS created a helpful flowchart related to Log4j vulnerability response.

Additional Resources

https://www.bleepingcomputer.com/news/security/log4j-2171-out-now-fixes-new-remote-code-execution-bug/

https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j

https://www.randori.com/blog/cve-2021-44228/

https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

https://www.lunasec.io/docs/blog/log4j-zero-day/

CISA Log4j (CVE-2021-44228) Vulnerability Guidance

 

If you have any questions, please reach out to the Risk + Response Team at services@corvusinsurance.com!