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:

• arbitrarily modify firmware
• remotely install malicious firmware
• lock/unlock doors
• turn vehicle on/off
• track vehicle GPS coordinates as well as speed, heading, and altitude
• read the car's internal data (i.e., temperature, fuel levels, diagnostic trouble codes, etc.)
• inject arbitrary CAN packets

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:

• Separate CAN bus communication from the network stack. In some of the devices tested, CAN frames were passed directly from the vehicle through the device to the external network. Directly passing data to the external network is very dangerous and can allow an attacker to submit arbitrary CAN commands to ECUs on the bus. This functionality should be separated from the network stack and allow an application to send a request only from a list of prechosen OBD-II commands.
• Sign and encrypt firmware updates. Firmware updates should always be cryptographically signed and encrypted to prevent firmware modification by an attacker. OBD-II and telematics device vendors should consider using The Update Framework or another open, well-supported standard for doing software updates.
• Be secure by default. In the course of investigating these devices, there is a supply-chain relationship between device resellers (who are really selling the use of their web-based service) and the actual device OEM. In our conversations with several vendors, we found that they sell their products as blank, development devices with very weak or non-existent security. They expect the reseller to then choose a secure configuration for the device before selling the device to the customer. Unfortunately, it appears that some resellers are unaware that this configuration is necessary and simply ship these devices without a secure configuration. We recommend that the OEMs provide the device to the resellers already within the most secure configuration. The reseller can then modify the configuration as needed, without needing specialized expertise to modify the device configuration.
• Obey the principle of least privilege. A device should provide only enough connectivity to enable it to operate for its desired function. For example, if the device does not need access to manufacturer networks (e.g., General Motors LAN), then the physical connector itself should be removed. Additional features introduce additional risk.

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

• When to issue a patch for a car?
• Should a driver be forced to wait for updates every time they turn on the car? And will they be willing to wait if they are running late for work?
• What is the risk to performing updates while the car is in use?
• If updates fail, should the car stop working until it can be examined by a mechanic or software engineer?

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.

Additional Resources

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.