OT Cyber Attack Workshop [ Case Study 05 ]: Drone Firmware Attack and Defense
This week we will introduce the fifth workshop case study : Drone OT/IoT Firmware Attack and Defense with the new drone terrain matching and auto pilot control system. In this case study we will also show the blue team's firmware attestation and firmware attack defense progress. We will comprehensively cover the attack tactics, techniques, and procedures (TTPs) and will include practical demonstrations of OT firmware attack and defense.
Program Design Purpose: The objective of this cyber attack case study is aim to develop a workshop using the terrain-matching drone system and dynamic firmware attestation algorithm introduced in paper [PAtt: Physics-based Attestation of Control Systems] to illustrate a practical demonstration of OT/IoT device firmware attack and the corresponding attack detection mechanisms. The terrain-matching drone is built by one Arduino, four distance sensors and one DJI Tello un-programable drone. The attack scenario involves a red team attacker injecting malicious code into the drone's terrain contour generation unit firmware, disrupting the drone auto landing process, and leading to a simulated drone crash. Simultaneously, the case study also showcases how blue team defenders employ the PATT firmware attestation function to identify the firmware attack in real-time, preventing the accident and highlighting the importance of robust defense mechanisms in securing operational technology and internet of things devices.
Attacker Vector : Firmware Attack, Malicious Firmware Updates (OT), IoT Supply Chain Attacks
Important : The demonstrated attack case is used for education and training for different level of IT-OT cyber security ICS course, please don't apply it on any real world system.
Attack Scenario Demo Video:
Introduction
This case study aims to develop a smart drone system capable of emulating specific Industry 4.0 (I4.0) drone autopilot use case, including autonomously tracing routes, environment sensing (Terrain matching), transfer items and making decisions for subsequent actions. The objective is to demonstrate the potential impact of an Operational Technology (OT) firmware attack on such a system. The project is structured into three key sections:
DJI Tello Terrain Matching Drone Control
In this project, our aim is to enhance the capabilities of the DJI Tello mini drone, which is inherently unprogrammable, in order to simulate actions commonly performed by industry drones, such as following predefined routes and transporting items within a factory setting. The DJI Tello drone, being a basic unprogrammable model, requires additional features to emulate more complex tasks. To achieve this, we have integrated four additional ultrasonic sensors onto the drone, enhancing its ability to "detect" a more intricate environment. The autopilot control is executed by a main drone control program running on the connected computer.
The bottom sensor of the DJI Tello, along with the four added distance sensors, collaborates to generate a comprehensive "5 points" ground contour map of the drone's surroundings. The primary drone controller, housed on the control computer, orchestrates the drone's movements to simulate autopilot actions and follow predefined routes based on the acquired contour map data.
The bottom sensor of the DJI Tello, along with the four added distance sensors, collaborates to generate a comprehensive "5 points" ground contour map of the drone's surroundings. The primary drone controller, housed on the control computer, orchestrates the drone's movements to simulate autopilot actions and follow predefined routes based on the acquired contour map data. For instance, if the objective is to make the drone fly straight until it detects an object resembling a table beneath it, and then proceed to land on that table (simulating the transfer of items from one table to another), the drone continually transmits the contour map to the control program. The drone control program analyzes the received contour matrix and if it matches the predefined features of a table, it will issue the landing command to the drone. The typical terrain matching process is illustrated below:
Remark: In the program design section of this document, we will provide a detailed overview of the DJI Tello Drone controller program. This comprehensive discussion will cover essential aspects, including the intricate usage of drone basic motion control, the functionality of track editing, the ground simple contour matching process, and the drone motion safety check function. This information is intended to empower users with the necessary insights and tools to plan and execute complex routes for the drone, ensuring a seamless and safe operation.
Firmware Attack Demonstration
In this malicious firmware updates attack scenario, the red team attacker's target is the firmware program running on the drone's CMGU (contour map generation unit). CMGU is crucial for fly environment monitoring and terrain matching, it comprises an ESP8266 Arduino, a battery, and four HC-SR04 Ultrasonic Sensors. During the attack demo, the red team attacker did exploiting a vulnerability in the IoT supply chain, sent a deceptive firmware update email to a negligent drone maintenance engineer, resulting in the installation of the malicious firmware in the contour map generation unit. The attack underscores the critical importance of securing the IoT supply chain to prevent unauthorized firmware alterations and potential operational disruptions. The attack path is shown below :
The rogue firmware behaves inconspicuously during manual drone control or when following predefined routes. However, it activates malicious functionalities when the drone initiates autopilot mode for ground contour matching. Specifically, the firmware introduces random "noisy" distance data, deliberately distorting the accuracy of ground contour information. This misinformation misguides the drone controller, leading to incorrect decision-making and, consequently, drone accidents such as crashes.
Arduino Firmware Attestation
In this segment, we will illustrate how a drone operator can employ the dynamic, real-time firmware attestation to not only detect the attack but also prevent potential accidents involving the drone. To achieve this, we adopt a portion of the PLC firmware attestation algorithm outlined in the paper "PATT"( Physics-based Attestation of Control Systems) to verify whether the firmware attack has happened. We will follow the "Nonce Storage and Hash Computation" part introduced in the paper to dynamically calculate the firmware's hamming hash with the k=4 as shown below :
It's essential to express our thanks for the Physics-based Attestation of Control Systems paper authors Dr.Hamid Reza Ghaeini and Professor Jianying Zhou from SUTD for introducing the efficient and robust firmware attestation algorithm.
Key Tactics, techniques, and procedures (TTP) of the attack
Based on the attack detailed road map introduced in the attack demo section, there will be two kinds main TTP included in the firmware attack scenario :
Malicious Firmware Development
Supply Chain Compromise
Background Knowledge
Within this section, we aim to provide fundamental, general knowledge about each respective system and elucidate the Tactics, Techniques, and Procedures (TTP) associated with the attack vectors. This foundational information will serve as a primer for understanding the intricate details of the systems involved and the methodologies employed in the attack scenarios.
DJI Tello Drone Control and Terrain Matching
Before delving into the technical aspects of the attack, it's essential to provide an overview of the platform utilized in our case—the DJI Tello Drone Terrain Matching system.
Our aim was to transform a conventional, unprogrammable drone into an intelligent device. To achieve this, we strategically installed four HC-SR04 Ultrasonic Sensors beneath the DJI Tello Drone, as illustrated below. Connecting these sensors to an ESP8266 Arduino's GPIO pins (`GPIO5-D1`, GPIO4-D2, GPIO0-D3, and GPIO2-D4) allowed us to interface with the sensors' data positive (+) pins. The contour map generation code, executed on the Arduino, reads distance data and performs averaging every 0.5 seconds. This process ensures the creation of a stable and accurate 4-point contour map of the drone's bottom area. The battery and Arduino are attached on the top of the drone and the 4 sensors are installed at the bottom of the drone, the hardware design and the wire connection is shown below:
We also developed a UI control program with all the trojan flight control function such as vertical/horizontal movement, flight attitude(row pitch yaw) adjustment and trace route. The ESP8266 will transmitting the 4-points drone bottom area contour map matrix back to the control program and this data is seamlessly integrated with readings from the drone's bottom height sensor for enhancing the precision and versatility of the drone's terrain-matching capabilities. The control program UI and the terrain-matching logic is shown shown below:
The Terrain Matching module within the drone controller meticulously scrutinizes the generated drone bottom area contour map against its pre-established contour map matrix. If the disparity falls below a predefined threshold, the control program recognizes a successful "Terrain Match." Following a consistent match duration of 2 seconds, the control program initiates the execution of a pre-set flight action timeline or route playbook for the drone. This could include specific instructions, such as directing the drone to perform a landing maneuver on the identified surface.
OT/IoT Firmware Attack
A firmware attack is any malicious code that enters your device by using a backdoor in the processor’s software. Backdoors are paths in the code, which allow certain individuals to bypass security and enter the system. The backdoor normally goes undetected due to its intense complexity, but can result in serious consequences if exploited by hackers.
A common example of a firmware attack is an unauthorized update on your computer or phone that results in malware or some other form of cybercriminal activity. This is because many updates include backdoors with undocumented features or functions that can be used for adverse actions, such as intercepting data without notice and turning off core functionalities; all while still masquerading itself as an innocent update process.
Reference link: https://netacea.com/glossary/firmware-attack/
In the course of the attack demonstration, the red team attacker's focus is on the firmware of the ground contour generation unit, as illustrated in the preceding section. The attack involves injecting malicious code into the firmware portion responsible for reading data from the distance sensors, introducing a random offset to distort the real data and disrupt the ground contour generation process. Before the attack, the drone adheres to a predefined flight pattern, flying straight until it identifies another table that matches its pre-saved ground contour—interpreted as a safe landing location—where it proceeds to land. However, post-firmware attack, the manipulated ground contour generation results cause the drone to perceive an unsafe area as a matching contour. (As shown in the demo video)
PAtt: Physics-based Attestation of Control Systems
PAtt is designed to do the remote firmware attestation of logic code running on a PLC without a traditional trust anchor (such as a TPM or PUF). For the PAtt: Physics-based Attestation of Control Systems please refer to Dr.Hamid Reza Ghaeini and Professor Jianying Zhou's Paper: https://www.usenix.org/system/files/raid2019-ghaeini.pdf
In our project we followed the idea of "Nonce Storage and Hash Computation" introduced in the paper to dynamically calculate the firmware's hamming hash with the k=4 to verify the firmware running on ESP8266 Arduino.
System Design
Within this section, we will outline the design of the system, comprising four key components:
Drone Controller UI design
The Drone controller encompasses distinct function panels designed to empower the drone operator with comprehensive control over the drone's flight. It facilitates the setting of flight routes, loading of terrain matching configuration files, and monitoring of the contour generation unit data. The main thread of the drone controller initiates three parallel sub-threads, each dedicated to vital tasks—communicating with the Arduino for data retrieval and firmware attestation, reading Tello-Drone states data, and obtaining the Tello's UDP video stream. Simultaneously, the main thread manages Tello flight control. The Drone controller's user interface features six primary panels, detailed below:
领英推荐
The Drone control UI contents 6 different function panels :
Communication Protocol Design
The drone control computer establishes connectivity with the drone through two distinct WIFI links:
The communication link is shown below:
As shown in the above diagram, there are 4 wireless channels between the drone controller computer and the drone. The control hub (Computer) will communicate with the drone by UDP and fetch the feedback data of Ground contour generator by TCP. The channels details are shown below:
The ground contour generator firmware attestation communication shares the same channel with the Ground contour generator data channel. Consequently, when the attestation process initiates, the ground contour generation function temporarily suspends data transmission to allow the channel's utilization for transferring PATT data. This synchronization ensures an efficient and coordinated exchange of information during the attestation phase without interference from ongoing data transmissions.
Design of Malicious Code and the Firmware Attack
The red team attacker follows the steps outlined below to execute the firmware attack:
The attacker initiates the process by downloading the standard firmware file, esp_client.ino.generic.bin from an authorized firmware server.
Utilizing a reverse engineering tool, the attacker decompiles the binary to extract a portion of the firmware's C++ source code.
Conducting a thorough analysis of the code, the attacker identifies the method employed for distance calculation—utilizing the sensor to generate a sound pulse, measuring the time interval between sending the pulse and receiving the echo, and then multiplying the time by the speed of sound while dividing by 2. With a comprehensive understanding of the underlying logic, the red team attacker introduces malicious code into the firmware, as depicted below:
In the introduced malicious code, the attacker strategically inserts a random delay (ranging from 0 to 300 microseconds) both before and after the pulse, introducing inconsistency to the echo time. Additionally, a random value within the range of -3 to 8 is added to the distance result, imparting a variable offset to the final measurement, spanning between -30cm to 80cm.
Subsequently, having incorporated the malicious alterations, the attacker compiles the deceptive firmware and dispatches it to the drone maintenance engineer via a fabricated ground contour generator unit firmware update email.
Upon receiving the firmware, the maintenance engineer proceeds to load it onto the ground contour generator unit. Upon powering up, the unit provides some feedback data. As the engineer refrains from initiating drone takeoff, the distance data appears ostensibly normal, leading him to assume that the firmware is functioning as expected—unaware of the underlying malicious alterations. The disparity in the contour map sent back to the controller becomes evident, as illustrated below:
During operational tasks where the drone is tasked with transferring items from one table to another, a critical issue arises. As the drone takes off, its ground contour generator unit consistently produces deceptive distance data. This discrepancy in data leads the drone to make inaccurate landing decisions, resulting in unintended landings on the ground or, in more severe instances, causing a crash.
Design of the Firmware Attestation
To verify the firmware, the control computer side will also keep firmware repository which contents copy of valid different version firmware and simulate the firmware loading to memory which same as the Arduino. The detailed attestation steps are outlined below:
The main communication flow is shown below (System execution workflow UML diagram) :
Program Usage/Execution
Run the Program
Follow the section "WIFI Connection Diagram" to connect to the sensor and drone to your computer. Then execute the program telloRun.py under src folder by the below command:
python telloRun.py
Load the ground matrix file
To active the Terrain Matching function, the drone operator needs to change the config file's Terrain Matching Flag to True after that when start the UI, the loading button will show up. Then Press the "loadCont" button and the count file selection dialog will pop up as shown below :
Then select the contour JSON file you want the drone to match during track the route, one simple contour example is shown below:
{
"sensorLF" : [1.33, 1.23]# The drone left front sensor reading
"sensorLB" : [1.33, 1.24] # the drone left back sensor reading
"sensorMD" : [1.12, 1.20]# the drone mid height sensor reading
"sensorRF" : [1.33, 1.23] # The drone right front sensor reading
"sensorRB" : [1.33, 1.24] # the drone right back sensor reading
"threshold" : 0.15 # matching threshold
"matchingT" : 2 # time to trigger matching (second)
"tackID" : "trackLanding" # track to be executed after terrain matched.
}
Drone Control and PATT firmware attestation
The drone operator can do the firmware attestation during the drone is flying, but we recommend drone operator do the attestation before the drone take off. The detailed step to do one attestation is shown below:
TrackName;action 1;action x;action x;action x;action x;action x;land (example:Track1;takeoff;command;up 30;ccw 30;up 30;ccw 30;up 30;land .
> If you don't set the land cmd, the program will add the land cmd automatically. For the action setting part, please check the detail drone control protocol in Tello SDK Documentation EN_1.3_1122.pdf under doc folder )
As shown in the above example, after run the attestation, the PATT checksum record are different as shown below:
Local:12411222...CA100
Remote:600C8C9...C505
Which means the firmware running on the drone is different with the one in our control firmware repository DB (The attestation indicator will show red with word "Sen_att: unsafe"), the drone is using a unauthorized firmware, the firmware attack is detected. The drone operator can stop task to avoid the drone accident.
So the blue team can successful defend the firmware attack as shown below:
Thanks for reading, if you have any question and suggestion, please feel free to message me. Many thanks if you can give some comments and share any of the improvement advice so we can make our work better ~
If you are also interested about other OT attack case study on railway system, please refer to below links: