Incident: Remotely Hackable Car Tracking Device Raises Safety Concerns

Published Date: 2015-08-13

Postmortem Analysis
Timeline 1. The software failure incident happened in August 2015. [38919]
System 1. Mobile Devices tracking device used by auto insurer Metromile [38919]
Responsible Organization 1. Student engineers from the University of California, San Diego [38919] 2. Mobile Devices, the device maker [38919]
Impacted Organization 1. Customers using the tracking devices from insurance companies, such as Metromile and ride-sharing service Uber, were impacted by the software failure incident [38919].
Software Causes 1. The software cause of the failure incident was a vulnerability in the tracking device's software that allowed hackers to remotely engage a car's brakes or disable them completely by sending specially-coded text messages [38919].
Non-software Causes 1. Lack of proper security measures in the design of the plug-in tracking devices [38919] 2. Vulnerabilities in the computer networks of cars [38919] 3. Insufficient consideration of the potential risks associated with Internet-connected devices in vehicles [38919]
Impacts 1. The software failure incident allowed hackers to remotely engage a car's brakes or disable them completely by sending specially-coded text messages to a tracking device plugged into the car's computer port [38919]. 2. The vulnerability exposed in the tracking device raised serious concerns about the safety and security of using such devices in cars, highlighting the potential dangers of cyber attacks on vehicles [38919]. 3. The incident prompted the device maker to issue a software update to address the security flaw, and the auto insurer Metromile stated that most of the affected devices, including those used by ride-sharing service Uber, have been fixed with all devices scheduled to be updated by mid-August [38919]. 4. The research findings emphasized the need for better design and security measures in Internet-connected devices used in vehicles, as they can pose significant risks if not properly secured against hacking attacks [38919]. 5. The incident underscored the broader issue of car hacking as a real threat, with modern cars being vulnerable to cyber attacks due to their computerized systems, similar to the previous case where security researchers demonstrated how Chryslers could be hacked over the Internet, leading to a recall of 1.4 million cars [38919].
Preventions 1. Implementing secure coding practices during the development of the tracking device software to prevent vulnerabilities that could be exploited by hackers [38919]. 2. Regular security audits and penetration testing of the tracking device software to identify and address any potential weaknesses or flaws [38919]. 3. Ensuring timely software updates and patches to address any discovered vulnerabilities, as seen in the case where the device maker issued a software update after the hack was demonstrated [38919]. 4. Enforcing stricter regulations and standards for the cybersecurity of Internet-connected devices, such as the bill introduced by U.S. Senators Markey and Blumenthal requiring measures to protect against hacking attacks [38919].
Fixes 1. Issuing a software update: The device maker has issued a software update to fix the vulnerability that allowed hackers to remotely engage a car's brakes or disable them [38919]. 2. Fixing the devices used by customers: Metromile has fixed most of the devices used by customers, including those used by ride-sharing service Uber, and plans to update all of them by mid-August [38919]. 3. Implementing security measures: U.S. Senators Edward J. Markey and Richard Blumenthal have introduced a bill that would require all entry points for cars sold in the country to be equipped with reasonable measures to protect against hacking attacks [38919].
References 1. Student engineers from the University of California, San Diego [38919] 2. Auto insurer Metromile [38919] 3. Stefan Savage, the college engineering professor overseeing the research project [38919] 4. U.S. Senators Edward J. Markey and Richard Blumenthal [38919] 5. Charlie Miller, one of the Chrysler hacking researchers [38919]

Software Taxonomy of Faults

Category Option Rationale
Recurring one_organization, multiple_organization (a) The software failure incident related to remotely hacking a car through a plug-in tracking device from insurance companies happened again at the same organization, Metromile. Student engineers from the University of California, San Diego examined a device from Mobile Devices used by auto insurer Metromile and discovered they could remotely engage a car's brakes or disable them completely by sending specially-coded text messages [38919]. (b) The incident of car hacking through plug-in tracking devices is not unique to a single organization. The article mentions that similar vulnerabilities have been demonstrated in the past with Chrysler vehicles, where security researchers showed how Chryslers could be hacked over the Internet, leading to a recall of 1.4 million cars [38919]. This indicates that the issue of car hacking through software vulnerabilities is not limited to a specific organization but is a broader concern across the automotive industry.
Phase (Design/Operation) design, operation (a) The software failure incident related to the design phase can be seen in the article where researchers discovered a vulnerability in a plug-in tracking device used by auto insurer Metromile. They found that by sending specially-coded text messages, they could remotely engage a car's brakes or disable them completely. This vulnerability was due to flaws in the design of the device, allowing unauthorized access to a car's internal controls [38919]. (b) The software failure incident related to the operation phase is evident in the same article where it was mentioned that the vulnerability in the tracking device could be exploited if the car was at a slow crawl of 5 miles per hour or less. This indicates that the failure could occur during the operation of the vehicle, potentially leading to dangerous situations if the brakes were remotely engaged or disabled [38919].
Boundary (Internal/External) within_system, outside_system (a) within_system: The software failure incident described in the article is primarily within the system. The vulnerability was related to a plug-in tracking device used by insurance companies that connects to a car's internal controls through the OBD-II port. The researchers were able to remotely engage a car's brakes or disable them completely by sending specially-coded text messages to the device. The flaw was within the design and implementation of the tracking device itself, allowing unauthorized access to critical car functions [38919]. (b) outside_system: The software failure incident also involved factors originating from outside the system. The vulnerability exploited by the researchers was related to the use of cellular networks to communicate with the tracking device. By sending text messages to the device, the hackers were able to manipulate the car's brakes remotely. This external communication channel provided a gateway for attackers to exploit the system, highlighting the risks associated with external connectivity and communication protocols [38919].
Nature (Human/Non-human) non-human_actions, human_actions (a) The software failure incident in the article was primarily due to non-human actions. The incident involved a vulnerability in a plug-in tracking device used by insurance companies, which allowed hackers to remotely engage a car's brakes or disable them by sending specially-coded text messages to the device [38919]. (b) However, human actions were also involved in addressing the software failure incident. The researchers who discovered the vulnerability presented their findings at a computer conference, and the device maker issued a software update in response to the identified flaw. Additionally, U.S. Senators introduced a bill to require measures to protect against hacking attacks in cars [38919].
Dimension (Hardware/Software) hardware, software (a) The software failure incident in the article is related to hardware. The incident involved remotely hacking a car by tapping into a plug-in tracking device from an insurance company. The researchers were able to send specially-coded text messages to the device, which allowed them to remotely engage a car's brakes or disable them completely. This indicates that the failure originated from the hardware aspect of the tracking device [38919]. (b) The software failure incident in the article is also related to software. The researchers discovered that they could exploit vulnerabilities in the software of the tracking device to remotely control the car's brakes. The device received text messages, and through software manipulation, the researchers were able to take control of the car's internal controls. The device maker issued a software update to address the identified flaws, highlighting the software aspect of the failure [38919].
Objective (Malicious/Non-malicious) malicious (a) The software failure incident described in the articles is malicious in nature. Hackers were able to remotely hack into cars by exploiting vulnerabilities in the plug-in tracking devices from insurance companies. They could send specially-coded text messages to engage or disable a car's brakes, demonstrating the potential for serious harm [38919]. The incident highlights the dangers of malicious attacks on connected devices and the need for robust security measures to protect against such threats.
Intent (Poor/Accidental Decisions) poor_decisions (a) The software failure incident described in the article was primarily due to poor decisions made in the design and implementation of the plug-in tracking devices used by insurance companies. The devices were found to have serious vulnerabilities that allowed hackers to remotely engage a car's brakes or disable them completely by sending specially-coded text messages [38919]. These vulnerabilities were a result of inadequate security measures and oversight in the development of the devices, highlighting the poor decisions made by the manufacturers in ensuring the safety and integrity of the technology.
Capability (Incompetence/Accidental) development_incompetence, accidental (a) The software failure incident related to development incompetence is evident in the article as the researchers from the University of California, San Diego discovered a vulnerability in the plug-in tracking device from Mobile Devices used by auto insurer Metromile. They were able to remotely engage a car's brakes or disable them completely by sending specially-coded text messages to the device. This vulnerability highlights a lack of professional competence in the development of the device, as it allowed for potentially dangerous manipulation of a car's internal controls [38919]. (b) The software failure incident related to accidental factors is demonstrated by the unintentional vulnerability discovered in the plug-in tracking device. The researchers did not have to look very hard for flaws in the device, indicating that the vulnerability was not intentionally introduced but rather accidentally present in the design. This accidental flaw allowed for the potential remote manipulation of a car's brakes, highlighting the unintended consequences of the device's design [38919].
Duration temporary The software failure incident described in the article is more aligned with a temporary failure rather than a permanent one. This incident was temporary because the failure was due to specific circumstances introduced by the vulnerability in the plug-in tracking device used by insurance companies to monitor driving behavior. The vulnerability allowed hackers to remotely engage a car's brakes or disable them, but the issue was addressed through a software update issued by the device maker [38919].
Behaviour crash, omission, value, other (a) crash: The software failure incident described in the article can be categorized as a crash. The researchers were able to remotely engage a car's brakes or disable them completely by sending specially-coded text messages to the tracking device plugged into the car's computer port. This action led to a failure in the system's intended function of controlling the car's brakes, resulting in a potential crash risk [38919]. (b) omission: The incident also involves an omission failure. The tracking device, when manipulated by the researchers, omitted to perform its intended function of accurately tracking the car's movements and instead allowed unauthorized control over critical functions like braking [38919]. (c) timing: There is no specific mention of a timing-related failure in the article. (d) value: The software failure incident can be linked to a value failure. The device, upon receiving the specially-coded text messages, performed its intended functions incorrectly by engaging or disabling the car's brakes inappropriately, compromising the safety and integrity of the system [38919]. (e) byzantine: The incident does not exhibit characteristics of a byzantine failure. (f) other: The other behavior observed in this software failure incident is the potential compromise of the system's security and safety due to unauthorized access and control over critical functions of the car, highlighting a security vulnerability in the software system [38919].

IoT System Layer

Layer Option Rationale
Perception sensor (a) The failure was related to the perception layer of the cyber physical system that failed due to contributing factors introduced by sensor error. The article mentions that student engineers from the University of California, San Diego examined a tracking device from Mobile Devices used by auto insurer Metromile and discovered they could send specially-coded text messages to remotely engage a car's brakes or disable them completely [38919]. This indicates that the failure was related to the sensor (tracking device) which received the text messages and caused the car's brakes to be manipulated.
Communication connectivity_level The software failure incident described in the article is related to the communication layer of the cyber-physical system that failed at the connectivity level. The incident involved a vulnerability in a plug-in tracking device used by insurance companies that connected to the cellular network and allowed hackers to remotely engage a car's brakes or disable them by sending specially-coded text messages [38919]. This vulnerability was exploited at the network layer, specifically through the device's connectivity to the cellular network, which enabled the hackers to manipulate the car's internal controls remotely.
Application TRUE The software failure incident described in the article [38919] was related to the application layer of the cyber physical system. The failure was caused by a vulnerability in a plug-in tracking device used by insurance companies, which allowed hackers to remotely engage a car's brakes or disable them by sending specially-coded text messages. This vulnerability stemmed from flaws in the device's software, making it susceptible to hacking attacks introduced by bugs and incorrect usage [38919].

Other Details

Category Option Rationale
Consequence property, non-human, theoretical_consequence (a) death: The articles do not mention any deaths resulting from the software failure incident. [38919] (b) harm: The articles do not mention any physical harm to individuals resulting from the software failure incident. [38919] (c) basic: The articles do not mention any impact on people's access to food or shelter due to the software failure incident. [38919] (d) property: The software failure incident impacted people's material goods, specifically their cars. The researchers were able to remotely engage a car's brakes or disable them completely through the hack. [38919] (e) delay: The articles do not mention any activities being postponed due to the software failure incident. [38919] (f) non-human: The software failure incident impacted non-human entities, specifically cars. The vulnerability allowed for remote control of a car's brakes or complete disablement. [38919] (g) no_consequence: The articles do not mention any observed consequences of the software failure incident. [38919] (h) theoretical_consequence: There were discussions about potential consequences of the software failure incident, such as the vulnerability of cars to hacking attacks and the need for measures to protect against such attacks. However, there were no real-life instances of these attacks reported. [38919] (i) other: The articles do not mention any other specific consequences of the software failure incident. [38919]
Domain transportation (a) The failed system was related to the transportation industry. The incident involved a vulnerability in plug-in tracking devices used by insurance companies to monitor and track cars, allowing hackers to remotely engage a car's brakes or disable them [38919].

Sources

Back to List