Manufacturing Networks Are Vulnerable to Log4J
Assembly Line
Industrial Organizations Targeted in Log4Shell Attacks
As of Monday night, Siemens has confirmed that 17 of its products are affected by CVE-2021-44228 and there are many more that are still being analyzed. The German industrial giant has started releasing patches and it has provided mitigation advice.
Schneider Electric has also released an advisory, but it’s still working on determining which of its products are affected. In the meantime, it has shared general mitigations to reduce the risk of attacks.
Critical Log4Shell (Apache Log4j) Zero-Day Attack Analysis
This is a critical vulnerability that is affecting a wide range of systems and users. It is very easy to exploit so many attackers are testing out the new vulnerability very rapidly. Users should upgrade quickly their Apache logging utility to Log4j 2.16.0 or alternatively apply one of the workarounds provided by the vendor. Nozomi Networks customers will be able to leverage our Threat Intelligence service for the latest countermeasures to this exploit.
Implications of Log4j Vulnerability for Operational Technology (OT) Networks
This cross-cutting vulnerability, which is vendor-agnostic and affects both proprietary and open-source software, will leave a wide swathe of industries exposed to remote exploitation, including electric power, water, food and beverage, manufacturing, transportation, and more. Log4j is found in popular open-source repositories used in numerous industrial applications, such as Object Linking and Embedding for Process Control (OPC) Foundation’s Unified Architecture (UA) Java Legacy. Additionally, adversaries can leverage this vulnerability in proprietary Supervisory Control and Data Acquisition (SCADA) and Energy Management Systems (EMS) which make use of Java in their codebase.
Log4j Security Vulnerability Response Center
For remediation for Apache Log4j 2 CVE-2021-44228 and CVE 2021-45046, PTC recommends removing the JNDILookup.class as described in the remediation from Apache. Throughout PTC’s testing to date (December 10 to December 15, 2021) there have been no adverse impacts from using this method. PTC has not used this dynamic loading capability in our products, and the remediation should be both effective to the vulnerability and very low risk to our products. Any risk of this change is limited in scope to the logging subsystem of applications, and any resulting errors are far less significant than the exposure of this vulnerability. Customers can preemptively remediate the vulnerability while awaiting official certification to reduce their immediate exposure to this critical issue.
Inside the Log4j2 vulnerability (CVE-2021-44228)
In 2013, in version 2.0-beta9, the Log4j package added the “JNDILookup plugin” in issue LOG4J2-313. To understand how that change creates a problem, it’s necessary to understand a little about JNDI: Java Naming and Directory Interface.
JNDI has been present in Java since the late 1990s. It is a directory service that allows a Java program to find data (in the form of a Java object) through a directory. JNDI has a number of service provider interfaces (SPIs) that enable it to use a variety of directory services. For example, SPIs exist for the CORBA COS (Common Object Service), the Java RMI (Remote Method Interface) Registry and LDAP. LDAP is a very popular directory service (the Lightweight Directory Access Protocol) and is the primary focus of CVE-2021-44228 (although other SPIs could potentially also be used).