The Log4Shell vulnerability – are industrial control systems at risk?

At the end of last year a previously-undetected vulnerability called Log4Shell was uncovered in an open source logging tool that is used in cloud servers and enterprise software across the world. It’s possible that the flaw is the worst computer vulnerability discovered in years. Log4Shell is a remote code execution vulnerability in a Java logging framework that is used by most enterprise Java applications. The exploitation of this vulnerability is often very easy, not requiring any authentication or special privileges. A remote code execution vulnerability is the worst kind of vulnerability, because an attacker can then take complete control over the server the software is running on and execute arbitrary code here. This could be any kind of malware, crypto miners or hacking tools that can be used to further compromise other components in the internal network.

Log4Shell has the potential to compromise millions of devices across the internet, and cyber security teams across the world are scrambling to patch the issue and safeguard their IT systems. But the nature of the vulnerability means that it is also present in industrial control system environments.

Are industrial systems at risk?

The answer to this question depends on the setup. Industrial control systems should be designed with network controls that stop outbound internet traffic. The way the Log4Shell exploit works, is that an attacker sets up a server that will tell the system to execute code available in a remote location, for example on a web server. If the attacker sets up these servers on the public internet but the vulnerable server in the ICS domain cannot reach the internet, the exploit cannot be triggered.

There are, however, ways attackers could exploit the vulnerability even if the vulnerable server is not able to contact the Internet. An attacker who has a foothold on the internal network could potentially set up the required servers (e.g. LDAP and HTTP services) internally, and then use that to trigger the vulnerability in order to execute code on the targeted server. Such an attacker would typically be an insider threat. It could be service personnel being allowed access through a service laptop or through remote access. It could be an operator with direct access to the network.

Because of this, although the probability of exploitation is much lower than a system that can both contact servers on the Internet, and be reached from the Internet, thinking that Log4Shell is irrelevant for industrial control systems would be potentially dangerous mistake.

What actions should you take?

The industrial cyber security teams at DNV and Applied Risk recommend that operators of industrial control systems take the necessary steps to mitigate Log4Shell exploitation. If an official patch is available for your affected system, updating the system would be the preferred option. If this does not yet exist, alternative workarounds exist. The primary workaround would be to change settings in the Java Virtual Machine to block the lookups necessary to get the payload from the remote server, see Apache's Log4j page for reference.

If you would like more advice, on the steps you should take to safeguard your industrial control systems from the Log4Shell vulnerability, don’t hesitate to reach out to the specialist industrial cyber security teams at DNV and Applied risk by visiting: www.dnv.com/cybersecurity/contact

DNV and Applied Risk are joining forces with the aim to build the world’s largest industrial cyber security practice. Find out more about how we can help defend your company against emergent cyber threats: www.dnv.com/cybersecurity