Proactive cybersecurity with eruditeMETA: Log4j use case review

Kristen
Feb 23, 2022
4 min read

Updated: Mar 22, 2022

(Originally posted February 22, 2022. See footer for reference.)

Abstract

With the rise of cybersecurity incidents, proactive processes in addressing cybersecurity are needed now more than ever. While it is not always possible to stop vulnerabilities from making their way into your production systems, following the practices outlined in a secure software development life cycle and supply chain is an extremely effective way to ease response and remediation. Through the automation of basic requirements for most regulatory standards, eruditeMETA can make this a reality. This can be demonstrated using the recent Log4j vulnerability as an example.

Introduction

eruditeMETA is a platform aimed at providing complete visibility into an organization's secure software supply chain. While it accomplishes this goal through a combination of features and integrations, arguably the most important features are the ones which can assist in responding to an incident once a vulnerability has been identified.

Background

While the full feature list is increasing, eruditeMETA offers two (2) particular features that greatly impact the effort in responding to cybersecurity incidents:

Software Composition Analysis (SCA), and
CVE Vulnerability Analysis.

In the case of the massive vulnerability associated with Log4j in late 2021, remediation could be reduced to a fraction of the time —and eruditeMETA's platform can pay for itself with less than a single instance.

What are these features?

Software Composition Analysis (SCA) is not a new concept, and many products exist in the marketplace focusing solely on this segment of application security. SCA tools perform automated scans of an application's code base, including related artifacts such as containers and registries, to identify all open-source components.

Most SCA tools were a response to the revolution around the use of open-source code, components, and libraries. The premise is that software now includes software developed "in the wild" by developers who are not internal employees or consultants. Because of the lack of control and oversight in that process and the outcome being used, it is necessary to identify each component in use. That is an absolutely valid use case.

While other products focus on identifying open-source components, they fail to look as deeply at the other components in use, either internal and bespoke or commercially available. They largely neglect to consider that the commercially available packages are created by other organizations, i.e., other organizations just like themselves... potentially using open-source components as well.

What differentiates eruditeMETA's features is a matter of scope. We do not only mistrust open-source developers and providers; we do not trust anyone —including our internal employees. (We are using the word "mistrust" in a somewhat "tongue-in-cheek" way.)

We take zero trust to a whole new level. Our SCA feature not only identifies open-source components; it identifies all components. The feature continues in a recursive fashion to follow the digital thread until it reaches a point through which it can no longer be traversed. We consider anything else to be a less than comprehensive list.

CVE (Common Vulnerabilities and Exposures) Analysis picks up where our SCA feature left off. With the complete list of components, we integrate with the National Vulnerability Database (NVD) to find any vulnerability related to each component, as well as relevant version information. We use ML/AI to follow those results recursively while adding to the model's decision trees.

Use Case: Log4j

As alluded to above, on December 10, 2021, a very serious vulnerability in the Log4j software was published with the identifier CVE-2021-44228. This vulnerability allowed attackers to send malicious messages into a log server that could be used to execute commands on that server, steal data, or even take control of the server. This was the result of overly provisioned features that were enabled by default, an insecure configuration, and the implicit trust of messages on the network.

What is Log4j?

Log4j is a widely used Java software library from the Apache Foundation. Its job is to collect and record events --a totally normal, necessary, and required task in software systems. Rather than reinvent the wheel and create their own logging system, professional developers across the world chose to use and include Log4j. In fact, software companies of all sizes have been using the vulnerable version of this library since 2014. (Yes, more than 7 years.)

Scope

Through the Framework for Analysis and Coordinated Trust (FACT) platform, analysts accessed a database of approximately 45 million software packages used in the operational technology (OT) space. Ninety percent (90%) of OT vendors have at least one affected product; some have hundreds.

Exploitation

During CISA's Briefing to Critical Infrastructure Partners, Eric Goldstein said, "This vulnerability could be used for an extraordinary broad range of attacks." Indeed, lots of attacks occurred. Government agencies like CISA and private ones alike were all reporting active exploitation of the vulnerability.

(We are not including a list of private agencies as the list is too extensive and to only name a few seems prejudicial.)

Detect and Response

The first step in every playbook is to determine if any software in your system contains the vulnerability; in this case, Log4j. One such example is the Log4j Detection and Response Playbook, published by the information security consulting group, TrustedSec.

The playbook recommends the following actions be performed:

Actively scan systems or use software inventories to identify vulnerable versions of Log4j;
Update vulnerable versions of Log4j or apply mitigations; and
Search for exploitation and post-exploitation activities.

Without eruditeMETA

It continues to decompose those steps into the following tasks:

Affected versions

The playbook lists the affected versions of the Log4j library. At the time of the posting, there were four CVE entries related to different versions:

CVE-2021-44228 (RCE vulnerability in v2.0 through v2.14.1)
CVE-2021-45046 (RCE vulnerability in v2.0 through v2.15.0)
CVE-2021-4104 (RCE vulnerability in Apache Log4j 1.2)
CVE-2021-45105 (DoS vulnerability in 2.0-beta9 to 2.16.0)

Using the information given at that point in time, those would be the directly affected versions that would need to be found and updated.

Affected software

The next step in the playbook is to identify the vendor applications or custom-built systems which contain the affected version.

Vulnerable software detection - searching for vulnerable code

Proactively scanning for vulnerable code by examining all servers and applications, on the chance that the component is buried in a lower class.

Vulnerable software detection - vendor notifications

Proactively addressing vulnerable software as vendors release bulletins if their software is vulnerable with information about applying upgrades.

Active scanning of deployed code

One can use a vulnerability scanner to actively scan a server for vulnerabilities

Prevention and mitigation

Prevention and mitigation are to upgrade the versions.

Exploitation detection

Scanning for exploitation attempts is the next step, in alignment with a company's incident response procedures.

Log analysis

Exploitation attempts, in this case, can be detected by searching through all log files on a server.

Endpoint analysis

Endpoint post-exploitation analysis is useful for detecting activity, and many EDR and endpoint security systems have signatures for detection.

Network analysis

Once an attack is successful, it is important to review outgoing network or web connections.

With eruditeMETA

Using the same breakdown of tasks above, if a company used the eruditeMETA platform, the playbook would be addressed somewhat differently:

Affected versions

These are handled as described above.

Affected software

This step would have been taken care of automatically through eruditeMETA.

Vulnerable software detection - searching for vulnerable code

This step is not necessary, as it is included in the recursive aspect of the SCA feature in eruditeMETA.

Vulnerable software detection - vendor notifications

As reputable vendors disclose this information programmatically though the NVD, CVE, and CPE records, this is already performed.

Actively scanning of deployed code

This can obviously be done additionally but should not be necessary due to eruditeMETA's scanning.

Prevention and mitigation

Through the results of the previous analyses, any guidance available would have been surfaced. In rare circumstances, one may need to perform manual steps when there is a case of infinite recursion in versions and vulnerabilities, until an updated patch with no vulnerabilities is published.

Exploitation detection

eruditeMETA's goal is to address any issues proactively. In the case of an exploit, it would rely on the company's existing tooling to detect any exploits.

Log analysis

These are specific searches related to each vulnerability, and are not automated in eruditeMETA, although it is a feature under consideration.

Endpoint analysis

These are not automated in eruditeMETA, although integration with existing vendors providing these services is a feature under consideration.

Network analysis

These are specific searches related to each vulnerability and potential whitelists. These are not automated in eruditeMETA, although integration with existing vendors providing these services is a feature under consideration.

Conclusion

Steps in detecting an attack in progress are still best handled by existing systems. In a proactive effort, though, eruditeMETA can reduce the chance of vulnerabilities being delivered to production.

While eruditeMETA furthers the effort to prevent vulnerabilities from entering your system, the fact remains that there will be occasions where a vulnerability is announced later, as was the case with Log4j. In situations such as this, the cost of delay in finding and quarantining or remediating the vulnerability cannot be measured. With eruditeMETA, the effort to identify software that has been impacted would be a non-event.

Our ongoing growth and pruning of the software supply chain and components included make this lag time negligible. eruditeMETA systems stay up-to-date, continuously learning through integration and traversing of each company's software supply chain, as well as the information publicly available.

Companies can feel confident that they know where vulnerabilities lie and can take steps to prioritize remediation, accept the risk, or create contingencies, especially if the unthinkable occurs.