Incident: Security Vulnerabilities in Government-Ready Drone System Allow Hacking

Published Date: 2016-03-02

Postmortem Analysis
Timeline 1. The software failure incident with the security vulnerabilities in the government-ready drone happened during the time when security researcher Nils Rodday was conducting his research, which was mentioned to have been during his time as a graduate researcher at the University of Twente in the Netherlands [41734]. Therefore, the software failure incident with the drone security vulnerabilities likely occurred during Rodday's time as a graduate researcher at the University of Twente. The exact date is unknown.
System 1. Lack of encryption between the drone and its controller module (telemetry box) [1] 2. Weak "WEP" encryption used in the Wi-Fi connection between the telemetry module and a user's tablet [1] 3. Lack of encryption in the radio protocol used between the telemetry module and the drone itself, specifically the Xbee chips [1]
Responsible Organization 1. The security vulnerabilities in the government-ready drone were caused by flaws in the security of the drone's radio connection, allowing it to be hacked, taken over, or knocked out of the sky [1].
Impacted Organization 1. The government, including first responders, cops, and the military, as well as police and fire departments, were impacted by the security vulnerabilities in the government-ready drone highlighted by security researcher Nils Rodday [41734].
Software Causes 1. Lack of encryption in the Wi-Fi connection between the telemetry module and the user's tablet, making it vulnerable to a "deauth" command attack [1]. 2. Absence of encryption in the radio protocol between the telemetry module and the drone itself, leaving it open to a man-in-the-middle attack [1].
Non-software Causes 1. Lack of encryption in the Wi-Fi connection between the telemetry module and the user's tablet, making it vulnerable to a "deauth" command attack [1]. 2. Lack of encryption in the radio protocol between the telemetry module and the drone itself, leaving it open to a man-in-the-middle attack [1].
Impacts 1. The security vulnerabilities in the drone's radio connection allowed a hacker to take full control over the quadcopter from more than a mile away, impersonate the legitimate controller, alter navigation commands, and block commands from the drone's operator [41734]. 2. The weak encryption protocols used in the drone's telemetry module and Wi-Fi connection allowed for easy interception and manipulation of commands, potentially leading to unauthorized control, data theft, or disruption of surveillance operations [41734]. 3. The lack of encryption implementation in the drone's Xbee chips left it vulnerable to man-in-the-middle attacks, where an attacker could reroute packets, establish communication with the drone, and intercept or drop commands from the operator, leading to potential crashes or theft of the drone [41734]. 4. The inability to easily update the firmware of the drones already in customers' hands to address the security flaws highlighted a significant challenge in securing existing UAVs, as they were not connected to the internet for remote updates [41734]. 5. The need for a hardware fix, such as adding a dedicated security chip, to enable encryption without compromising the drone's responsiveness to commands posed a significant obstacle to addressing the security vulnerabilities in the existing drones [41734].
Preventions 1. Implementing strong encryption protocols for communication between the drone and its controller module, such as using advanced encryption standards (AES) instead of weak protocols like WEP [41734]. 2. Regularly updating the firmware of the drone to patch security vulnerabilities and enhance encryption capabilities [41734]. 3. Conducting thorough security assessments and penetration testing during the development phase to identify and address potential vulnerabilities before the product is released to customers [41734].
Fixes 1. Implementing strong encryption protocols for the communication between the drone's telemetry module and the user's tablet to prevent unauthorized access [41734]. 2. Adding dedicated security chips to enable encryption without compromising the drone's responsiveness to commands [41734]. 3. Recalling the affected drones and issuing a hardware fix to address the security vulnerabilities [41734].
References 1. Security researcher Nils Rodday at the RSA security conference in San Francisco [1] 2. University of Twente in the Netherlands where Rodday conducted his research [1] 3. IBM where Rodday currently works [1] 4. Hacker Samy Kamkar who demonstrated vulnerabilities in Parrot AR quadcopters [1]

Software Taxonomy of Faults

Category Option Rationale
Recurring one_organization, multiple_organization (a) The software failure incident related to security vulnerabilities in drones has happened again within the same organization or with its products and services. The article mentions that security researcher Nils Rodday found serious security oversights in a specific model of a government-ready drone, highlighting vulnerabilities that may apply to a broad swathe of high-end drones [41734]. (b) The software failure incident related to security vulnerabilities in drones may have also occurred at multiple organizations or with their products and services. The article mentions that Rodday contacted other drone sellers that use the Xbee radio protocol to ask for information about how they secure their UAVs' communications, but he didn't get a response. This suggests that the vulnerability he found in the specific drone he tested could potentially exist in other setups as well [41734].
Phase (Design/Operation) design, operation (a) The software failure incident related to the design phase is evident in the security vulnerabilities found in a government-ready drone by security researcher Nils Rodday. The vulnerabilities allowed for the drone to be hacked from more than a mile away, taken over by a rogue operator, or knocked out of the sky with a keystroke due to flaws in the security of the drone's radio connection [41734]. (b) The software failure incident related to the operation phase is highlighted by the fact that the specific drone tested by Rodday had weak encryption protocols in its Wi-Fi connection and telemetry module, making it susceptible to attacks during operation. The lack of encryption between the drone and its controller module allowed any attacker in Wi-Fi range to break into the connection and send commands to the drone, potentially causing it to become unresponsive, crash, or be stolen [41734].
Boundary (Internal/External) within_system (a) within_system: The software failure incident described in the article is primarily due to security vulnerabilities within the system of the drone. The security researcher, Nils Rodday, discovered serious security oversights in the drone's communication protocols, specifically the weak encryption used in the Wi-Fi connection between the telemetry module and the user's tablet, as well as the lack of encryption in the radio protocol between the telemetry module and the drone itself. These vulnerabilities allowed for a man-in-the-middle attack, enabling a rogue operator to take full control over the quadcopter, alter navigation commands, and potentially cause harm or steal the drone [Article 41734]. (b) outside_system: The software failure incident was not caused by factors originating from outside the system. The vulnerabilities exploited by the security researcher were inherent to the design and implementation of the drone's communication systems, rather than being influenced by external factors beyond the control of the system itself.
Nature (Human/Non-human) non-human_actions, human_actions (a) The software failure incident in the article is primarily due to non-human actions. The security vulnerabilities in the drone's radio connection allowed a security researcher to take full control over the quadcopter with just a laptop and a cheap radio chip connected via USB. The flaws in the security of the drone's radio connection, lack of encryption, and weak encryption protocols contributed to the vulnerability that could be exploited by a hacker from more than a mile away [41734]. (b) However, human actions are also involved in this software failure incident. The security researcher, Nils Rodday, conducted research to identify and exploit the security vulnerabilities in the drone's communication systems. Additionally, the manufacturer of the drone was made aware of these security flaws and plans to fix them in the next version of the quadcopter they sell. The decision-making process of not implementing encryption to avoid latency in the drone's responsiveness to commands was also a human action that contributed to the vulnerability [41734].
Dimension (Hardware/Software) hardware, software (a) The software failure incident in the article is related to hardware vulnerabilities in a government-ready drone. The security researcher, Nils Rodday, discovered serious security vulnerabilities in the drone's radio connection, which could allow it to be hacked, taken over by a rogue operator, or knocked out of the sky from more than a mile away. The vulnerabilities stem from weaknesses in the drone's telemetry module and its communication with the controller, as well as the lack of encryption in the radio protocol used between the module and the drone itself [41734]. (b) The software failure incident is also related to software vulnerabilities in the drone. The drone's software flaws allowed for the exploitation of a lack of encryption between the drone and its controller module, enabling a hacker to impersonate the controller, alter waypoints, change data on the flight computer, and take full control over the quadcopter. Additionally, the Wi-Fi connection between the telemetry module and a user's tablet used weak encryption, making it susceptible to attacks. The software vulnerabilities highlighted by Rodday's research could potentially apply to a broad range of high-end drones, indicating a systemic issue in the software security of such devices [41734].
Objective (Malicious/Non-malicious) malicious (a) The software failure incident described in the article is malicious in nature. The security researcher, Nils Rodday, demonstrated how serious security vulnerabilities in a government-ready drone could allow it to be hacked from more than a mile away, taken over by a rogue operator, or knocked out of the sky with a keystroke. Rodday was able to exploit flaws in the drone's security, such as weak encryption protocols and lack of encryption between the drone and its controller module, to take full control over the quadcopter with just a laptop and a cheap radio chip connected via USB. He highlighted the potential for malicious actions like altering waypoints, changing data on the flight computer, setting a different coming home position, making the drone unresponsive, crashing it into a building, or stealing it [41734].
Intent (Poor/Accidental Decisions) accidental_decisions (a) The intent of the software failure incident was not due to poor decisions but rather due to security vulnerabilities in the design and implementation of the drone's software and communication protocols. The security researcher, Nils Rodday, identified serious security oversights in the drone's communication systems, such as weak encryption protocols and lack of encryption between the drone and its controller module, which allowed for potential hacking and takeover of the drone [41734]. The incident was more related to flaws in the security design rather than poor decisions made during the development process.
Capability (Incompetence/Accidental) development_incompetence (a) The software failure incident in the article is related to development incompetence. The security vulnerabilities in the $30,000 to $35,000 drone were due to flaws in the security of the drone's radio connection, allowing a security researcher to take full control over the quadcopter with just a laptop and a cheap radio chip connected via USB. The lack of encryption between the drone and its controller module, known as a "telemetry box," allowed any hacker who's able to reverse engineer the drone's flight software to impersonate the controller and send navigation commands, blocking all commands from the drone’s legitimate operator [41734]. (b) The software failure incident was not accidental but rather a result of intentional actions by a security researcher to identify and exploit the security vulnerabilities in the drone's radio connection.
Duration permanent (a) The software failure incident described in the article is more of a permanent nature. The security vulnerabilities identified in the drone's software, specifically in its radio connection, are inherent to the design and implementation of the system. These vulnerabilities could allow a hacker to take full control over the quadcopter, impersonate the legitimate controller, alter flight data, reroute packets, intercept commands, and potentially cause harm or steal the drone [Article 41734]. (b) The software failure incident is not temporary as the vulnerabilities identified are fundamental flaws in the system's security design, making it susceptible to exploitation by malicious actors. The issues cannot be easily patched through a simple software update and would require significant hardware changes to address effectively [Article 41734].
Behaviour crash, omission, value, other (a) crash: The software failure incident described in the article involves the potential for a drone to be crashed into a building or made unresponsive by a malicious attacker taking control of the quadcopter [41734]. (b) omission: The security vulnerabilities in the drone's software allow an attacker to omit the intended functions of the drone by taking full control over it, altering waypoints, changing data on the flight computer, and setting a different coming home position [41734]. (c) timing: The software failure incident does not directly relate to timing issues where the system performs its intended functions but at the wrong time. (d) value: The security flaws in the drone's software lead to the system performing its intended functions incorrectly, as an attacker could send commands to reroute packets on the network, intercept or drop commands from the drone's operator, and potentially steal the drone [41734]. (e) byzantine: The software failure incident does not exhibit byzantine behavior where the system behaves erroneously with inconsistent responses and interactions. (f) other: The other behavior observed in the software failure incident is the potential for a man-in-the-middle attack where an intruder could join the network and establish communications between the drone and themselves, intercepting or dropping commands from the legitimate operator [41734].

IoT System Layer

Layer Option Rationale
Perception sensor, network_communication, embedded_software (a) sensor: The software failure incident discussed in the article is related to vulnerabilities in the security of a drone's radio connection, specifically the telemetry module and the drone itself. The lack of encryption and weak encryption protocols used in the Wi-Fi connection between the telemetry module and the user's tablet, as well as the radio protocol between the telemetry module and the drone, allowed for potential attacks such as taking full control over the quadcopter, injecting commands, altering waypoints, and rerouting packets on the network [41734]. (b) actuator: The incident does not directly mention any failure related to the actuator of the drone. (c) processing_unit: The software failure incident does not specifically mention any failure related to the processing unit of the drone. (d) network_communication: The software failure incident is primarily related to vulnerabilities in the network communication of the drone, specifically the radio connection between the telemetry module and the drone itself. The lack of encryption and the use of weak encryption protocols in this communication channel allowed for potential attacks and takeovers of the drone [41734]. (e) embedded_software: The software failure incident is related to vulnerabilities in the embedded software of the drone, particularly in how the drone's flight software interacts with the telemetry module and the lack of encryption implemented in the communication between the drone and the controller. These vulnerabilities allowed for unauthorized access, injection of commands, and interception of legitimate commands [41734].
Communication link_level The software failure incident described in the article is related to the communication layer of the cyber-physical system that failed at the link_level. The security vulnerabilities identified by the security researcher Nils Rodday were primarily due to weaknesses in the communication between the drone and its controller module, known as a "telemetry box." Specifically, the vulnerabilities stemmed from the lack of encryption in the drone's radio connection, allowing for unauthorized access and control over the quadcopter [41734].
Application TRUE The software failure incident described in the article [41734] is related to the application layer of the cyber physical system. The failure was due to serious security vulnerabilities in the drone's radio connection, allowing a security researcher to take full control over the quadcopter with just a laptop and a cheap radio chip connected via USB. The vulnerabilities included weak encryption protocols (WEP) between the telemetry module and the user's tablet, as well as an unsecured radio protocol between the telemetry module and the drone itself. These vulnerabilities allowed for a man-in-the-middle attack, enabling an attacker to intercept or drop commands from the drone's operator and take over the drone remotely. The flaws highlighted in the research point to issues at the application layer of the drone's software system, leading to potential unauthorized access and control of the drone [41734].

Other Details

Category Option Rationale
Consequence harm, property, delay, non-human, theoretical_consequence (a) unknown (b) harm: The software failure incident could potentially lead to physical harm as a malicious attacker could take control of the drone and cause it to crash into a building or fly it away, posing a risk to people's safety [41734]. (c) unknown (d) property: The software failure incident could result in the theft of the drone, all the equipment attached to it, and its information, as an attacker could take control of the drone and steal it [41734]. (e) delay: The software failure incident could cause a delay in daily surveillance procedures as an attacker could interfere with the drone's camera or control, preventing the desired information from being received [41734]. (f) non-human: The software failure incident impacts the drone itself, as it could be controlled by a malicious attacker, leading to potential crashes or theft [41734]. (g) unknown (h) theoretical_consequence: The potential consequences discussed include the drone being taken over by a rogue operator, knocked out of the sky, or controlled to cause harm or disruption to surveillance procedures [41734]. (i) unknown
Domain information, manufacturing (a) The software failure incident discussed in the article is related to the industry of information, specifically in the context of security vulnerabilities in high-end drones used for various applications such as inspecting power lines, windmills, aerial photography, and potentially by police and fire departments [Article 41734]. (m) Additionally, the incident is also relevant to the industry of manufacturing as it involves the security flaws in the communication systems of a high-end drone, which is a product created from materials and used for industrial applications [Article 41734].

Sources

Back to List