Following the discovery of the much-publicized “Log4Shell” vulnerability (December 9, 2021),  this new zero-day exploit continues to send shockwaves throughout the global cybersecurity community. Log4j is a library widely adopted and used in many commercial and open-source software products as a logging framework for Java. The vulnerability is tracked as CVE-2021-44228 and is a remote code execution exploit that can provide an attacker with complete control of any breached system. It was followed by a few other ones related to that same Log4j library.  Log4Shell targets the code functions in Log4j analyzing and logging data for security and debugging reasons, which is a ubiquitous software feature. Log4j is used in most of the developed Java applications. Unfortunately, this practice allows attackers to compromise vulnerable applications.

One of the significant concerns about Log4Shell is Log4j’s strong position in the software suites utilized in the rail industry. It will be popular in many enterprise solutions facing the operators, from tools at the OCC that will be used to supervise railway and station operations, the physical security systems to the actual train driving software. In addition, it’s used in cloud services like Apple iCloud and Amazon Web Services and a wide array of OCC software and Rail Operational Systems (ROS). It’s just everywhere.

Log4Shell received the highest CVSS score, 10.0/10.0, and is exceptionally unsafe due to several factors: (1) With an abundance of weaponized exploits available on GitHub and other public libraries, the vulnerability can be attacked with relative ease and with combined tools. (2) Log4J2 is one of the most popular logging libraries. Maven Central, the largest Java package repository, found that 35,863 Java packages use vulnerable versions of the Apache Log4j library. That’s 8% of the total Java packages there. (3) Finally, Log4Shell can easily be used in random attack scenarios by bombarding random HTTP servers with malicious requests.

In response to these new threats, CISA and the Joint Cyber Defense Collaborative (JCDC) published new guidelines on the vulnerability and recommended applying appropriate patches immediately. In addition, CISA details steps that affected organizations should take to mitigate the risk from Log4Shell. These steps include:

* Identifying networks affected by Log4Shell and other vulnerabilities in Log4j. 

* Upgrading Log4j assets and affected products to the latest version as soon as patches are available to vendors.

* Activating incident response procedures to detect possible Log4Shell exploitation.

Mitigating the Risk of Log4Shell with CylusOne

As mentioned above, since Java-based systems are widespread in railway environments, a strong network segmentation strategy will help you protect assets that may be vulnerable deep in a rail-OT layer. Still, it is not a perfect answer, and as threat actors run out of easier targets, more sophisticated exploits may appear. CylusOne offers powerful asset management and virtual segmentation capabilities to ensure that your rail network is virtually segmented into security zones, following the principles of Security In-Depth.

Beyond visibility and segmentation, threat detection is of paramount importance as well. While in an IT environment, you may be able to quickly scan your network to find potential threats, in your OT, it is improbable that you will be able to do so. So the need for a security monitoring solution running deep in that OT network to identify Log4Shell exploitation attempts becomes essential.

The last hurdle is remediation or risk mitigation. If you’re lucky, you will be able to patch the vulnerability from the solution vendor soon. One of the challenges is that the vendor may not be able to fix it quickly because Log4j isn’t always included as a direct dependency inside Java packages but is also a dependency of another dependency, also known as indirect dependency. In fact, this intricate dependency is the majority of the cases (80% of the cases are indirect dependencies, with over 50% being 5 and above levels down). The deeper the vulnerability is in a dependency chain, the more steps that must be fixed.

Risk mitigation is hard enough to execute in an IT environment, but it is much worse in an OT rail environment. You will need to patch systems, and we all understand the challenges coming with that. Your OT system vendor will need to make that patch available first, and with the level of dependency described above it might take a while. And then that system might be safety-critical and therefore very tightly controlled, so changing the system version means that you need to look again at the safety case with an outcome ranging from “patch can be applied with the necessary precautions” to “not happening”. So those vulnerable systems will stay that way for a while, some of them possibly forever. You can also assume that there will be a breach, if not already. Therefore, you should actively hunt for post-exploitation activity. CylusOne offers effective security operations and remediation capabilities to meet these vital needs, including risk scoring, continuous vulnerability assessments, and remediation playbooks.

To conclude, as the headline of a recent article in Wired suggests, Log4Shell will "haunt the internet for years." But, unfortunately, it will also haunt other interconnected software and networks, including widespread systems in the railway industry. During a conversation I recently held with a senior executive at a major rail operator, he asked me about the long-term effects of Log4Shell. I answered: "it looks like it’s here to stay". "But the good news," I replied, “is that it can be closely monitored and remediated with the proper rail cybersecurity solution."