Implications of Log4J in your Control System

Recently across the news there has been a lot of discussion about “Log4J vulnerability” This is a newly discovered vulnerability in a very common piece of software that can allow an attacker to execute malicious code on the impacted system, creating a pathway for attacking systems in an enterprise network. Many of ACE’s customers are asking themselves, and ACE, questions like “Am I affected?” Is this a big deal?” and “What do I do?”

What is Affected?

Log4J is used as a dependency in a variety of software packages, including packages that DO NOT use Java for the user facing client. For this reason, you may not be able to immediately screen out software on the systems you support. Two examples include:

• For an industry-leading SCADA provider, Log4J is a sub-dependency of the package used to provide search features on the web interface of their historian.
• For another industry-leading historian provider Log4J is a sub-dependency of the search provider and of the webserver used to provide the web-site user interface.

In both of the above instances, Java is not directly used for the user-facing aspects. Therefore it is important to reiterate that a search for Java will not immediately uncover all of the potential vulnerabilities. The potential for vulnerabilities depends on the specific software packages installed. Therefore, it is imperative that you develop a better method for identifying your sites vulnerabilities. Below are methods for determining if this vulnerability impacts systems you support. Select the appropriate method to respond to your environment. This includes the software packages installed by OEMs on any embedded hardware systems. Contact ACE for assistance if required.

• Check for information releases or disclosed vulnerabilities for all of the software/hardware vendors used in the systems you are responsible for (refer to following section).
  o If you do not know what vendors are used in your systems, contact ACE for site evaluation and ACE will provide a report on the software used, and the associated disclosed vulnerabilities.
  • CISA maintains a list of vulnerabilities, but please note that not all major vendors supply CISA with their vulnerabilities. Therefore, absence of a notice on this site is not necessarily indicative that no notice exists.
  • Each vendor maintains their own separate list of vulnerabilities. Many vendors are also issuing notices that their software does NOT use Log4J.
• Search for presence of log4j-core jar files and check for versions 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0. This is only possible on systems where the file system is accessible (typically not possible on embedded systems).
• Search for accessible services responding with identifiable signatures. This falls into a class of active scanning that requires extreme caution when utilized in an ICS environment. Improperly leveraging active scanning tools may cause communications failures and resulting down time. If you require assistance for proper use of these tools, please contact your ACE account manager.

Is this a big Deal?

As of this writing, there are known active attacks that exploit this vulnerability. Not only are there attacks on web-facing devices, there are reports that ransomware attacks are using this vulnerability to attack non-internet facing targets. While this vulnerability is ubiquitous, it is because of the threat to any vulnerable network that it has gotten a CVE rating of critical – the highest level.

What do I do?

Your specific system will largely dictate the mitigation that you need to do. First and foremost, software that is vulnerable to Log4Shell should NOT be left accessible to the Internet or to untrusted users. The two most common methods of disconnection include unplugging connections from the control system to any external network, or leveraging firewall rules to implement a DMZ.

In addition to network isolation, additional mitigation is recommended. In most cases, software package vendors provide mitigation techniques with their own vulnerability notice. These should be reviewed and applied as appropriate to adequately mitigate the risk to align with the system owner’s cyber security posture. These methods of mitigation include upgrading or patching software packages so that the vulnerable Log4J components are no longer used. In most ICS software packages, this will require an update from the vendor, and the Log4J components will not be individually upgradeable.

If a vendor has not supplied mitigation recommendations, disabling of the parent software package or specific features may eliminate the vulnerability. This is typically useful if the software or features are not required for day-to-day production.

Finally, alternate controls may be utilized to increase defense-in-depth and may be able to address scenarios where the software can neither be upgraded or disabled. Exploitation of the vulnerability requires an attack pathway where Log4J parses specially-crafted inputs. Without full source access, it is difficult or impossible to screen out the threat vector within the software when vulnerable versions of Log4J are present in the software package. Such guidance must generally come from the vendor. However, it is possible to bound the vulnerability by protecting such pathways external to the software package. Network controls and access controls may be part of alternate controls used to implement such a mitigation outside of the software package.

If you still are unsure about what to do, contact your ACE account manager, or contact ACE directly. We will help put together a roadmap to address identifying and mitigating any Log4J vulnerabilities in your control system.

 Learn more about the ACE approach for bringing the latest cybersecurity practices to your plant floor.