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?”
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:
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.
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.
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.