System Firmware

System Firmware
Technique
ID	T0857
Tactic	Persistence, Inhibit Response Function
Data Sources	Alarm history, Sequential event recorder, Network protocol analysis, Packet capture
Asset	Safety Instrumented System/Protection Relay, Field Controller/RTU/PLC/IED, Input/Output Server

Description

System firmware on modern assets is often designed with an update feature. Older device firmware may be factory installed and require special reprograming equipment. When available, the firmware update feature enables vendors to remotely patch bugs and perform upgrades. Device firmware updates are often delegated to the user and may be done using a software update package. It may also be possible to perform this task over the network.

An adversary may exploit the firmware update feature on accessible devices to upload malicious or out-of-date firmware. Malicious modification of device firmware may provide an adversary with root access to a device, given firmware is one of the lowest programming abstraction layers.1

In the 2015 attack on the Ukranian power grid, the adversaries gained access to the control networks of three different energy companies. The adversaries developed malicious firmware for the serial-to-ethernet devices which rendered them inoperable and severed connections between the control center and the substation.2

Procedure Examples

• The malicious shellcode Triton uses is split into two separate pieces -- inject.bin and imain.bin. The former program is more generic code that handles injecting the payload into the running firmware, while the latter is the payload that actually performs the additional malicious functionality. The payload --imain.bin-- is designed to take a TriStation protocol get main processor diagnostic data command, look for a specially crafted packet body, and perform custom actions on demand. It is able to read and write memory on the safety controller and execute code at an arbitrary address within the firmware. In addition, if the memory address it writes to is within the firmware region, it disables address translation, writes the code at the provided address, flushes the instruction cache, and re-enables address translation. This allows the malware to make changes to the running firmware in memory. This allows Triton to change how the device operates and would allow for the modification of other actions that the Triton controller might make3

Mitigations

• Human User Authentication - Devices that allow remote management of firmware should require authentication before allowing any changes.

The authentication mechanisms should also support Account Use Policies, Password Policies, and User Account Management.

• Communication Authenticity - Protocols used for device management should authenticate all network messages to prevent unauthorized system changes.

• Network Allowlists - Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.4

• Encrypt Network Traffic - The encryption of firmware should be considered to prevent adversaries from identifying possible vulnerabilities within the firmware.

• Access Management - All devices or systems changes, including all administrative functions, should require authentication. Consider using access management technologies to enforce authorization on all management interface access attempts, especially when the device does not inherently provide strong authentication and authorization functions.

• Software Process and Device Authentication - Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.

• Boot Integrity - Check the integrity of the existing BIOS or EFI to determine if it is vulnerable to modification. Use Trusted Platform Module technology.5 Move system's root of trust to hardware to prevent tampering with the SPI flash memory.6 Technologies such as Intel Boot Guard can assist with this.7

• Code Signing - Devices should verify that firmware has been properly signed by the vendor before allowing installation.

• Encrypt Sensitive Information - The encryption of firmware should be considered to prevent adversaries from identifying possible vulnerabilities within the firmware.

• Network Segmentation - Segment operational network and systems to restrict access to critical system functions to predetermined management systems.4

• Update Software - Patch the BIOS and EFI as necessary.

• Filter Network Traffic - Filter for protocols and payloads associated with firmware activation or updating activity.

• Audit - Perform integrity checks of firmware before uploading it on a device. Utilize cryptographic hashes to verify the firmware has not been tampered with by comparing it to a trusted hash of the firmware. This could be from trusted data sources (e.g., vendor site) or through a third-party verification service.

References

1. ^  Basnight, Zachry, et al.. (n.d.). Retrieved October 17, 2017.
2. ^  Electricity Information Sharing and Analysis Center; SANS Industrial Control Systems. (2016, March 18). Analysis of the Cyber Attack on the Ukranian Power Grid: Defense Use Case. Retrieved March 27, 2018.
3. ^  DHS CISA. (2019, February 27). MAR-17-352-01 HatMan—Safety System Targeted Malware (Update B). Retrieved March 8, 2019.
4. a b  Department of Homeland Security. (2016, September). Retrieved September 25, 2020.

5. ^  N/A. (n.d.). Trusted Platform Module (TPM) Summary. Retrieved September 25, 2020.
6. ^  ESET Research Whitepapers. (2018, September). LOJAX First UEFI rootkit found in the wild, courtesy of the Sednit group. Retrieved September 25, 2020.
7. ^  Intel. (n.d.). Intel Hardware-based Security Technologies for Intelligent Retail Devices. Retrieved September 25, 2020.