Nozomi Networks Labs is proud to have participated in the Swiss Cyber Defence Campus’s ICS Hackathon this past September 2022. During the event, our team spent three days researching vulnerabilities and reverse engineering firmware; we were especially focused on Hitachi Energy Relion 650/670 series, a protection and control IED.
Once the team gained a basic understanding of some of the features present in the firmware, we started to experiment with some attack paths on the provided devices. If some of them turned out to be non-exploitable, then on the last day we had the opportunity to look at the firmware validation mechanism.
In this blog we will discuss how we discovered this vulnerability, share a list of affected configurations, and provide mitigations to immediately implement.
Background
When trying our exploit, we noticed the Hitachi Energy Relion’s screen turning off, symptomatic of a system crash, so we did some more investigating. One of the testing racks on which the vulnerability was developed is shown below in Figure 1.
The task was no small feat, as firmware often are exceptionally large executable files, in which dependencies are usually statically linked. This Relion firmware is no exception, with several services and features built into the firmware itself, including two different FTP servers. This means that to gain an understanding of the firmware features, plenty of time is spent researching and making sense of the functions used by the firmware. An example of that is shown below in Figure 2. First, we show a firmware function FTP HELP before analysis, followed by the same function post-analysis.
As the reverse engineering progressed, and the team gained more understanding on the features present in the firmware, we started to build some attack paths. While we investigated other aspects of the device, we focused our analysis on the firmware update mechanism, speculating that there was a complex attack surface beneath. Eventually, the investigation paid off.
The specific vulnerability found by our team exploits the firmware update mechanism on the Relion 650/670 series. Notably, a malicious update package can be sent to device during the update procedure, crashing the device. However, for the vulnerability to work, the device must have the FSTAccess parameter enabled.
Unfortunately, we did not manage to fully trace the vulnerability back to the affected code in the firmware before the Hackathon concluded. Our speculation is that the vulnerability causes a heap overflow, which might be leveraged to allow remote code execution on the device, but we cannot be certain, as we did not have the time to build an exploit nor set up a debugging environment.
Hitachi Energy Relion Vulnerability Found
While analyzing the Hitachi Energy Relion 650/670 firmware, we found one vulnerability:
- CVE-2022-3864: Update package validation vulnerability (CWE-), CVSS v3.1 4.5 (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H)
This vulnerability affects the following configurations:
- Relion 670/650 series version 2.2.0 all revisions
- Relion 670/650/SAM600-IO series version 2.2.1 all revisions
- Relion 670 series version 2.2.2 all revisions
- Relion 670 series version 2.2.3 all revisions
- Relion 670/650 series version 2.2.4 all revisions
- Relion 670/650 series version 2.2.5 all revisions
As the development of a patch is still in progress, technical details on the PoC request used have voluntarily been omitted from this article.
Requirement and Impacts
Although the vulnerability is triggered when updating the Hitachi Energy Relion firmware using a malicious update package, there are some major preconditions to the exploitation of the vulnerability: first, the FSTAccess mode must be enabled on the device, and second, the threat actor must know a set of credentials to initiate the update procedure.
We see two potential ways to exploit this vulnerability:
- First and most obvious, a threat actor with remote access to the Relion device where FSTAccess is enabled and a valid set of credentials to access the device can initiate the update procedure and supply the malicious update package.
- Second, the threat actor might perform a watering hole attack to supply the malicious update package to the Relion’s operator. For instance, by running a spear-phishing campaign targeting the operators and promoting a new firmware for the Relion 650/670 series. An alternative could also be, if the threat actor has already compromised some systems within the victim environment, to tamper with the victim knowledge center and file shares hosting the firmware packages, at which point, operators could use this malicious update package when updating the device.
Mitigation for Hitachi Energy Relion 650/670 Vulnerability
While waiting for a patch from Hitachi Energy (which is in progress), we recommend the following mitigations:
- Ensure the FSTAccess mode is disabled on the affected devices. If needed, only turn it on during the update procedure and turn it back off once done. For detailed instructions on how to disable the “Field Service Tool access”, please follow the referent product Technical Manual;
- Ensure the update packages are always downloaded directly from Hitachi Energy and over a secure channel;
- Avoid storing the update package on untrusted file shares and other medium, always download fresh versions until the vulnerability is fixed.
For more information, see Hitachi Energy security advisory: Update package validation Vulnerability in Hitachi Energy’s Relion® 670, 650 and SAM600-IO Series Products
Summary
Update mechanisms are a typical exploitation vectors for a lot of hardware devices and are often surprisingy simple to abuse. Adversaries can leverage these vulnerabilities to install implants that may, in some cases, be flash resilient offering them an exceedingly high level of persistence within the victim environment. Be extremely careful when obtaining update packages for your devices – always get them from the supplier directly, never from an intermediary. Try not to store them anywhere in your environment, as they could ultimately be tampered with by the adversary.
We would like to thank Armassuisse, The Federal Office for Defence Procedure in Switzerland, and all the organizers for hosting this event. We took great pleasure in participating, and hope to attend again shall the occasion occur. We would also like to thank all event participants for their hard work and the thrilling discussions we had. Finally, we would like to thank Hitachi Energy PSIRT for their quick response and professional handling of the disclosure process.
