A new analysis of data from multiple sources has uncovered a total of 56 vulnerabilities in OT products from 10 vendors, including notable ones such as Honeywell, Siemens, and Emerson.

Many of the vulnerabilities are the result of device vendors not including basic security mechanisms, such as authentication and encryption, in their technologies. Often they exist in older products that asset owners are continuing to use even though more secure options are available. Significantly, the vulnerabilities are present in products that have gone through some sort of auditing process and were certified as being safe for OT networks, a new study by Forescout found.

Researchers from Forescout’s Vedere Labs discovered the vulnerabilities from data they gathered via open source intelligence, Shodan search-engine queries, and customer networks. The vulnerabilities exist in widely used products and protocols in a range of critical infrastructure sectors, such as oil and gas, chemical, nuclear, and power generation. The security vendor released a report Tuesday highlighting the main findings from its study.

The vulnerabilities — collectively labeled “OT: Icefall” — stemmed from four primary reasons: insecure engineering protocols, weak cryptography or broken authentication mechanisms, insecure firmware updates, and native functions that enabled remote code execution. The bugs enabled a variety of malicious activity, including remote code execution, denial-of-service attacks, file and configuration manipulation, authentication bypass, and credential theft. Affected devices included programmable logic controllers, remote terminal units, engineering workstations, distribute control systems, and one supervisory control and data acquisition (SCADA) system.

Insecure by Design

The flaws were not introduced by programming and coding errors, says Daniel dos Santos, head of security research at Forescout. Rather, the technologies are vulnerable to attack because they are insecure by design, Santos says. They often lack critical controls like those needed to authenticate users and actions, encrypt data, and verify whether firmware updates and software are signed and verified. When these mechanisms are present, they are often weak and easily hacked or seriously undermined by other issues, like the presence of hard-coded and plaintext credentials on the device, insufficient randomness and broken crypto, or features that allow arbitrary file writes, he says.

“While it’s a semantic difference and ends up with the same vulnerabilities, it’s not so much they are 'insecure by design' as they are designed without security as a consideration,” says Mike Parkin, senior technical engineer at Vulcan Cyber. “Stronger security has been baked into newer OT equipment, but there is still a lot of kit out there where it just wasn’t a consideration." 

In many cases OT technology was designed with the idea that it would be isolated, protected from outside access, and not exposed to anything but its operational environment. “Unfortunately, the real world wasn’t quite so cleanly defined,” he says.

Foresight found numerous instances of vulnerabilities tied to poor design. For instance, 38% of the vulnerabilities that Forescout discovered allowed for credential compromise, and 21% gave attackers a way to introduce poisoned firmware into the environment. Fourteen percent of the flaws stemmed from native functionality — such as logic downloads, firmware updates, and memory read/write operations — that gave attackers a way to execute malicious code remotely on OT systems. 

For example, none of the affected systems supported logic signing, 62% accepted firmware downloads via Ethernet, and 51% authenticated such downloads. Nine of the 56 flaws that Forescout discovered were related to unauthenticated protocols.

(Not) Certifiably Secure

Disturbingly, nearly three-quarters — 74% — of the vulnerable product families had some sort of certification regarding their suitability for use in critical OT environments. Examples of such certifications included ISASecure Component Security Assurance, ISASecure System Security Assurance (SSA), GE Achilles Communications Certification, and ANSSI Certification de Sécurité de Premier Niveau. 

The fact that vulnerable products were certified as compliant with these standards suggests product evaluations were likely limited in scope, were too focused on functional testing, or were hobbled by opaque security definitions, Forescout said.

The presence of vulnerabilities stemming from insecure design in OT devices and protocols is troubling because of the growing attacker interest in these environments, Santos says. He points to ICS- and OT- specific malware such as Industroyer, Triton and Incontroller as evidence of the increasingly sophisticated capabilities that attackers have begun to deploy in attacking ICS and OT facilities. 

“There is still this lingering notion that attackers don’t understand the environment or proprietary OT technology,” Santos says. 

That is simply not true, he says. Nation-state actors and even well-resourced ransomware groups have demonstrated their ability to access OT environments. Detailed information on OT environments is also available in the public domain and equipment for testing out attacks are easily available in markets for used technology products, he notes.

“OT/ICS and IoT environments are becoming the preferred targets by cybercriminals, for many reasons,” says Bud Broomhead, CEO at Viakoo. 

Among them is the growing use of vulnerable open source components — such as Log4j — in OT/ICS environments and the fact that the systems are often managed outside the IT department. 

“Often OT/ICS teams lack the IT skills to maintain complete cyber hygiene” and are focused on operational issues instead, Broomhead says. As a result, there is little oversight over patching practices and password management. OT/ICS devices are often also not visible to IT, or sometimes to the organizations managing them. 

Another issue is that devices are often used well past the manufacturer's support time frame. 

“Many OT/ICS devices are in operation past the time the manufacturer is supporting patches or updates,” Broomhead says. “Security solutions used for IT systems do not work for OT/ISC environments. OT/ICS devices do not accept agents, and therefore organizations must implement solutions, such as for patching, certificate management, and password rotations specifically designed for OT/ISC environments.”

Parkin also urges organizations to pay attention to the fundamental security practices such as keeping patches up to date and implementing proper network segmentation and isolation to keep OT and ICS environments away from public access. 

“The management and control platforms should have proper isolation and authentication, including multi-factor authentication, and there should be some kind of traffic monitoring in place to make sure [OT] is only being accessed by authorized users from authorized locations,” he says.