A new research project has uncovered 56 vulnerabilities in operational technology (OT) devices from 10 different vendors, all of which stem from insecurely designed or implemented functionality rather than programming errors.
This highlights that despite the increased attention this type of critical devices have received over the past decade from both security researchers and malicious attackers, the industry is still not following fundamental secure-by-design principles.
"Exploiting these vulnerabilities, attackers with network access to a target device could remotely execute code, change the logic, files or firmware of OT devices, bypass authentication, compromise credentials, cause denials of service or have a variety of operational impacts," researchers from security firm Forescout said in their new report.
The identified security issues, collectively dubbed OT:ICEFALL, stem from insecure engineering protocols, weak cryptographic implementations or broken authentication schemes, insecure firmware update mechanisms, and improperly protected native functionality that can be abused for remote code execution.
In fact, 14 per cent of the disclosed vulnerabilities can result in remote code execution and another 21 per cent can lead to firmware manipulation.
Another interesting finding of this research was that many of the vulnerable devices had been certified according to different standards applicable to OT environments such as IEC 62443, NERC CIP, NIST SP 800-82, IEC 51408/CC, IEC 62351, DNP3 Security, CIP Security, and Modbus Security.
"While these standards-driven hardening efforts have certainly contributed to major improvements in the areas of security program development, risk management and architecture-level design and integration activities, these efforts have been less successful at maturing secure development lifecycles for individual systems and components," the researchers concluded.
A history of insecurity-by-design in OT
The Forescout researchers draw comparisons between their findings and those of Project Basecamp, a research project from 10 years ago that focused on exposing insecure-by-design problems in remote terminal units (RTUs), programmable logic controllers (PLCs), and other controllers that make up the SCADA (Supervisory Control and Data Acquisition) systems used in industrial installations.
Then, following the discovery of sophisticated threats like Stuxnet developed by nation-states to target PLCs, the researchers who participated in Project Basecamp set out to change what they said had been "a decade of inaction" by ICS manufacturers and asset owners following 9/11.
A decade later, OT:ICEFALL shows that many of the same problems, such as obscure proprietary protocols that lack proper authentication and encryption, continue to be a common occurrence in the devices that run our critical infrastructure.
"The products affected by OT:ICEFALL are known to be prevalent in industries that are the backbone of critical infrastructures such as oil and gas, chemical, nuclear, power generation and distribution, manufacturing, water treatment and distribution, mining and building automation," the Forescout researchers said in their report. "Many of these products are sold as ‘secure by design’ or have been certified with OT security standards."
While this state of insecure by default has continued in the OT world, the number of attacks has only increased and evolved.
Since Stuxnet, we have seen the Industroyer attack that caused power blackouts in Ukraine in 2016, the TRITON malware that was used in attempted sabotage of petrochemical plants in Saudi Arabia in 2017, the Industroyer2 malware that was used against electrical substation in Ukraine this year, and the INCONTROLLER APT toolkit.
The OT:ICEFALL flaws impact devices from Bently Nevada, Emerson, Honeywell, JTEKT, Motorola, Omron, Phoenix Contact, Siemens and Yokogawa. They include condition monitors, distributed control systems (DCS), engineering workstations, RTUs, PLCs, building controllers, safety instrumented systems (SIS), SCADA systems, protocols and even a logic runtime.
The logic runtime is the software that interprets and executes the ladder logic -- the code written by engineers to act on the inputs and outputs of the device. The ProConOS runtime from Phoenix Contact, for example, is used in multiple PLCs from different vendors making the flaws discovered in it -- lack of cryptographic authentication of the uploaded logic -- a potential supply-chain risk that leads to arbitrary code execution.
"Due to the lack of software bills of materials (SBOMs) and the complexity of product supply chains, it is often not immediately clear what runtime a particular PLC uses," the researchers said in their report.
"Runtimes typically have different versions with corresponding protocol differences and are subject to OEM integration decisions. A PLC manufacturer may choose to use the runtime but not the protocols, preferring to use its own, or may choose to use the protocol on a non-default port or may choose to rebrand or modify the runtime altogether.
"Absent proactive, coordinated efforts by vendors, CVE numbering authorities, and CERTs to propagate knowledge of supply chain vulnerabilities to all affected parties, the security community is forced to rediscover them periodically and haphazardly, resulting in CVE duplication and complicating root-cause analysis."
For example, two CVEs assigned in the past to issues in the ProConOS runtime -- CVE-2014-9195 and CVE-2019-9201 -- were only associated with Phoenix Contact PLCs while they impacted other vendors as well. An issue was discovered later in Yokogawa STARDOM controllers and was assigned CVE-2016-4860, but it's actually the same issue as CVE-2014-9195, the researchers said.
The problem is further exacerbated by the fact that in the past many insecure-by-default issues like the ones included in OT:ICEFALL did not receive CVE IDs at all since they were not viewed as traditional vulnerabilities, making it hard for customers to track them.