Researchers at Forescout’s Vedere Labs wanted to show how insecure many internet-connected operational technology (OT) systems can be. So on Monday they released 56 vulnerabilities discovered across products from nine manufacturers.
Dubbed Icefall, the holes are included in applications such as programmable logic controllers and distributed control systems from big names like Emerson, Honeywell, Motorola, and Siemens. Many of the affected products are used in oil and gas, chemical, nuclear, power generation and distribution, manufacturing, water treatment and distribution, mining, and building automation sectors, says the report.
“Many of these products are sold as ‘secure by design’ or have been certified with OT security standards,” says a detailed technical report. The reality, the report suggests, is many products are ‘insecure by design.’
An attacker able to leverage the vulnerabilities could bypass authentication and then manipulate setpoints and monitoring values relating to a natural gas distributor’s compressor stations to overwhelm operators with false alarms or change flow setpoints to disrupt transport, the report says in one possible attack scenario.
The reality, the report suggests is products are becoming ‘insecure by design.’
One problem, the researchers say, is that some OT manufacturers don’t acknowledge bugs by issuing CVEs, which would at least allow IT and OT leaders to know of and mitigate vulnerabilities.
Related content: Attack on Florida water treatment plant
The researchers group the vulnerabilities under five broad categories:
- Remote code execution (RCE): Allows an attacker to execute arbitrary code on the impacted device, but the code may be executed in different specialized processors and different contexts within a processor, so an RCE does not always mean full control of a device. This is usually achieved via insecure firmware/logic update functions that allow the attacker to supply arbitrary code;
- Denial of service (DoS): Allows an attacker to either take a device completely offline or to prevent access to some function;
- File/firmware/configuration manipulation: Allows an attacker to change important aspects of a device such as files stored within it, the firmware running on it or its specific configurations. This is usually achieved via critical functions lacking the proper authentication/authorization or integrity checking that would prevent attackers from tampering with the device;
- Compromise of credentials: Allows an attacker to obtain credentials to device functions, usually either because they are stored or transmitted insecurely;
- Authentication bypass: Allows an attacker to bypass existing authentication functions and invoke desired functionality on the target device.
More than one-third of these vulnerabilities (38 per cent) allow for compromise of credentials, the report says, with firmware manipulation coming in second (21 per cent) and remote code execution coming third (14 per cent).
“The prime examples of insecure-by-design issues are the nine vulnerabilities related to
unauthenticated protocols,” the report says, “but we also found many broken authentication schemes, which demonstrates subpar security controls when they are implemented.”
Just under three-quarters of the product families affected have some form of security certification, the report adds.
Related content: Threat actors have new tools for attacking ICS, SCADA devices
Vulnerabilities in OT supply chain components tend to not be reported by every affected manufacturer, the researchers also warn. Their report includes a discussion on two vulnerabilities in a runtime operating system in some programmable logic controllers (PLCs) and remote terminal units (RTUs) that don’t have common vulnerability scores (CVE).
The report also says most issues should be discovered relatively quickly with an in-depth vulnerability discovery.
“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,” says the report. “These issues range from persistent insecure-by-design practices in security-certified products to subpar attempts to move away from them. 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.”
“Despite the important role that standards-driven hardening efforts play in OT security,” the report says, “products with insecure-by-design features and trivially broken security controls continued to be certified.”
The report urges manufacturers to issue patches for device firmware and supported protocols. “Realistically,” it adds, “that process will take a very long time.” In the meantime IT and OT leaders should
–discover and inventory vulnerable devices;
–enforce segmentation controls and proper network hygiene;
–monitor progressive patches released by affected device vendors;
–monitor all network traffic for suspicious activity;
–migrate to secure-by-design variants of products where available;
–make use of native hardening capabilities such as physical mode switches on controllers which require physical interaction before dangerous engineering operations can be performed.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has this guide for securing industrial control systems.
While the breadth and depth of the vulnerabilities identified in the report seem like a doomsday scenario, said Ron Fabela, co-founder and CTO, SynSaber, Forescout has just outlined what many of us in the industry already know: Protocols are not secure, unauthenticated, and other ‘insecure by design’ engineering choices that were never really meant to be CVEs. “Again, these are not vulnerabilities as information security would identify them, but truly ‘that’s not a bug, it’s a feature’ for industrial. Protocols were designed to not use authentication, and although there are secure options for industrial protocols, there has been slow adoption. ‘Protocol does not use authentication’ could generate thousands of CVEs across multiple vendors and business lines, because there was never meant to be authentication. But does generating thousands of CVEs, tying up vendor product security teams and asset owners, really cause a positive impact on the security of our critical infrastructure?”
The report is “well constructed, highly detailed, and great insight from a security perspective on legacy ICS ‘vulnerabilities,'” he said. However, he added, because CVE numbers are being generated, this will trigger a swell of unnecessary tracking and management of vulnerabilities with no patch and few mitigations.
