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.
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.
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. For OT systems, the following can be solutions:
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:
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:
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.
For more information and resources to address Log4j/Log4Shell, visit our Log4j Resources page.