In June 2022 Vedere Labs published the ‘OT Icefall’ report disclosing 56 CVEs related to insecure-by-design functions affecting devices from 10 major OT manufacturers.

The impact these vulnerabilities have is that they allow for a take-over, DoDs, or operational impacts on thousands of devices that are either exposed online or found in Critical Infrastructures verticals such as Power Generation & Distribution, Oil & Gas, Water Treatment & Distribution, Building automation etc.

Often there are no patches for these vulnerabilities which is related to the insecurity-by-design where many types of OT equipment are designed without basic security controls.

The insecurity-by-design approach to OT has manifested in the past decade through a number of incidents – attacks launched against the Ukrainian power grid (Industroyer), a petrochemical plant in Saudi Arabia (TRITON) – or a discovery of novel industrial CIS-oriented attack tools designed to target machine automation devices (Incontroller).

Vedere Labs has concluded that the biggest issues facing OT security is the previously mentioned persistent lack of basic security controls as well as the opaque and proprietary nature of the OT systems and lack of awareness of what the fact of insecurity-by-design means for the asset owners.

Vulnerabilities by type and impact

The 56 discovered CVEs can be split into four main categories:

• Insecure engineering protocols
• Weak cryptography or broken authentication
• Insecure firmware updates
• Remote code execution

Affected vendors include such distinguishable brands as:

• Honeywell
• Siemens
• Motorola
• Omron
• Emerson
• others

Looking at the types of vulnerabilities, the majority of them – 38% – were related to the Compromise of Credentials followed by Firmware Manipulation – 21% – and Remote Code Execution – with 14% – making a total of nearly ¾ of all vulnerability types.

Vulnerable but Certified 

Many vulnerable products are certified.

74% of the vulnerable products analysed by Vedere Labs had some sort of security certification. There are several factors contributing to this such as opaque security definitions, however more important than the reason for insecure devices having a security certification is the fact that the asset owner might have a false impression of the security status of such device.

Knowing your insecurity is crucial

Although it is widely recognised that many OT products are insecure-by-design, and asset owners are advised to focus on perimeter hardening and monitoring, the proprietary nature of many components of these systems makes it difficult to implement sound risk management practices.

This is because proprietary components often lack transparency and cannot be audited, which makes it challenging for asset owners to identify vulnerabilities and manage risk effectively. It is crucial to know in what way a component is insecure.

Insecure-by-Design Supply Chain Components

OT supply chain components affected by vulnerabilities are not reported by all affected manufacturers.

A component, which in this case has been subjected to a detailed analysis as an example of supply chain issues is the ProConOs runtime.

In the past, there have been CVEs assigned to this protocol, but they never propagated down the supply chain to other vendors that were using it. As result there are devices on the factory floor using this runtime without CVEs assigned to them and as a result asset owners are unaware that such devices are vulnerable since they are using a component insecure-by-design.

Native functionality and RCE on level 1 

Typically, there are three main pathways to gaining RCE on level 1 devices by relying on native functionality:

1. Logic Downloads – none of the systems analysed supported logic signing and runtime security measures. This gives an attacker the ability to execute native machine code on a controller with capabilities way beyond simple logic modification.
2. Firmware Updates – 62% of the updates are happening over the Ethernet with only 51% of them having authentication for this functionality (and even this was in the form of hardcoded credentials in some cases)
3. Memory Read & Write Operations – Many proprietary OT protocols contain numerous undocumented commands that enable memory read or write operations. This aspect has not been thoroughly examined. Some of these operations are limited to manipulating operational variables, while others directly manipulate a device’s internal memory organization in the form of an object- or block-based scheme.

About this article

This article was prepared based on the Vedere Labs ‘OT:ICEFALL’ report from 2022 which can be accessed here

Related posts

Add a comment