Log4j: Panic or lesson? How to protect deployed assets

Nearly every week, the cybersecurity community buzzes around a newly discovered vulnerability or 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.

As we write this, government security agencies are reporting active exploitation of the vulnerability. Both adversaries and security researchers are 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.

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.

How to protect deployed assets from vulnerabilities like Log4j 

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.

There are multiple opportunities to provide compensating controls to protect an affected product with network connectivity. For OT systems, the following can be solutions:

1. Limit connections to authorized hosts only.
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 java naming and directory interface (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 JNDI feature (if you can find the Log4j configuration file, enter –Dlog4j2.formatMsgNoLookups=true).

Getting visibility

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.

For more information and resources to address Log4j/Log4Shell, visit aDolus’ Log4j Resources page.

– This article originally appeared on aDolus’ blog. aDolus is a CFE Media content partner.

Original content can be found at blog.adolus.com.

Do you have experience and expertise with the topics mentioned in this article? You should consider contributing content to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.