Hacksident: Cybersecurity in the Age of the Driverless Car

One of the most transformative undertakings associated with the ongoing development of the Internet of Things (IoT) is the evolution of partially- and fully-automated vehicles. Since 2013, there has been a proliferation of new car models equipped with advanced driver assistance mechanisms, including features such as adaptive cruise control, lane departure warning systems, automatic parallel parking, driver fatigue detection, and automatic emergency braking. Such features still require the driver’s full attention and readiness to take control of the vehicle at a moment’s notice. Uber is even working on a self-driving vehicle that was recently recorded going the wrong direction.

The National Highway Traffic Safety Administration classifies vehicles into autonomy into five levels:

Level 0:

No Automation

Driver has sole control over primary controls at all times, and is solely responsible for monitoring the roadway and for safe operation of all vehicle controls.

Level 1:

Function-Specific Automation

One or more specific control functions such as cruise control, automatic braking, and lane keeping that operate independently from one another.

Level 2:

Combined Function Automation

Two or more control functions designed to work in unison, such as adaptive cruise control combined with lane centering. Driver cedes primary control in certain limited situations

Level 3:

Limited Self-Driving Automation

Vehicle is cabable of driving itself in most situations. Driver must be available to take control if necessary, but is not expected to constantly monitor the road.

Level 4:

Full Automation

Vehicle is in full control of all functions. Driver doesn’t need to take control at any given time, simply providing destination or navigation input.

A future where driverless cars automatically communicate with the road and other vehicles should lead to substantial reductions in traffic congestion and road fatalities, but it could add an entirely new dimension to the cyber threat landscape. Imagine a world where hackers could restrict access your vehicle in a ransomware attack or tap into a built-in microphone and eavesdrop on your private conversations. Worse yet, imagine a world where hackers are capable of interfering with your car’s navigation and communication mechanisms, deliberately causing a crash.

Before we get too far ahead of ourselves, keep in mind the fact that it is still 2016. Vehicles with Level 2 automation such as the 2016 Tesla Model S are now available to the general public, and companies such as Google and Uber are currently piloting vehicles with Level 3 autonomy. Fully driverless cars are still a long way off. That being said, cars have already become increasingly software-driven with the introduction of features such as smartphone connectivity, real-time traffic alerts, and built-in web browsers. Modern automobiles contain 20-100 computer components known as electronic control units (ECUs). Each ECU is responsible for one or more features, ranging from seatbelt tightening to monitoring the steering wheel. Many ECUs communicate with each other, as well as other parts of the vehicle’s internal network, in order to coordinate activities. Some ECUs also communicate externally, making remote manipulation feasible.

In July 2015, automotive cybersecurity researchers Miller and Chris Valasek used a zero-day exploit to hack a Jeep Cherokee’s Uconnect system while it was traveling 70mph on an interstate highway. Not only were they able to manipulate the air conditioning, radio, windshield wipers, and digital display—they were able to cut the vehicle’s transmission, causing the vehicle to rapidly lose momentum on a busy highway. In another experiment, they were also able to disable the vehicle’s brakes. In response, Chrysler released a patch to address the zero-day vulnerability, notifying the owners of vehicles with the Uconnect feature in a post on the company website.

According to Miller and Valaesk’s report titled ‘A Survey of Remote Automotive Attack Surfaces,’ three factors determine a vehicle’s vulnerability to remote attacks:

  1. Remote Attack Surface: the presence of ECUs with remote functionality which could potentially be exploited as attack vectors
  2. Network Architecture: the extent to which a vehicle’s internal network isolates ECUs with remote functionality from ECUs that control safety critical features
  3. Cyber-Physical Features: the presence of computers that control physical actions

In order for a hacker to execute a remote attack, they must first compromise an ECU with remote functionality, typically responsible for functions such as Bluetooth, radio data systems, or cellular capabilities. That being said, a sizable attack surface is of little use to the hacker unless the vehicle’s network architecture makes it possible to inject messages into the vehicle’s internal network. Lastly, the presence of ECUs responsible for physical, safety critical features such as steering, braking, and acceleration is required to control the vehicle itself.

In September 2016, researchers at the Keen Security Lab announced that they found a way to hack a Tesla Model S, hitting its brakes from 12 miles away—the first successful remote attack on a CAN bus (controller area network). However, the vulnerability could only be exploited when the web browser was in use and required physical proximity and connectivity to a malicious charging station. In this case, the remote ECU is supporting the vehicle’s web browser served as the attack surface, the vehicle’s network architecture enabled the Keen Team to compromise the CAN bus, and the vehicle’s cyber-physical  features enabled them to control the brakes remotely. This technique can also be used at airport phone charging stations.

Before you start panicking, all known vehicle hacks to date have been carried out by white hat researchers on their own vehicles. It would be extremely difficult, if not impossible, for a cyber criminal to carry out similar attacks on a stranger’s vehicle. For the time being, remote vehicle attacks should be regarded as a hypothetical future threat. Active collaboration between white hat researchers and car manufacturers, full transparency with customers, and public awareness efforts could go a long way in preventing a future where vehicular cyber attacks are a legitimate safety concern.

When it comes to adopting new technologies—whether it be automated vehicles or cloud infrastructure—taking a proactive, research-driven approach to threat prevention is always a better option lagging behind out of fear of the unknown. 

To stay in the loop about the latest cybersecurity risks, subscribe to Alert Logic’s Weekly Threat Report.

About the Author

Stephen Coty - Chief Security Evangelist at Alert Logic

Stephen Coty

Stephen Coty originally joined Alert Logic as the head of the Threat Research team, where he led the effort to build threat content and deliver threat intelligence. He later became the Chief Security Evangelist for the company. Prior to joining Alert Logic, Coty was the Manager of Cyber Security for Rackspace Hosting, and has held IT positions at multiple companies, including Wells Fargo Bank, Applied Materials, Stanford Medical Center and The Netigy Corporation. He has been in the Information Technology field since 1993. Research has been his primary focus since 2007.

@StephenCoty | More Posts by Stephen Coty