Dozens of insecure-by-design flaws found in OT products

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% of the disclosed vulnerabilities can result in remote code execution and another 21% 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. ICS security firm Dragos tracks 19 threat groups that target ICS environments, including three that were discovered last year and showed the capability of accessing ICS/OT networks.

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.

Mitigating OT device vulnerabilities

The Forescout team has worked with the U.S. Cybersecurity and Infrastructure Security Agency (CISA) during the disclosure process and the agency has published its own advisories for some of the issues. Asset owners should install patches and firmware updates when device manufacturers make them available but fixing some of the identified issues might involve significant engineering efforts and changes, so vendors might not address them for a long time. In the meantime, the Forescout team recommends the following mitigation steps:

• Discover and inventory vulnerable devices. Network visibility solutions enable discovery of vulnerable devices in the network and apply proper control and mitigation actions.
• Enforce segmentation controls and proper network hygiene to mitigate the risk from vulnerable devices. Restrict external communication paths and isolate or contain vulnerable devices in zones as a mitigating control if they cannot be patched or until they can be patched. Review firewall rules, especially whitelisted OT protocols, against SME knowledge. Some vendors offer dedicated firewalls and switches with protocol-aware security features.
• Monitor progressive patches released by affected device vendors and devise a remediation plan for your vulnerable asset inventory, balancing business risk and business continuity requirements.
• Monitor all network traffic for suspicious activity that tries to exploit insecure-by-design functionality. Use monitoring solutions with DPI capabilities to alert security personnel to these activities so appropriate actions can be taken.
• Actively procure for secure-by-design products and migrate to secure-by-design variants of products where available and when possible. Evaluate device security posture by including security evaluations in procurement requirements.
• Make use of native hardening capabilities such as physical mode switches on controllers which require physical interaction before dangerous engineering operations can be performed. Some vendors offer plug-and-play solutions to simulate these capabilities at a network level for multiple controllers. Where possible, activate alerts on operational mode switches into monitoring solutions.
• Work toward consequence reduction by following Cyber-PHA and CCE methodologies. This is important to address not only likelihood but also the impact of incidents.