CISO Update: What We Know About the Log4j Vulnerability

Updated Monday December 13, 10:45 am ET

On December 10, 2021, Apache published details of the CVE-2021-44228 vulnerability in the Log4j utility — an open source Java package managed by Apache. For background, the Log4j utility is a popular logging package that many applications use. With many applications, as users interact with it, the application will log the various actions that are taking place. This is useful for when administrators need to troubleshoot the application or system.

📌 Interested in learning more about our Log4j vulnerability discovery tool or looking for the latest updates? See the bottom of this page for more info on our Log4j resources. 

What’s the Expected Impact of the Log4j Vulnerability? 

The vulnerability that was published occurs when a specific series of characters are logged with the Log4j logging package. Knowing how web applications work and log-specific activity, threat actors have identified ways to configure web requests to web applications that include the specific set of characters. When that happens, the threat actors are able to execute commands and gain control of the server.

This might seem par for the course. You'd be forgiven for thinking, “oh great, just another vulnerability to deal with. I’ll follow my patching best practices and call it a day."

Not so fast. Here’s the issue. There are a lot of applications that use the vulnerable logging package. Not only do you need to be concerned with your own applications, but also any third party applications you are using that might be storing your data or have access into your environment. Suffice to say, we are in the first inning of a very long ball game where new vendors will be coming forward with new patches for you to apply.

Early indications are calling this one of the greatest Internet vulnerabilities in the last seven years (anyone remember Heartbleed or ShellShock?).

In other words, this is a big deal and should be taken as such. Working exploit code is already public. Threat actors are already scanning the Internet for vulnerable systems. It is only a matter of time before that access is turned into other forms of malicious activity, such as deploying ransomware.

What Are the Next Steps in Dealing with Log4j Vulnerability?

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: 

   • Use the following tool on the suspected systems:

     • https://github.com/mergebase/log4j-detector

   • Use one of the following commands: 

     • Windows PowerShell: gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path

     • Linux: find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}"

   • Search for the file hashes listed here to determine if you are vulnerable.

   • Leverage the Huntress tool to test for the vulnerability. Note that this will run the exploit on your systems. 

2. Upgrade to the latest version Log4j v2.15 (this will fix the vulnerability).

3. If you are using a vulnerable version and cannot upgrade, do one of the following:

   • For releases >=2.10: Set the property “log4j2.formatMsgNoLookups” or “LOG4J_FORMAT_MSG_NO_LOOKUPS” to “true”.

   • For releases 2.0-beta9 to 2.10.0: Remove the JndiLookup class from the classpath. This can be done using the command:

     • zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Click here for additional information on mitigations.

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. If your product 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.

• If you leverage a web application firewall, validate with the vendor that they have signatures to protect against the vulnerability.

2. Ensure EDR technology is running on all servers.

3. Investigate systems to determine if they are impacted:

• The following tool can be used to determine if the system has potentially been compromised: https://github.com/Neo23x0/log4shell-detector

4. Monitor log files for the string "{jndi". This represents scanning activity which could lead to the compromise of the system. Detection techniques are available here.

1. • Review systems for suspicious outbound communication.

   • Review systems for the installation of malicious files. This could include scripts, webshells, or executable files.

More Log4j Resources from Corvus

• In collaboration with CrowdStrike, we've released a Log4j vulnerability discovery solution to help organizations achieve greater certainty they have located and patched every instance of the Log4j utility. Policyholders can request a scan here (or read more about the tool first).

• Refer to the Corvus Knowledge Nest article related to this vulnerability for the latest updates and recommendations. That is the first place we'll publish any changes to guidance. 

Additional Resources on Log4j 

• Cloudflare blog post

• LunaSec blog post

• Randori blog post