Why do you need SCA to mitigate the Log4j flaw?

By now, I am sure you have heard about Log4j and the serious vulnerability that allows attackers to carry on attacks without user credentials, gaining remote access to secure systems and sensitive data.

Log4j is such a popular open-source library that is used by thousands of well-known applications to provide logging functionality. The discovery of a vulnerability in this open library caused a storm because of the popularity of the library.

The reports of exploits didn’t take long after the vulnerability was discovered.

Therefore, organizations are assuming compromise and starting forensic scans. Finding the open-source components in an application is not something that can be done manually. This is where SCA (software composition analysis) tools automate this process and is a key tool to mitigate the Log4jShell flaw.

The Log4j vulnerability is far from over

Since December 2021, when a vulnerability found in the Apache logging library Log4j was discovered; attackers have broken havoc, stolen credentials, and data, and installed crypto miners.

The range of impact was very broad because of the nature of the vulnerability. To exploit Log4j, the attackers get the system to log a string of code that they use to load and install the malware in the targeted server and may use it to launch other attacks. It is easy for attackers to introduce the string via a seemingly innocent email, for example.

While big companies like Amazon, Microsoft, Cisco, and Google, rushed to issue fixes, smaller companies may not have the resources to tackle the vulnerability quickly. Log4j is an open-source logging library, used widely by the majority of large organizations. If left unpatched, it may affect millions of enterprise applications and cloud services written in Java.

Recent attacks

In December, many cyber vendors detected a large number of attempts to exploit the vulnerability, but the combined efforts of the digital and security communities helped avert more serious attacks. In early January, the number of attacks was lower than expected.

Some of the large attacks revealed to date include:

• On December 20, a portion of the defense ministry’s network in Belgium was down as a result of a Log4j exploit. They didn’t reveal if there was ransomware involved.
• Large companies like Microsoft and Mandiant observed exploit intents from nation-state groups—connected to countries like China and Iran—.
• Other attacks have been disrupted midway. On December 29, Crowsstrike reported a disrupted attack carried on by a state-sponsored group from China. This attempt involved exploiting the Log4j vulnerability.

Another reason there may have been fewer attacks than expected is that attackers need to customize the threat to each application using the Lg4j code. Still, cyber experts believe the exploitation of the Log4j vulnerability will probably continue for months or years.

How software composition analysis can help?

SCA, Software Composition Analysis, is part of the application security testing (AST) tool stack, that scans a codebase to identify the open-source software in an application codebase. Tracking open-source components manually can become an impossible task when you are working with hundreds of libraries. Thus, it is often overlooked. An SCA solution automates this process, inspecting source code, binary files, package managers, and container images.

How does SCA work?

Once it identifies all open-source components, the SCA compiles a Software Bill of Materials (SOB), including their license data, and detects any potential security vulnerability. The inventory includes direct and transitive dependencies. It also provides information on each component’s license and its compatibility with the organization’s policies. This feature provides visibility into all open-source components, and how they are used.

Some SCA tools go further than detection and identification, providing prioritization and auto-remediation capabilities. The best SCA solutions automate the entire process, from scanning to inventory, to alerting.

These quick alerts help organizations to take action when a Zero-day vulnerability is identified. Binary SCA also helps enterprise organizations to scan commercial software, therefore verifying their vendors.

What steps can you take now to mitigate the impact of Log4Shell?

Knowing what open source components, you have in your applications and where are vulnerable, is the first step in preventing the impact—or mitigating it—of a Log4Shell vulnerability. You should approach the vulnerability from the outside-in, from a general to specific analysis. Here are some steps you can follow:

1. Scan the external surface: this will enable you to identify potentially vulnerable hosts, for example, cloud providers. Check with your cloud vendor and see if they issued a new plugin for this.
2. Put your SCA to work: your software composition analysis scans your applications and systems to identify what Java codebases have components and dependencies on Log4j. Ensure your scans include transitive dependencies.
3. Keep in mind this vulnerability does not affect ports because it requires the use of Java interfaces.
4. As soon as you can upgrade your dependencies to Log4j 2.25.0.
5. Design a remediation plan and execute it.
6. Remember to continuously scan for open-source vulnerabilities.

So in summary:

The full impact of the Log4j vulnerability will probably continue for months of the next years, and it is better to act as soon as possible. Scanning your applications with an SCA tool will help you detect vulnerabilities in open-source libraries, and act quickly to remediate them. Leverage leading SCAs that also provide alerting and response capabilities for more peace of mind.

also, check out How can you protect yourself against Ransomware?