Posted on by Vulnerability Analysisin
By Christopher King
This blog post was co-authored by Dan Klinedinst.
Automobiles are often referred to as "computers on wheels" with newer models containing more than 100 million lines of code. All this code provides features such as forward collision warning systems and automatic emergency braking to keep drivers safe. This code offers other benefits such as traffic detection, smartphone integration, and enhanced navigation. These features also introduce an increased risk of compromise, as demonstrated by researchers Chris Valasek and Charlie Miller (who work for Uber's Advanced Technology Center in Pittsburgh) in a July 2015 story for Wired, where they hacked into a Jeep Cherokee with a zero-day exploit. The Jeep Hack, as it has come to be known, highlighted an underlying issue for all vehicles: when automobiles are built, manufacturers focus on a threat model of potential risks that rely on physical defects, but do not include vulnerabilities that make a vehicle susceptible to intrusion and remote compromise. This blog post highlights the first phase of our research on making connected vehicles more secure by testing devices that connect into the vehicle itself.
Threat Model: The Potential for Harm
As outlined in our recent technical report, On Board Diagnostics: Risks and Vulnerabilities of the Connected Vehicle, the millions of lines of code in vehicles operate dozens of electronic control units (ECUs), such as the brakes, wipers and steering, that control automotive systems. Today's vehicles come with hundreds of sensors and ECUs that control everything from vehicle operations (steering, braking, and accelerating) to peripheral functions such as door locks or infotainment systems. These ECUs interact in simple networks called controller area networks (CANs) that allow them to communicate at high speeds.
The on-board diagnostics (OBD-II) port, which has been mandated in vehicles since 1996, is usually located in the foot well of the driver's side of a car. In modern vehicles the Controller Area Network (CAN) bus is connected to the OBD-II port and can often receive and relay all traffic to the external side of the interface. This port initially enabled car manufacturers to test for emissions and conduct inspections.
As we enter the age of the Internet of Things (IoT), these ports have become increasingly popular for use by insurance companies, fleet managers, and consumers. For example, insurance companies have recently used this technology to implement pay-per-mile insurance. Under such a system Uber drivers, for example, would only pay insurance on the number of miles driven for the service. Insurance companies and fleet managers have also used this technology to access the vehicle's internal data, which can tell them how fast a vehicle is being driven, its location, and other information.
The CAN bus protocol suffers from several security issues that are not addressed in most modern vehicles. Most of the networks and ECUs were designed when access to the bus required physical access to the vehicle and therefore security was not a primary concern. Also, speed and timing are often deemed more important to the safety and performance of a vehicle than data security. An automobile shouldn't wait a millisecond to verify the sender of a byte of data before deploying an airbag.
As detailed in our technical report, a vehicle with security vulnerabilities introduces potential safety concerns because an intelligent adversary could use those vulnerabilities to potentially control vehicle functions.
We recently obtained a vehicle, a 2013 Chevy Volt that was loaned to us from Transport Canada and the U.S. Department of Transportation's VOLPE Center, which became our test platform for our research. While we ultimately plan to research vehicular telematics, we first wanted to focus on after-market, onboard diagnostic devices.
First Phase: Onboard Diagnostic Devices
Our initial phase of research focused on the security of aftermarket devices that connect to a vehicle via its OBD-II port, which provides access to the internal CAN bus. Several of these devices have already been shown to be susceptible to intrusion, such as the Zubie, Progressive Snapshot, and Metromile. We investigated the security of a representative sample of these devices, both to warn consumers of problems and to inform government fleet management personnel who are acquiring them.
Unfortunately, the bar for security in these types of devices is low. We examined eight devices and reviewed the documentation of quite a few others and found common architectural and implementation problems. Many of these devices simply pass raw serial data from a radio interface (Bluetooth, WiFi, or cellular) to the OBD-II port of the car, and from there to the vehicle's CAN bus.
If this data is not sanitized, an attacker who controls the device could send arbitrary commands to the car's brakes, steering system, accelerator and other important safety components, as was demonstrated by Valasek and Miller with the Jeep Hack.
A secondary risk of using these devices is that compromise of the manufacturer's or operator's back-end server may allow an attacker access to any device connecting to its network, such as USB, Bluetooth, or a smart phone. When consumers plug these devices into their cars, they are unintentionally moving the security boundary from the vehicle itself to the device manufacturer's network, associated services, and any other connected device.
Our analysis of each devise generally involved reverse-engineering the main functionalities of the device, identifying the connections that it had both into the vehicle and to the Internet. We also examined software and hardware such as the physical wires, connections, radios, etc.
In addition to extracting the firmware and analyzing it, we also conducted man-in-the-middle attacks. This essentially involved connecting to the device and using CERT's TAPIOCA tool to examine and change network traffic and encryption parameters.
Through our research, we successfully conducted the following attacks:
What We Learned and Recommendations
While our recently published report highlights detailed testing methodologies and results (See Appendix C in that report), the important takeaway for government and industry is that aftermarket OBD-II devices have the potential to introduce serious safety and security risks to an automobile. The current design of the OBD-II port--architectural issues include the external network interface, undocumented features, and insecure firmware updates--gives it unlimited access to some or all of a car's internal networks. An external interface also allows access from outside the car via WiFi, Bluetooth, or cellular.
As a result of our testing and analysis, we recommend the following:
One thing that we would like to stress that often gets overlooked when people talk about cybersecurity of cars is that even if an attacker gains access to the vehicle, the variety of code on each make and model complicates any attack. For example, with traditional IT, when a vulnerability is discovered in Windows, that vulnerability can affect every system with that version of windows. With vehicles, however, every manufacturer, model, and even year may be programmed differently. This programming is often proprietary, so it raises the bar for an adversary attempting to create a widespread attack. However, we expect to see exploit kits being developed for various makes and models in the near future.
Looking Ahead: Future Research inNetworked Telematics
As we wrap up this first phase on small-scale device testing, our new phase will examine the in-dash telematics of the vehicle that are provided by the manufacturer. Networked telematics encompasses all functions of the vehicle electronics that are designed to be accessible to users, including the dashboard, controls, and navigation system. Many vehicle manufacturers have recently added cellular connectivity to their vehicle to provide richer, more interactive services to the consumer. Developers of smartphone operating systems have also begun to integrate their products more closely with telematics systems. The introduction of Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communication on new vehicles will also introduce new risks.
The upcoming mass deployment of this domain will increase the risk of new vulnerabilities, especially those of a systemic nature. The emerging smartphone-telematics integration technologies (e.g., Apple CarPlay, Google's Open Automotive Alliance, Blackberry QNX) are of particular concern. An Internet-connected vehicle is vulnerable to a wide range of attacks, both from determined attackers and traditional threats such as malicious code and phishing.
As vehicles become increasingly networked, there will be many issues that need to be resolved. Awareness is an important first step. We are also working with the National Highway Traffic Safety Administration on coordinated vulnerability disclosure in this domain.
While we have extensive experience in coordinated disclosure of cyber vulnerabilities, the cyber-physical domains of a vehicle present an entirely new domain of concerns. While it is necessary to issue a recall on a defective airbag, would a component in a vehicle that is vulnerable to cyberattack necessitate the same response (More on this topic in a related blog post: When is Vulnerability a Safety Issue?)? In cybersecurity, there is an intelligent adversary who at some point may figure out how to compromise a vehicle, but you don't know when or who the adversary might be.
There are other issues such as
We will detail our findings and comments on these issues in future blog posts.
We welcome your feedback on our research in the comments section below.
View a webinar in which Dan Klinedinst and others from CERT discuss lessons learned from the Jeep Hack.
Read our white paper on this research, On Board Diagnostics: Risks and Vulnerabilities of the Connected Vehicle.