How to Protect Deployed Assets from Log4j

How to Protect Deployed Assets from Log4j

What Is the Log4j Exploit

Nearly every week the cybersecurity community buzzes around a newly discovered vulnerability or a breach. December’s alert for the CVE-2021-4428  vulnerability in Apache Foundation’s Log4j software is no different. Also known as the Log4Shell vulnerability, it is present within the log4j-core library commonly used for logging in Java applications. These applications are widely deployed in a huge variety of environments, and the potential for extensive impact is real.

Cleaning up the mess will take a methodical approach

As we write this, government security agencies are reporting active exploitation of the vulnerability. Both adversaries and security researchers are actively attempting to identify vulnerable hosts on the Internet. Attackers targeting a host running Log4j may also be using it as a vector to enable or obscure larger attack campaigns.

Before panicking, it is crucial to understand the nuances around the true risk/impact and be methodical in addressing the issue. Even just locating affected assets can be challenging, so a systematic approach is necessary.

How to Protect Against Log4j

1. Consider where potentially affected digital assets are located in your environment. Java-based applications containing Log4Shell are likely to be found where sensitive data (like PCI data) is located, but they may also exist in other environments. For example, these applications are often found within critical infrastructure and Operational Technology (OT) software. Happily, those assets are usually not directly connected to the Internet and may be running an older, unaffected version of Log4j.
2. If you detect these vulnerabilities within an application or endpoint in your environment, remediate as soon as possible. This could be through a patch (if available) or via one of the workarounds we discuss below.
3. Quarantine any infrastructure hosting the affected software if it is directly accessible (e.g., where there is a high likelihood of the affected software being probed by adversaries on the Internet) or is used within a larger networked system of systems. Even if it is an unimportant device or computer, the attackers could compromise it and then use it to move laterally to more interesting assets. They could also use it as a launching pad for future attacks..
4. Remember that users and even the product owner/developers themselves might not know the vulnerability exists in your applications. It also may not appear in vulnerability management (VM) scans. Software Bill of Materials (SBOMs) are a great tool for identifying the presence of a vulnerability in a software asset.

So how can you protect deployed assets from vulnerabilities like Log4j in the future?

You need to have multiple compensating controls protecting your key assets. This consistent “defense in depth” layered strategy reduces risk to acceptable levels while engaging in a response. The following infographic is a good example of how multiple controls could be applied to prevent exploitation of the Log4j vulnerability (courtesy of GovCERT.ch  — the Swiss government’s Computer Emergency Response Team ).

GovCERT illustrates multiple opportunities to provide compensating controls to protect an affected product with network connectivity.

Solutions for OT systems to protect against Log4j:

1. Limit connections to authorized hosts only (not shown).
2. Use a Web Application Firewall (WAF) to block malicious requests; these requests are fairly obvious in network traffic and the rules to block them are widely available.
3. Disable JNDI lookups.
4. Disable Log4j.
5. Disable remote code-bases.
6. Last but not least, patch the software.

Unfortunately, patches do not secure an already compromised host. If an asset is known to be clean and disconnected from sources of potential risk exposure, then patching may eliminate a specific risk. However, if the asset is on the Internet or connected in an environment with a high-level of exposure, patching alone is not enough to address a potential threat because that asset may already be compromised. So don’t rely solely on the “patching” step.

Patching is also not a silver bullet to eliminate this vulnerability in OT because some product providers are:

• Unaware that the vulnerable component exists in their software
• Unable to rapidly recompile and distribute the fixed software as a binary patch (because the affected code is distributed as source code)

Even when you know the vulnerability exists in software you use (thanks to the licensing and service agreements common in the critical infrastructure space), your supplier might be the only party able to provide a software fix. The good news is that once you know you are using vulnerable software, you can deploy one workaround that offers some level of protection, such as disabling the Java Naming and Directory Interface (JNDI) feature (if you can find the Log4j configuration file, enter –Dlog4j2.formatMsgNoLookups=true).

The key to addressing future vulnerabilities similar to Log4j begins with getting visibility into the subcomponents in the products you sell or use. If you are the asset owner, you need to:

• Quickly identify vulnerable products you have deployed in your systems.
• Leverage compensating controls to provide immediate protections for affected systems.
• Request that vendors supply patches and fixes for identified affected products.
• Investigate possible compromise where affected assets may have had exposure to malicious actors.
• And finally, respond and remediate where applicable.

If you are the product manufacturer, you’ll need to rely on SBOMs from source code and builds (assuming you have source code). When dealing with legacy products, make use of derived SBOMs created using binary analysis. And even if you possess the source code, remember to compare the source code and binary SBOMs; you’d be surprised what makes it into the end software product.

Regardless of whether you are an asset owner or a software vendor, aDolus FACT allows your organization to manage supply chain vulnerabilities throughout a software product’s development, release, and deployment lifecycle via automated binary tear-downs and machine learning (ML) correlation techniques. This helps improve your organization’s compliance and advisory reporting capabilities and also relieves the burden on already-stretched security teams. More about Embracing DevSecOps with Automated Software Binary Security

For more information and resources to address Log4j/Log4Shell, visit this page.

About the author

This article was written by Ron Brash, VP of Technical Research & Integrations at aDolus and originally it was published here.