Industrial Automation Log4j Roundup
How did the leading suppliers of manufacturing automation technology respond to the Log4j vulnerability? Also called Log4Shell because it left vulnerable systems open to remote code execution (RCE), this critical flaw appeared in the ubiquitous Log4j Java logging library and created quite the stir (read: panic) among organizations small and large (read: everyone).
In a statement from the Cybersecurity and Infrastructure Securty Agency (CISA) Director Jen Easterly, she explained, “This vulnerability, which is being widely exploited by a growing set of threat actors, presents an urgent challenge to network defenders given its broad use… CISA recommends asset owners take three additional, immediate steps regarding this vulnerability:
Enumerate any external facing devices that have log4j installed.
Make sure that your security operations center is actioning every single alert on the devices that fall into the category above.
Install a web application firewall (WAF) with rules that automatically update so that your [Security Operations Center] is able to concentrate on fewer alerts.”
Besides following these steps, manufacturers were forced to closely look at their integrations, consult with their suppliers, and figure out where they might be exposed. That’s why we want to put all the information in one place for you. This roundup contains the official responses from top automation suppliers.
Inductive Automation
In their official statement, the company says they “conducted a full audit for Ignition’s direct and transitive dependencies to confirm that log4j is not used or included in any supported or unsupported release of Ignition, and as such is not vulnerable to the RCE outline in CVE-2021-44228.”
“No action is required by any Ignition user on any version of Ignition, LTS or not,” they conclude.
PTC
This company created a web page dedicated to the Log4j vulnerability where they enumerate which of their products aren’t affected, which are, and how to deal with vulnerable systems by linking to specific support articles. Overall this is a quite thorough response, and PTC customers should be able to find exactly the information they need in a timely manner.
They also devote some time to PTC Cloud, explaining that this system contained the vulnerability but that they have applied patches as they’ve arrived and “will continue to act with the utmost urgency.” If you use PTC Cloud and have questions or concerns, they encourage you to reach out to cloudservicemanagement@ptc.com.
PTC went one step further than most vendors, with their Chief Technology Officer, Steve Dertien, submitting a short article to Industrie Digitalisierung. “Our tight response time was possible because, in the world of SaaS delivery, everything is highly automated and built to scale simply,” he writes. “Software is updated with no effort on the part of the user. This also means that when critical security or software issues are found, no manual intervention is required at the customer site.”
Siemens
Information regarding how the vulnerability affected various Siemens products is scattered across their site, but, thankfully, others have done the heavy lifting for us and created a compiled list of what products are vulnerable and the steps that users need to take.
Affected products include SIMATIC WinCC V7.4, LOGO! Soft Comfort, Industrial Edge Management apps, and more. Some of these systems have been fully remediated at this point, while others should still have both incoming and outgoing traffic blocked off.
Phoenix Contact
On their Product Security Incident Response Team website, Phoenix Contact keeps a repository of PDFs related to recent security advisories that are free and easy to download—no sign-ups or mailing lists required. In the “Statement on Security Vulnerability ‘Log4Shell’ discovered in Java library Log4J”, they write:
“We have examined our product portfolio with the following result:
Physical products containing firmware — Not affected
Software products — Not affected
Cloud Services — Partly affected. Remediations are being implemented.”
AVEVA
In the company’s statement (log-in required), they write that “AVEVA products are unaffected by Apache Log4j, expect as described”
Namely, AVEVA Historian versions 2017 to SP 2017 Update 3 SP1 P01 are affected through a dependency on vulnerable versions of Elasticsearch. They offer two mitigation strategies. Environments that aren’t using Historian Insight (the Historian Client Web) can use the Windows Services Management Console to disable Elasticsearch by stopping and disabling the Wonderware Historian Search service.
Those using Historian Insight will have to take more steps for mitigation that are beyond the scope of this article and, if you’re in this boat, we recommend going to their site and following their directions as soon as possible.
Rockwell Automation (Updated)
Rockwell Automation released a publicly available Knowledgebase article indicating affected products. The most affected product was Rockwell’s Plex IIoT software, which has been updated at this time. Other affected software includes Industrial Datacenter, Warehouse Management, and FTA Data applications.
Rockwell does note that several other software products do use Log4j libraries but do not use aspects that are vulnerable. You’ll be happy to know that Studio 5000 Logix Designer does not use Log4j at all, but Studio 5000 View Designer does contain the Log4j library with the limited functionality.
Opto 22
Our final official company statement includes a link to firmware and software updates that “Opto 22 urges you to apply immediately” along with a list of affected products, mainly within the groov View software family. They include:
GRV-Epic-PR1, GRV-EPIC-PR2
GROOV-AR1, GROOV-AR1-BASE, GROOV-AR1-SNAP
GROOV-AT1, GROOV-AT1-SNAP
GROOV-SVR-WIN, GROOV-SVR-WIN-BASE, GROOV-SVR-WIN-SNA{
They also note three products that are not affected. They are:
groov RIO (GRV-R7-MM1001-10 and GRV-R7-MM2001-10)
SNAP I/O brains, SNAP PAC controllers, and the PAC Project software suite
Legacy products include mistic, Optomux, FactoryFloor, and others
Beckhoff
This company failed to produce any response. Manufacturers who use their equipment should treat it as vulnerable until proven otherwise and follow CISA guidelines for mitigation.
AutomationDirect
This company likewise failed to produce any response to the critical vulnerability. Be careful connecting any of their products that run software/firmware to a network and follow CISA guidelines.