RELATED STORIES

• Security Leads the Way for Digital
• Safety ‘Hops on Digital Train’
• As Digital Advances, So Does Cybersecurity
• OT Cybersecurity: The Backbone To Industrial Digitalization

Researchers divided the vulnerabilities in OT:ICEFALL into four categories:

1. Insecure engineering protocols
2. Weak cryptography or broken authentication schemes
3. Insecure firmware updates
4. Remote code execution via native functionality

Vendors involved in the research include, Bently Nevada, Emerson, Omron, Siemens, Honeywell, Yokogawa, Motorola, Phoenix Contact, and JTEXT. There are four vulnerabilities affecting one vendor still under disclosure.

Although the impact of each vulnerability is highly dependent on the functionality each device offers, they fall under the following categories: Remote code execution (RCE), denial of service (DoS), file/firmware/configuration manipulation, compromise of credentials, and authentication bypass.

“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,” the researchers said. “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.”

Not all security experts agree the report helps secure the OT environment.

“This OT:ICEFALL report from Forescout is not a serious or responsible vulnerability disclosure. Not only are most of the products old and often end-of-life, but these vulnerabilities are also old news,” said Eric Byres, chief technology officer at software bill of material (SBoM) provider, aDolus. “For example, check this one out – ‘The Honeywell Modbus TCP and Safety Builder protocols have no authentication’ – no shit – it is Modbus we are talking about. Or ‘The SRTP protocol transmits passwords in plaintext’ – I think someone demo’d that at S4x13 or S4x14!

“I also think they have been irresponsible; there is no useful public data that an asset owner can use to plan a mitigation strategy in either the CVE or NVD databases (at least not for all of the ones that I searched for). Here is the typical CVE notice when I search for one like CVE-2022-30268 ‘** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.’

Need More Details
“This is problematic because they’ve not provided sufficient version details to understand what products were tested and are at risk. For example, I think the Experion PKS Safety Manager is 20 years old – have they checked all the versions, or the even the latest version?

“For a specific example, check out the vulnerabilities noted in the report on Siemens WinCC Open Architecture (OA). Then check out the advisory on the Siemens website:

“’ETM immediately analyzed the claims made in these reports. Based on our level of information, they are based on WinCC Open Architecture (OA) version 3.15.

“’We thank the researchers of FORESCOUT for identifying a security problem if one does not use and correctly configure available security features of the product:

“’Server-side authentication is available in the version under evaluation (V3.15, released in January 2017) but not configured by default.

“’Additionally, certificate-based authenticated and encrypted communication via AD (active directory) integration and Kerberos has been available since V3.8 (released November 2008) but must be configured the right way…

“’Beginning with version 3.17, we made server-side authentication the default configuration to avoid the problems identified.’

“I immediately noticed Siemens/ETM don’t actually know what versions Forescout is testing. Clearly, it appears Forescout has not communicated with Siemens in advance of this disclosure. Similarly Forescout provided none of the critical version information in their public notice. If they haven’t tried to talk to Siemens before they published this report, then that is just plain irresponsible.

Supply Chain Details Needed
“The one topic that does deserve some serious consideration is section 3.6. Supply Chain Issues: the ProConOS/eCLR Runtime Case. This is basically what Rob Lee said at (the S4x22 security conference in April) – the lack of reliable supply chain information is resulting in asset owners not knowing when they are vulnerable. Asset owners know the PLC manufacturer, not the manufacturer of the underlying OS and yet the vulnerabilities are only listed against the OS manufacturer. So the asset owners don’t know they are at risk.

“So frankly I think this appears to be a rather sloppy marketing grab and not an attempt to help make OT more secure,” Byres said.

An additional security expert said he is hoping this leads to stronger security coming from the vendors.

“Harkening back to Digital Bond’s Project Basecamp over a decade ago, Forescout’s Vedere Labs lists in detail the continued challenge of ‘insecure by design’ in industrial control systems,” said Ron Fabela, CTO and co-founder of SynSaber. “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. 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.

Looking for Real Change
“Instead, 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. 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. Until then, we have to monitor and protect the critical systems in place now, CVEs or not.”

Some of the main findings of the Vedere Labs research include:

• Insecure-by-design vulnerabilities abound: More than a third of the vulnerabilities found (38 percent) allow for compromise of credentials, with firmware manipulation coming in second (21 percent) and remote code execution coming third (14 percent).
• Vulnerable products are often certified: 74 percent of the product families affected by OT:ICEFALL have some form of security certification and most issues should be discovered relatively quickly during in-depth vulnerability discovery. Factors contributing to this problem include limited scope for evaluations, opaque security definitions and focus on functional testing.
• Risk management is complicated by the lack of CVEs: It is not enough to know that a device or protocol is insecure. To make informed risk management decisions, asset owners need to know how these components are insecure. Issues considered the result of insecurity by design have not always been assigned CVEs, so they often remain less visible and actionable than they ought to be.
• There are insecure-by-design supply chain components: Vulnerabilities in OT supply chain components tend to not be reported by every affected manufacturer, which contributes to the difficulties of risk management.
• Not all insecure designs are created equal: Researchers investigated 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 52 percent compile their logic to native machine code. 62 percent of those systems accept firmware downloads via Ethernet, while 51 percent have authentication for this functionality.
• 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 five to six 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.

Vedere Labs researchers found the products affected by OT:ICEFALL are known to be used in oil and gas, chemical, nuclear, power generation and distribution, manufacturing, water treatment and distribution, mining, and building automation.

In addition, the researchers were able to see more than 5,000 of the affected devices exposed online via Shodan. Most of these are Saia Burgess and OMRON controllers or devices running the ProConOS runtime.

“We queried (Forescout) Device Cloud for the vulnerable devices and found close to 30,000 results,” the researchers said.

To mitigate the OT:ICEFALL vulnerabilities vendors should issue changes in device firmware and supported protocols and asset owners apply the changes (patches) in their own networks.

“Realistically, that process will take a very long time,” the researchers said. “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.”

In addition, asset owners 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 malicious packets

Click here to view the technical report.