Overview
.jpg)
As part of a Red Teaming engagement for a major Distribution System Operator (DSO), performed jointly with Secura, Midnight Blue developed an offensive capability in order to support a scenario where attackers penetrated substation networks with the intention to cause prolonged blackouts.
The research resulted in the discovery of CVE-2024-8036, which concerns two separate security issues affecting multiple ABB products including the popular Relion protection relays used in electrical substations globally.
As part of a Red Teaming engagement for a major Distribution System Operator (DSO), performed jointly with Secura, Midnight Blue was asked to develop an offensive capability (targeting protection relays controlling circuit breakers) to support a scenario where attackers penetrated substation networks with the intention to cause prolonged blackouts.
This research led to the discovery of two security vulnerabilities, collectively assigned CVE-2024-8036, in multiple ABB products used in the power transmission, distribution, and generation, heavy industry, and maritime sectors (among others). The vulnerabilities in question concern the ability of an attacker to push unsigned firmware and configuration files to these devices in order to achieve persistent denial-of-service (including bricking) or remote code execution effects.
While the research initially focused on ABB's Relion protection relays, subsequent coordinated disclosure with the vendor found several other product families to be also affected.
Note that this advisory will omit certain technical details and proof-of-concept code due to the sensitive nature of the devices involved and the fact that these vulnerabilities are practically unpatchable.
Several product series within the ABB Relion family of Intelligent Electronic Devices (IEDs) were found to allow for malformed configuration updates leading to a denial of service scenario. While configuration updates may require user authentication over Manufacturing Message Specification (MMS), this channel is protected by a password that is commonly left to factory default settings or can be trivially intercepted due to the lack of confidentiality in MMS.
The vulnerability arises because of Improper Handling of Exceptional Conditions (CWE-755) on the IED when a malformed configuration update deletes critical configuration files but does not replace them with functional new ones. Malformed configuration updates can put the IED in an operating mode where it no longer performs its protection and control functionality and cannot be restored through conventional means such as Local HMI (LHMI) based factory resets or using the PCM600 engineering software. Given the crucial role these devices play in operating and protecting the electric grid, the ability to put an IED in such a state poses a significant risk.
In order to carry out this attack, the attacker would perform the following sequence:
This sequence will delete critical configuration files, then change the passwords on the FTP(S) and MMS interfaces, ensure passwords are required for subsequent connections, and change the IP configuration to invalid settings. These changes will cause a subsequent lockout for operators and engineers to complicate recovery.
When the IED reboots, it will initialize without a proper configuration. It will not have a datamodel nor SLD and neither remote nor local control of switchgear and breakers will be possible. In addition, when it initializes without a proper configuration the LHMI menu lacks access to basic settings and control menus and remote connections via MMS are denied.
Several product series within the ABB Relion family of Intelligent Electronic Devices (IEDs) were found to have unsigned firmware updates. While several other ABB product families were found to be similarly affected, this advisory only contains details relevant to the ABB Relion products.
Even though firmware updates are performed over an authenticated channel (FTP or FTPS), this channel is protected by a password that is commonly left to factory default settings or can be trivially intercepted depending on IED configuration settings. The lack of firmware signing allows authenticated attackers to push malicious firmware to the IED, allowing for either covert persistence and low-level access (firmware implanting) or rendering it permanently inoperable through so-called 'bricking'. Given the crucial role these devices play in operating and protecting the electric grid, the absence of firmware signing poses a significant risk.
In order to carry out this attack against the Relion IEDs, the attacker would perform the following sequence:
1. Connect to the IED's FTP(S) service and authenticate with either factory-default or intercepted credentials
2. Navigate to the update folder on the FTP(S) server filesystem
3. Transfer the malicious firmware .bin file to the device which will auto-reboot after completion
The REF615E-1G IED we analyzed consists of three main components which communicate through various interconnects:
1. The CPU board (CPU0007 REV.D), serving as the IED's brain, is built around an MPC8247 PowerPC processor running RTXC Quadros RTOS and an Altera Cyclone III FPGA.
2. The Communications board (COM0037 REV.P), handling internal and external communications, is built around an Altera Cyclone V FPGA.
3. The Display board (DISP0012 REV.M), handling local HMI interaction, is built around a MCF5208 ColdFire processor.
After reverse-engineering the IED and firmware update process, we discovered that while the Relion firmware format contains a listing describing components (e.g. Application, RAM, and FPGA images) and their checksums, these checksums are not cryptographically signed nor bound to a hardware root-of-trust. An attacker can simply create a malicious firmware file with valid checksums that will pass the update mechanism's validation.
Note that "Remote Update" settings need to be enabled in order to allow for remote firmware updates (rather than via the front port interface only).
CVE-2024-8036 could allow an attacker to achieve the following:
1. Remote code execution: An attacker could implant a vulnerable device with malicious firmware in order to covertly and persistently maintain access or have it trigger a secondary payload at a later point in time. Without deep introspection and forensics capabilities, determining whether a device is implanted at the firmware level (even after a factory reset) is infeasible.
2. Persistent Denial-of-Service (Relion only): While recovering from the malicious configuration attack is possible, this requires issuing a factory reset and recommissioning to all devices through a manual walkdown since only front-port communications are still available.
3. Equipment damage (bricking): An attacker could push malicious firmware that simply renders the device inoperable and irrecoverable without specialized hardware intervention (e.g. wiping flash memory and/or causing an infinite boot loop). Such a 'bricking' or wiper approach would require full device replacement, which may not be trivial given limited hardware stock reserves at asset owners.
Such effects would be particularly problematic when used to amplify a disruptive attack manipulating switchgear and circuit-breakers at a substation, and subsequently bricking IEDs to prevent further recovery - similar but more potent to the attempted exploitation of CVE-2015-5374 against Siemens SIPROTEC IEDs during the attacks on the Ukrainian power grid in 2016. Such a use of this vulnerability could prolong power outages by days while grid operators attempt to replace IEDs and restore power without protective functionality.
Given the relative simplicity of the above scenario and the fact that advanced adversaries have been increasingly deploying such bricking payloads against high-profile embedded device targets, such as satellite modems, routers, and NASes, we consider the potential impact of this vulnerability significant.
In collaboration with Midnight Blue and Secura, ABB has prepared Product Advisory Note 2NGA002288 outlining the context and recommended mitigations to address this vulnerability. We recommend asset owners evaluate the risk posed by this vulnerability to their environments and operations and start implementing the recommended mitigations prior to public disclosure the vulnerability.
One of the main takeaways of these issues is that if certain security features with hardware dependencies (e.g. secure boot, configuration and firmware signing, etc.) aren't build into the platforms from the start they cannot be retrofitted without requiring a hardware revision. Especially given long device lifetimes in OT environments, this means such issues can in practice only be (often painstakingly) mitigated rather than fundamentally resolved.
The second takeaway is that the ability to push malicious configurations or firmwares allows for persistent Denial-of-Service attacks requiring either factory resets and recommissioning or even full device replacement. For OT equipment, such DoS attacks are far more serious than conventional network-based DoS or those requiring a simple reboot because they significantly increase the duration of operational disruption. As such, mitigating these type of vulnerabilities should be prioritized over most others.
All items
