What is the Log4Shell vulnerability and how big is it?
On the 24th November 2021, the Alibaba Cloud Security team privately notified Apache about a new vulnerability in a very popular Java programming language library called Log4j. The vulnerability became public knowledge on the 9th December 2021 and officially published in CVE databases during the 11th & 12th December 2021.
Java logging system vulnerable!
The vulnerability titled CVE 2021-44228, and coined Log4Shell, is a vulnerability in the logging system that allows an attacker to craft a string and execute code on a victim's machine. While this vulnerability was first discovered in the popular game Minecraft, written in Java, it was discovered that the vulnerability was far more widespread than first thought. Companies affected included Apple, Amazon, Twitter, and Cloudflare among many thousands of others. The CVE awarded this vulnerability a maximum score of 10/10 because of the combination of the ease of exploitation and the scale at which the vulnerability is present. As of 13th December, automated exploits have been discovered in the wild, allowing malicious actors to attack across a large surface with relative ease.
How does Log4Shell affect the Industrial sector?
Human Machine Interface (HMI) and Supervisory Control and Data Acquisition (SCADA) systems often utilise Java and Log4j in order to capitalise on the portability of the Java Virtual Machine (JVM). Furthermore, embedded systems that rely on web server technologies such as Apache Tomcat utilise vulnerable versions of this library and are at risk of exploitation.
Many vendors which serve the industrial sectors have published notices of being affected by the Log4Shell vulnerability. This includes:
Honeywell are currently evaluating their potential vulnerabilities
OPC UA Java Legacy also uses Log4j
And so many more, the website techsolvency.org is a useful resource for discovering notices by vendors.
We will continue to keep our eye on other industrial vendors such as ABB, Kuka, Mitsubishi and more. We know that many of these systems use Java, but they have not yet notified the public about Log4j vulnerabilities.
It is important not to point fingers here. Log4j has been a well respected logging open source library for Java since it’s creation in 2001, and is maintained by the well loved Apache Software Foundation. In fact, we should applaud how this vulnerability is being handled by Apache, and by all of the software developers which are working tirelessly to update their software to use the latest patched version of Log4j.
For some insight… Vendors are in the process of analysing the vulnerabilities within any software that relies on the Log4j library for logging and updating accordingly, in some cases this might mean rewriting some parts of the software to support the newer interfaces. For those building Java-based systems, the vulnerability is present in versions of Log4j prior to version number 2.15.0-rc1. From version 2.15.0-rc1 (published on the 6th December 2021) the vulnerability is no longer present. It is also recommended that, where feasible, the Java Naming and Directory Interface (JNDI) is updated to at least version 2.12.1.
Users of these systems are strongly advised to deploy updates as soon as possible, particularly to those systems which also have an active internet connection. In some cases the feasibility may mean waiting until the next maintenance window, in which case understand the risk in as much detail as possible, and make this a high priority patch.
For everyone running Java-based software, it is recommended that the Java Runtime Environment (JRE) is updated to the very latest version.
Can Awen Collective help?
Our Dot software system for asset and vulnerability discovery on Operational Technology networks is kept up-to-date with the latest CVE information, and can discover device information which is then cross-referenced with the Log4Shell vulnerability (and other vulnerabilities).
However, this post is here not to sell our software, but to ensure that the right information is in the right hands. We want to help, and so if you are concerned that you (as an industrial organisation or engineer) might have this vulnerability then please do contact us today. We are happy to informally point you in the right direction at the very least. No obligation necessary with informal chats.
This post was written by Awen developer Jamie Grant and Awen CEO & Founder Daniel Lewis. This post was first published on 14th December 2021 at 12:26pm GMT, it was updated by Daniel to reflect new information on 14th December 2021 at 22:33 GMT.