Vedere Labs identifies OT:ICEFALL vulnerabilities caused by insecure-by-design practices across OT environments

Vedere Labs identifies OT:ICEFALL vulnerabilities caused by insecure-by-design practices across OT environments

Forescout’s Vedere Labs has discovered 56 vulnerabilities caused by insecure-by-design practices affecting devices from ten OT (operational technology) vendors. Collectively called OT:ICEFALL, these security loopholes are divided into four main categories – insecure engineering protocols, weak cryptography or broken authentication schemes, insecure firmware updates, and remote code execution via native functionality. 

The ‘insecure by design’ problems have been found across ten manufacturers, including Baker Hughes (Bentley Nevada), Emerson, Honeywell, JTEKT, Motorola, Omron, Phoenix Contact, Siemens, and Yokogawa.

With OT:ICEFALL, Forescout discloses and provides a quantitative overview of OT insecure-by-design vulnerabilities rather than relying on the periodic bursts of CVEs for a single product or a small set of public, real-world incidents, which are often brushed off as a particular vendor or asset owner is at fault. These findings reveal that one of the biggest security problems in OT continues to be the lack of basic controls, and OT-focused attackers have exploited this in practice.

It has been ten years since Project Basecamp, a research project conducted by Digital Bond demonstrated the fragility and insecurity of most SCADA and DCS field devices, and coined the term ‘insecure by design.’ The goal of Project Basecamp is to make the risk of these fragile and insecure devices so apparent and easy to demonstrate that a decade of inaction will end. As a result, SCADA and DCS owners/operators will demand a secure and robust PLC, which will drive vendors to finally provide a product worthy of being deployed in the critical infrastructure.

Forescout said that OT:ICEFALL shows that despite Project Basecamp’s success in raising awareness of the scale and severity of insecure-by-design practices in OT and the past decade of effort by the OT security community. The research acknowledges that insecure-by-design practices are still very much the norm, and those security controls that have been implemented are often of subpar quality. 

“These issues range from persistent insecure-by-design practices in security-certified products to subpar attempts to move away from them,” according to Forescout. “The goal is to illustrate how the opaque and proprietary nature of these systems, the suboptimal vulnerability management surrounding them, and the often-false sense of security offered by certifications significantly complicate OT risk management efforts,” it added. 

Vedere Labs estimates the impact of OT:ICEFALL vulnerabilities based on the evidence collected during the research, using open source intelligence, Shodan queries, and Forescout Device Cloud. Open-source intelligence analyzed product documentation, datasheets, and marketing information that mention where devices are used and their certification security status. The Shodan search engine allows users to look for devices connected to the internet, estimating the number of affected devices based on public data is difficult because these devices are not supposed to be accessible via the internet.

Forescout said that the past decade has seen the advent of standards-driven hardening efforts at the component and system levels. It has also seen impactful real-world OT incidents, such as Industroyer, TRITON, and INCONTROLLER abusing insecure-by-design functionality, which has left many defenders wondering just how much has changed. “One major difference is the increased adoption and proliferation of (certifiable) standards applicable to OT environments such as IEC 62443, NERC CIP, NIST SP 800-82, IEC 51408/CC, and various sector-, region- or protocol-specific (e.g. IEC 62351, DNP3 Security, CIP Security, Modbus Security) standards,” it added. 

These standards-driven hardening efforts have contributed to major improvements in security program development, risk management, and architecture-level design and integration activities. However, these efforts have been less successful at maturing secure development lifecycles for individual individuals systems and components, the Vedere Labs report said. 

“With OT:ICEFALL, we wanted to disclose and provide a quantitative overview of OT insecure-by-design vulnerabilities rather than rely on the periodic bursts of CVEs for a single product or a small set of public real-world incidents that are often brushed off as a particular vendor or asset owner being at fault,” it added. 

“More than one-third of these vulnerabilities (38%) allow for compromise of credentials, with firmware manipulation coming in second (21%) and remote code execution coming third (14%),” Vedere Labs said in its report on Tuesday. “The prime examples of insecure-by-design issues are the nine vulnerabilities related to unauthenticated protocols, but we also found many broken authentication schemes, which demonstrates subpar security controls when they are implemented,” it added.

Forescout said, “since the issues uncovered are the result of insecure design practices affecting core system functionality, many of them will remain unpatched in production environments for a significant amount of time.” The OT:ICEFALL issues primarily affect level 1 and 2 devices and could be used in OT-specific attacks targeting those devices.

Although many vulnerabilities are due to the insecure-by-design nature of OT, an important observation of the findings is that many authentication schemes are broken, which also demonstrates subpar security controls when implemented, Forescout pointed out. Vulnerabilities in OT:ICEFALL related to broken authentication were identified as being broken through plaintext credentials, authentication bypass, or broken cryptography, it added.

Another shocking disclosure made by the Vedere Labs report was that product families affected by the issues had achieved one or more of the following certifications. These include ISASecure Component Security Assurance (CSA) that subsumes Embedded Device Security Assurance (EDSA), based on IEC 62443-4-1 and IEC 62443-4-2. Additionally, the ISASecure System Security Assurance (SSA) certification is based on IEC 62443-4-1 and IEC 62443-3-3. 

Other certifications included GE Achilles Communications Certification (ACC), which is similar to, but not based on, IEC 62443-4-2, and ANSSI Certification de Sécurité de Premier Niveau (CSPN), which is based on Common Criteria. The ISASecure Secure Development Lifecycle Assurance (SDLA) and GE Achilles Practices Certification (APC) were left out of Forescout’s figures due to their implied nature in other certifications. In addition, several products claimed to have a security posture ‘based on IEC 62443’ – in some cases ‘up to SL3/SL4’ but the product lines were not certified.

Forescout said that the vulnerabilities discussed in this research are either the result of insecure-by-design or often-trivial failures of security design. These findings point to serious issues with security standards and certifications for OT. The factors contributing to the situation include (re)certification effort, limited Target of Evaluation (ToE), opaque security definitions, and limited security evaluations.

The Forescout research also highlighted ‘the effects of the opaque nature of OT product on risk management.’ While it is well known that many OT products are insecure-by-design and vendors often recommend that asset owners treat these products by focusing on perimeter hardening and monitoring, the proprietary nature of many components of these systems complicates sound risk management. After all, it is insufficient to know that a protocol or interface is insecure simply, it added. 

“To make informed decisions around segmentation, monitoring, and hardening efforts, asset owners need to know in what way these components are insecure,” the report said. ‘There is a huge difference in potential impact between an attacker’s ability to change a setpoint, which could be limited by logic-based sanity checks and downstream alarms, and their ability to execute arbitrary code on a controller,” it added.

Vulnerabilities in OT supply chain components tend not to be reported by every affected manufacturer, Forescout detected. “We discuss two vulnerabilities with CVEs assigned to the ProConOS runtime that we often encountered in PLCs and RTUs without an associated CVE or public discussion that they were affected,” it added.

The Forescout report also detected insecure-by-design supply chain components, as vulnerabilities in OT supply chain components tend not to be reported by every affected manufacturer. 

As not all insecure designs are created equal, the Forescout report investigates three main pathways to gaining RCE on level 1 devices via native functionality – logic downloads, firmware updates, and memory read/write operations. “None of the systems analyzed support logic signing and most (52%) compile their logic to native machine code. 62% of those systems accept firmware downloads via Ethernet, while only 51% have authentication for this functionality,” it added. 

The research also highlighted the fact that offensive capabilities are more feasible to develop than often imagined. “Reverse engineering a single proprietary protocol took between one day and two man-weeks while achieving the same for complex, multi-protocol systems took 5 to 6 man-months. This shows that basic offensive cyber capabilities leading to the development of OT-focused malware or cyberattacks could be developed by a small but skilled team at a reasonable cost,” it added.

Forescout said in the report that complete protection against the type of issues uncovered in OT:ICEFALL requires that vendors address these fundamental issues with changes in device firmware and supported protocols and that asset owners apply the changes (patches) in their networks. Realistically, that process will take a very long time. 

Some immediately actionable mitigation strategies for asset owners and system integrators include discovering and inventorying vulnerable devices, enforcing segmentation controls and proper network hygiene, and monitoring progressive patches released by affected device vendors and network traffic for suspicious activity. It also advised actively procuring ‘secure-by-design’ products, using native hardening capabilities such as physical mode switches on controllers, and working toward consequence reduction by following Cyber-PHA and CCE methodologies. 

In addition to network monitoring, mitigations for OT:ICEFALL include isolating OT/ICS networks from corporate networks and the internet, limiting network connections to only specifically allowed engineering workstations, and focusing on consequence reduction where possible.

“Hardcoded passwords and lack of authentication may be known knowns within OT security circles but the OT ICEFALL report lists them out in black and white for all to see,” Ron Fabela, CTO & co-founder at SynSaber, wrote in an emailed statement.  “Like Project Basecamp, OT ICEFALL focuses on the low-hanging exploitation fruit of ICS, where exploitation isn’t really necessary at all in most cases. Simply sending the correct command, knowing how to run strings against firmware, or often times just reading the manual will yield the necessary information for attacking these systems.”

“But the community needs to ask the question: does generating CVEs for engineering decisions move the ball forward in securing ICS? While the work of researchers is beneficial from an awareness stance asset owners are left with more ‘vulnerabilities’ that are most likely un-patchable during their operational period,” Fabela added.  

For a community already over-taxed with compliance, breach reporting, and ‘threat actor of the month’ FUD, the hope is that these vulnerability reports motivate real change: improved security from the product vendors and better procurement requirements in the future, Fabela said. “Until then, we have to monitor and protect the critical systems in place now, CVEs or not,” he added.

Earlier this month, Vedere Labs provided details of a new attack approach called Ransomware for IoT or R4IoT. The proof of concept covers next-generation ransomware that exploits IoT devices for initial access, targets IT devices to deploy ransomware and cryptominers, and leverages poor OT security practices to cause physical disruption to business operations. By compromising IoT, IT, and OT assets, R4IoT goes beyond the usual encryption and data exfiltration to cause physical disruption of business operations.

A complimentary guide to the who`s who in industrial cybersecurity tech & solutions

Free Download

Related