Why Is Hacking Vehicles Over the Internet So Easy?
Internal vehicle communication protocols were never built for connecting to the Internet. Recent trends to connect everything before securing makes matters worse. Finally, the icing on the cake is the lack of clearly defined liability i.e who is responsible when vehicles are hacked — and you end up with multiple nightmare scenarios.
So why are manufacturers continuing to make bad decisions when it comes to vehicle security? It’s because there’s no single magic solution. To understand why, let’s go to the beginning of vehicle communication systems.
In the 1970s, there was a rapid development of vehicle electronic control units (ECU); where each ECU controls electrical systems in a vehicle. This was largely spurred by higher efficiency requirements from the California Clean Air act and ECUs made it possible to continuously monitor and control vehicle parameters, such as fuel to oxygen ratios.
The CAN protocol was developed in 1986 to communicate between ECUs in an efficient and flexible manner, with minimal physical wiring. These ECU connections are an essential part of modern vehicles such as changing fuel-oxygen mixtures based on speed or steering wheel indicators in case of lane departure, etc. However, the CAN protocol was built for speed and efficiency — as is necessary when operating fast vehicles on the road. But they were not built for security.
In 1986, for someone to access your vehicle’s internal communication systems, they had to be in your vehicle. Fast forward to 1996. Companies like OnStar started developing ways to connect vehicles to wireless telecommunication, which is now known as vehicle telematics. Benefits include wireless communication, entertainment systems, GPS navigation, etc.
However, the benefits of increased wireless connectivity have come with a cost. Since vehicle internal communication systems are insecure, hacking of the internet connection to vehicles puts at risk critical vehicle components such as navigation. And a vehicle that is navigating incorrectly is a weapon. How bad are vehicle internal systems?
In 2015, Miller and Valasek famously showed that they could gain complete remote access of a Jeep Grand Cherokee through vulnerabilities in the UConnect entertainment system. The key first step it turns out, the UConnect system was connected to Sprint, and any Sprint device can connect to another one. Once they hacked the Sprint connection, they were able to send messages, and ultimately these messages were relayed to the vehicle ECUs through the CAN bus. But here’s where it gets worse:
The CAN bus does not know where messages are coming from, and treats all messages as legit. Thus hacking the 4G connection to your vehicle entertainment system leaves your vehicle in the hands of hackers imagination.
Along with a reporter from Wired, in a demonstration, they showed they could blast music, swerve the car, and completely stop it, while the poor driver (Wired reporter Andy Greenberg) had no control!
You might think that the solution should be straightforward — make internal vehicle communication protocols more secure. Renovate the CAN protocol. However one of the major advantages of CAN is efficiency. Messages are relayed rapidly between ECUs. Any authentication protocol would mean more latency, and delays would be bad. Think about the consequences of an airbag deploying one second later. Not ideal.
But that’s not the only problem. Imagine we had perfect authentication and could detect any fake message coming in. This still does not solve problems involving badly authenticated 3rd party apps connecting to your vehicle’s critical functions.
In 2016, Troy Hunt showed that the Nissan Leaf app used to remotely access a Leaf’s air conditioning system could be remotely hacked. All this ‘hack’ required was knowing the VIN number of a Leaf vehicle, and anonymously accessing the API. What that means is — no password required. Anyone who knows how to write a URL could do this.
GET https://[redacted].com/orchestration_1111/gdc/BatteryStatusRecordsRequest.php?RegionCode=NE&lg=no-NO&DCMID=&VIN=SJNFAAZE0U60XXXXX&tz=Europe/Paris&TimeFrom=2014-09-27T09:15:21This was the code used to access the API anonymously (last 5 digits of VPN removed). From that, they could essentially run the vehicle’s battery out, and even get location information from the API. There have been numerous such incidents, including one where more than 25,000 vehicles that ran GPS tracking apps were found vulnerable to hackers randomly stalling vehicles on the road.
In the case of bad apps, you don’t even need to be a hacker to remotely compromise a vehicle and cause serious harm.
Many envision perfect anomaly detection or internal vehicle security as the silver bullet to vehicle hacking. However, 3rd party app vulnerabilities have shown that vehicle security needs to be thought of in a more wholesome way. But unless there is a liability of some sort, its hard to incentivize companies to go beyond their normal duties of securing a vehicle internally. Who is responsible if a vehicle hack causes accidents and city-scale traffic jams that cascade to dangerous transportation gridlocks?
From a few prolific incidents, we are aware of certain vulnerabilities in-vehicle internal and external communications. But what about the ones we are unaware of? The unknown unknowns. With the rise in connected surface area, there will be more and more ways that hackers can gain access to vehicles remotely, only limited by their creativity. Since connecting to the Internet is relatively low-cost:
Motivated actors on a low budget could target cities to shutdown through vehicle hacking.
This is indeed scary. So what’s the solution if we can’t know all the entry points? In my opinion, the only way to stop ensuing chaos from hacked vehicles is through resilience.
The first step to resilience is quantification. In the event vehicles are hacked, what are the worst consequences? It boils down to identifying the worst possible consequences and working backward. How many vehicles hacked does it take to stop city transportation?
The second step is mitigation. Now that we have quantified consequences, how do we mitigate them? How can we build transportation to be more resilient against vehicle hacking? Can we have emergency roadways so that critical transportation can reroute in the event of a massive hack of vehicles? Can we safely and quickly remove infected vehicles from the road?
The third step is implementation. Now that we have identified potential solutions, who are the various stakeholders? Automobile companies, chip and equipment manufacturers, insurance companies, city transportation authorities, telecommunication networks, bill, and policymakers all need to work together to develop solutions. This is where the liability aspect comes in. Hacked vehicles have the potential to disrupt so many different sectors that it’s not feasible to hold automobile manufacturers solely responsible for all the consequences. At the same time, this argument should not be a way out for parties to avoid responsibility.
I believe we have an opportunity to work together and make our society more resilient. From our experience during COVID, we have seen various communities come together for the greater good. Once we recover, we will discover that we have emerged as a better society with improved values like encouraging work from home options. In a similar vein, investing in city resilience to hacking is more than just recovering quickly. It has the potential to transform transportation for the better.
