Dozens of non-safe-by-design flaws found in OT products

A new research project has discovered 56 vulnerabilities in operational technology (OT) devices from 10 different vendors, all of which stem from insecurely designed or implemented features rather than programming errors. This underscores that despite the increased attention these types of critical devices have received over the past decade from security researchers and malicious attackers, the industry is still not following fundamental security-by-design principles. .

“By exploiting these vulnerabilities, attackers with network access to a target device could remotely execute code, modify logic, files, or firmware on OT devices, bypass authentication, compromise credentials, cause denials of service or have various operational impacts,” researchers from security firm Forescout said in its new report.

The identified security issues, collectively referred to as OT: ICE FALL, stem from insecure engineering protocols, weak cryptographic implementations or faulty authentication schemes, insecure firmware update mechanisms, and poorly protected native features that can be abused for runtime remote code. In fact, 14% of disclosed vulnerabilities can lead to remote code execution and another 21% can lead to firmware manipulation.

Another interesting finding from this research was that many vulnerable devices had been certified 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 in maturing secure development lifecycles for individual systems and components,” the researchers concluded.

A History of Insecurity by Design in OT

Forescout researchers draw comparisons between their findings and those of Project base campa 10-year-old research project that aimed to expose insecurity-by-design issues in remote terminal units (RTUs), programmable logic controllers (PLCs), and other controllers that make up Supervisory Control (SCADA) systems and Data Acquisition) used in industrial installations.

Then, following the discovery of sophisticated threats such as Stuxnet developed by nation states to target PLCs, researchers who participated in the Basecamp project set out to change what they called “a decade of inaction”. from ICS makers and asset owners in the aftermath of 9/11. A decade later, OT:ICEFALL shows that many of the same issues, such as obscure proprietary protocols that lack authentication and proper encryption, continue to be common in 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 infrastructure 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 to OT security standards.”

While this default state of insecurity continues in the OT world, the number of attacks has only grown and evolved. From Stuxnet we have seen the Industroyer attack which caused power outages in Ukraine in 2016, the TRITON malware which was used in attempts to sabotage petrochemical plants in Saudi Arabia in 2017, the Industroyer2 malware which was used against electrical substations in Ukraine this year, and the INCONTROLLER APT toolkit. The security company ICS Dragos follows 19 threat groups that target ICS environments, including three that were discovered last year and demonstrated the ability to access ICS/OT networks.

The OT:ICEFALL flaws affect 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, programmable logic controllers, building controllers, safety instrumented systems (SIS), SCADA systems, protocols and even logic execution.

The logic runtime is the software that interprets and executes ladder logic – the code written by engineers to act on device inputs and outputs. Phoenix Contact’s ProConOS runtime, for example, is used in multiple PLCs from different vendors, making flaws discovered there – the lack of cryptographic authentication of downloaded logic – a potential supply chain risk that leads to the execution of arbitrary code.

“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 usually 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 their own, or may choose to use their own, or may choose to use their own. ‘use the protocol on a non-default basis In the absence of proactive and coordinated efforts by vendors, CVE numbering authorities, and CERTs to spread knowledge of supply chain vulnerabilities to all parties affected, the security community is forced to periodically and randomly rediscover them, resulting in CVE duplication and complicating root cause analysis.”

For example, two CVEs attributed in the past to issues in the ProConOS runtime – CVE-2014-9195 and CVE-2019-9201 – were only associated with Phoenix Contact PLCs while also affecting other vendors. An issue was later discovered in Yokogawa STARDOM controllers and was assigned CVE-2016-4860, but is actually the same issue as CVE-2014-9195, the researchers said. The problem is further exacerbated by the fact that in the past many default insecure issues like those included in OT:ICEFALL were not given CVE IDs at all because they weren’t considered traditional vulnerabilities, which made it difficult for customers to track them.

Mitigating vulnerabilities in OT devices

The Forescout team worked with the US Cybersecurity and Infrastructure Security Agency (CISA) during the disclosure process and the agency has published their own reviews for some problems. Asset owners should install firmware patches and updates when device manufacturers make them available, but fixing some of the issues identified may involve significant engineering effort and changes, so suppliers may not solve them for a long time. In the meantime, the Forescout team recommends the following mitigation measures:

• Discover and inventory vulnerable devices. Network visibility solutions help discover vulnerable network devices and apply appropriate control and mitigation measures.
• Apply segmentation controls and good network hygiene to mitigate risk from vulnerable devices. Restrict external communication paths and isolate or confine vulnerable devices to areas as a mitigation control if they cannot be patched or until they can. Review firewall rules, especially whitelisted OT protocols, against SMB knowledge. Some vendors offer dedicated firewalls and switches with protocol-compatible security features.
• Monitor rolling fixes released by affected device vendors and design a remediation plan for your inventory of vulnerable assets, balancing business risks and business continuity requirements.
• Monitor all network traffic for suspicious activity that attempts to exploit features that are not secure by design. Use monitoring solutions with DPI capabilities to alert security personnel to these activities so appropriate action can be taken.
• Actively source secure-by-design products and migrate to secure-by-design product variants where appropriate and possible. Assess device security posture by including security assessments in provisioning requirements.
• Use native hardening abilities such as physical mode switches on controllers that require physical interaction before dangerous engineering operations can be performed. Some vendors offer plug-and-play solutions to simulate these capabilities at the network level for multiple controllers. Where possible, enable alerts on operational mode changes in monitoring solutions.
• Work on reducing consequences by following Cyber-PHA and CCE methodologies. This is important to address not only the likelihood but also the impact of incidents.