December 22, 2021 • RBS

Categories: Security News

In our last article, we dissected “Log4Shell”, explaining its attack surface, variants, and how organizations can begin to remediate it. But in just a week, our VulnDB entry for Log4Shell has expanded considerably, being updated hundreds of times a day, with almost 1000 references and thousands of affected products.

What are the new details that you should know? Well, stick around so we can get you up to speed.

In This Article:
Understanding Log4Shell and Its Variants
Remediating Log4Shell
Prioritizing Log4Shell
Future Log4Shell Vulnerabilities
Preparing for What Comes After Log4Shell

Understanding Log4Shell and Its Variants

Much like the Time Variance Authority, variants are proving to be quite problematic. As more CVE Assignments are being given to Log4j related issues, some organizations and vendor disclosures have conflated the multiple issues as one, making it difficult to understand what the issue actually is, or who/what is affected. At the time of writing, there are currently five distinct CVE Assignments, with more surely to follow. Here is what you should know about these Log4j related vulnerabilities:

  • CVE-2021-44228
    • This is the original Log4Shell vulnerability that started it all. This is also the specific issue that the press and security industry is focusing on.
  • CVE-2021-45046
    • It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.
  • CVE-2021-4104
    • This variant was one of the main discussion points in our first joint webinar with Flashpoint.
    • JMS Appender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration.
    • This is a much lower severity, local issue.
  • CVE-2021-45105
    • This is a new Denial of Service vulnerability that was disclosed on December 18.
    • Uncontrolled recursion from self-referential lookups
    • CVSSv2 = 7.1 and CVSSv3 = 7.5
    • Java 8 (or later) users should upgrade Log4j to release 2.17.0
      • Alternatively, this can be mitigated in configuration:
      • 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.
  • CVE-2021-4125
    • Currently in RESERVED status.
    • It is fair to include this as a log4j vulnerability, but note that it’s not specifically for upstream log4j.
    • This is an incomplete fix only in the OpenShift metering hive containers:
      • Only applies to the OpenShift metering hive container images, shipped in OpenShift 4.8, 4.7, and 4.6.
    • This vulnerability is sparking talk about new, or different attack vectors.
      • Need to keep in mind that this CVE is a library issue.
        • Anyone with a vulnerable version of Log4j can potentially trigger this vulnerability.

One important point to keep in mind is that two of the new CVEs have been assigned for “incomplete fixes”, as some assignments are just trying to fix the main core Log4Shell issue. As such, CVE-2021-44228, CVE-2021-45105, and CVE-2021-4104 should be considered as the only distinct Log4Shell vulnerabilities at this time.

Remediating Log4Shell

Organizations have had a tough time with Log4j over the past week as multiple fixes have been published, with some of them having issues of their own. Here’s a quick recap:

  • 2.15.0
    • This was the initial fix that was published.
  • 2.15.1
    • Released in response to disable JNDI access by default.
  • 2.16.0
    • A more comprehensive fix that removes the problematic message lookups functionality.
    • Customers not requiring JDNI access or message lookups are strongly encouraged to update to this or a newer version.
  • 2.17.0
    • Released on December 17, this is currently the latest version with all fixes.
    • According to Apache, released because version 2.16 “does not always protect from infinite recursion in lookup evaluation”.

If your organization hasn’t started or has just begun the process of updating Log4j, you need to start. If possible, you should update to 2.17.0 to ensure that systems aren’t susceptible to CVE-2021-45105.

In the span of less than a week, the number of affected products has increased from 200 to 900 and this number is likely to increase as our research teams process new advisories. Unfortunately, we are also seeing quite a bit of vulnerability disclosures from vendors that contain conflicting information and an estimated 34k GitHub repos that might need to be updated/fixed.

These will likely require different patches to correct and this will likely add a considerable amount of time to the remediation process. But other than having vendors clean up their advisories themselves, the best way for you to navigate through the confusion is to understand each Log4Shell variant and log4j related vulnerability.

Prioritizing Log4Shell

Having a grasp of what all the Log4j CVE Assignments are helps you keep a level head while you figure out which assets are affected. Since this is a library vulnerability, you need to ask yourself three things:

  1. Am I using the Log4j library in my own code?
  2. Are we using a vendor or library that includes Log4j?
  3. Are we using a managed service that uses Log4j?

Finding those answers will help you take a risk-based approach to dealing with Log4j related issues. Rather than wasting time and resources trying to find and fix every asset, you can instead focus on securing the ones that have the most impact and then move down in priority.

If you’re still having difficulty determining your organization’s attack surface in regards to Log4Shell, there are ways to find out where your organization might be vulnerable.

1. Software Bill of Materials (SBOM)

With Log4Shell being a library vulnerability, a Software Bill of Materials (SBOM) is extremely valuable since they list the various third-party libraries, open-source or commercial, that are used in software components. If your organization has been implementing this process, then you are better off compared to the many that haven’t.

For those that haven’t put SBOM into practice, this is actually a great time to start. Without this process in place, you will likely be spending a lot of time dissecting each of your deployed software anyways. So why not kill two birds with one stone and formally start the process? Rest assured this has not been, and will not be, the only critical library vulnerability you have to contend with.

2. Configuration Management Database (CMDB)

A CMDB can facilitate a risk-based approach since it helps you understand your assets by informing which software is being run on them and where they fit in your IT infrastructure. When paired with SBOM, this should provide you with most of the information you need.

But if you haven’t maintained your CMDB or don’t have one, you should use Log4Shell as an opportunity to start that process. During your research you will be capturing information like Affected Products, versions, and location, so take the time to consolidate this data into your new CMDB.

3. Scanning

Yes, we are aware that we recently published an article that details the deficiencies of vulnerability scanning. Scanning is a helpful tool and certainly has value, especially when you need to uncover unknown assets in your network. It just shouldn’t be the cornerstone of your vulnerability management program.

If you are one of the organizations that do not have SBOMs or a functional CMDB, you may want to consider this option. You will need to make sure that the scanner you choose has a signature written for every Log4Shell variant or at least make sure the scan doesn’t conflate every Log4j vulnerability as one issue. However, keep in mind that at the time of writing, CVE-2021-4125 is currently in RESERVED status. So this means that scanners sourcing from CVE/NVD won’t include this issue in their scans.

As long as you’re not treating scan reports as “end-all-be-all”, scanning should supplement your vulnerability management program. There are open source tools out there from vendors like JFrog and Arctic Wolf that can be useful in uncovering at-risk assets.

4. Risk Scores

Once you surface your at-risk assets, risk scores are what actually enable you to prioritize and take a risk-based approach. An asset risk score is a numerical value that represents the asset’s overall importance to the organization based on use, type of data stored, likelihood of being exploited, and its exposure to vulnerabilities.

You can calculate it with this formula:

Asset Value x Threat Likelihood x Vulnerability Exposure

Ultimately, you need to be able to map your Log4Shell vulnerabilities with your assets, and then be able to understand which of them require the most attention. This will give you focus and help you make the best of limited resources.

Mission critical systems, internet-facing systems, and other important assets will likely have the highest scores so start there and work down. Following this approach will ensure that your organization is best equipped against potential attacks and will lessen the impact to you and your customers.

Future Log4Shell Vulnerabilities

Implementing a risk-based approach is essential since it is likely that Log4Shell will not go away soon. Like we mentioned before, there is a lot of conflicting information out there in the form of vendor disclosures and GitHub repos, so there will be even more confusion as those resources are updated and fixed. Trust us, some vendor advisories are extremely confusing, some have contradictory information, and ten days later some are still “pending” more information as to the status of their products.

However, the thing that organizations should prepare for is the increased attention from vulnerability researchers. It is likely that the issues found so far only scratches the surface.

Security professionals may be shocked to know that the Log4Shell vulnerability was introduced to the Log4j codebase in July 2013 as part of the implementation of LOG4J2-313. CVE-2021-44228 was disclosed on December 10, 2021. Doing math, this means that these issues have gone unnoticed for over eight years. With as many as three billion devices affected, does this mean that malicious attackers could have been using Log4Shell this whole time? It is very possible.

To make matters worse, Log4j is an open source library and therefore, anyone could have found it. So why didn’t anyone report it? We’ve done a lot of research in this space (we’ve even published our own research too), and this situation is quite typical. This is yet another example disproving the notion that “With a thousand eyes, all defects are shallow“. Quite simply, thousands of eyes aren’t auditing these open source projects.

Vulnerability researchers are people, and like for everyone else, incentives play a large role in human behavior. Anything considered interesting will naturally get more attention; that is why well-known vendors and products tend to have “more vulnerabilities”. Once you also factor in bug bounties and other incentives, it makes sense that researchers may not spend a lot of time vetting an open source library.

But now that Log4j is getting a lot of attention, expect this to change. Researchers now have a plethora of reasons to dive deep into the Log4j code so don’t be surprised if even more vulnerabilities are found.

Preparing for What Comes After Log4Shell

Even though Log4Shell is in contention for being the “worst vulnerability of all time”, it doesn’t mean that every other issue being disclosed is a pushover. New vulnerabilities are disclosed every day, and there are likely many that will require your attention. So what else has been going on?

Well, 543 vulnerabilities have been disclosed since Log4Shell’s publishing on December 10. Burdened with glorious purpose, Microsoft released a Patch Tuesday where 31 vulnerabilities had a CVSSv2 score of 10.0, and also included CVE-2021-43890, a Windows 10 vulnerability that was already being exploited in the wild. The following is a breakdown of the latest Patch Tuesday:

  • 71 in Microsoft products
  • 60 in Adobe products
  • 60 in Apple products
  • 48 in Siemens products
  • 20 in IBM products
  • 16 in SAP products
  • 12 in Schneider Electric products
  • Etc etc etc
  • 194 (32.9%) had a remote attack vector
  • 86 (15.8%) have public exploit information available
  • 365 (61.8%) have an integrity impact
  • 127 (22.8%) have a confidentiality impact

The point of this isn’t to downplay Log4Shell, but it is to show the volatility of the vulnerability disclosure landscape. It is vital that security teams don’t get lost in Log4Shell and are at least aware of new major issues being disclosed.

Implementing a risk-based Vulnerability Management program enables organizations to proactively address issues, instead of being forced to react to them. But in order to accomplish this, security teams will need comprehensive, detailed, and timely vulnerability intelligence that is contextualized to their environment.

Read more about Log4j and Log4Shell:
Log4Shell: log4j Vulnerability, Attack Surface, Variant and Remediation
Flashpoint Community Call: Log4J Vulnerability
Log4j: What You Need to Know
Log4Shell: How “Big” Is It?
Our products
The Platform
Risk Based Intelligence
Learn more
Vulnerability Intelligence
Learn more
Cyber Risk Analytics
Threat Intelligence
Learn more
Risk Management
Learn more