Vulnerable Vehicles – Connected cars and their security issues

In times of the continuing Internet-of-things- and connectivity-hype, a connected variant of “the German’s favourite toy” cannot be absent. Modern cars, SUVs and lightweight trucks come with all kinds of connected features, from smartphone interface integration up to social media in the navigation system. But what about the security of these features? Is there a way to compromise them? And what could be possible results of a remote exploitation? This blog post gives an overview about the current state of research in terms of connected car security and shows us some problems, which could be live threatening to some extent.

The automotive industry finds itself a bit between the devil and the deep blue sea at the moment. Besides record turnovers and economic success, the manufacturers are faced with some serious challenges. Dieselgate, alleged cartels, general antitrust issues and massive pressure from the governments due to legislations and the push of new drive concepts are only a short summary of the problems the whole industry has to deal with.

But there is another issue that could lead to a great depression for the automakers. The fascination and attractiveness of conventional cars in the eyes of younger generations is decreasing constantly. Especially the Generation Y does not let itself being impressed from “old values” like a high amount of horsepower, sporty design or the exclusivity of a luxury brand. In their eyes, cars need to have new digital features, which make their life easier, to be attractive.

According to this, car makers introduce many digital and connected features in new generations of their products and continuously build their cars to be part of the Internet of Things (IoT). And some of those new features could have an undisputed benefit for some users and seem to be a very important selling point. However, in regard to development times of conventional parts in the car, like the suspension or passive security features, which are tested for many years before they land in production cars, those car-IoT-solutions popped up in production cars in a very short period. Considering the fact, that many other IoT-devices, which do not weigh several tons and move with 200 km/h have security issues, it is important to look “under the bonnet” of those features – especially when you read articles, like those about the remote exploitation of a connected car from 2015, which we examine later in this text. To get a deeper understanding of this whole topic, we now take a brief look on the history of connectivity in our cars, such as we know it today.

The rolling WiFi-hotspot

The first efforts of the automakers to integrate cars in the IoT environment started already in the 2000s with the implementation of sim cards and cellular GSM-modules in the onboard electronics. Initially, the data transfer was unidirectional to get information for the navigation system or to listen to internet radio. The car itself did not have any interface to send information about its current state to the environment. With the introduction of the first proprietary e-Call services around 2005, the navigation- and entertainment systems, also called infotainment systems, were firstly able to send information about the location of the car via the cellular module. From 2018 on, all new vehicles in the European Union have to be delivered with these features as standard, which finally leads to a wide coverage of connected vehicles. However, these kind of fundamental connectivity features are not really part of the IoT, which leads to a classification as Connected Car 1.0, since data transfer is only one directional and not interactive with the connected environment.

Connectivity was an increasing topic for premium cars since the mid-2000s. Meanwhile even small-sized cars, like an Opel Corsa or a Volkswagen Polo have some proper connectivity functions on board – of course mostly as a fee-required option. Considering the offered functionalities and features, a parallel to smartphone services and applications can be drawn. Cars with modern, connected infotainment systems receive data from the internet (of things) to use various services and may also send many different data to their environment, starting with your location, over information about the cars state, like current fuel capacity, mileage or service requirements up to the integration of your social media profiles.

Fast mobile networks and up-to-date data consumption models also opened the possibility to receive and send more dynamic information about the driving profile, current state of the vehicle, like speed, revolutions per minute and other telematics. Besides the informational benefit for the owner of the car, this data is highly interesting for many different companies with data-driven business models. As an example, you can name insurance companies. With access to the driving profile and style of a certain driver and his car, they can calculate individual rates.

Also road safety can benefit from telematics and data about the state of connected cars. If the electronic stability control from a car a few miles in front of you regulates due to a slippery road, this data can be logged and transmitted to a service provider, which sends all cars behind a warning because of the dangerous road conditions. This is only one brief example, how this kind of data can contribute to safety, but obviously only when the data is processed secure. The table below shows a summary of connected car services.

Owing to the described bidirectional data transfer, cars with those capabilities are now labeled as Connected Car 2.0. Like on other devices, which send and receive data from the internet, more and more new features were developed for connected cars. For example, new cars can be ordered as kind of a rolling WiFi-hotsport, which use the sim card and its cellular-communication module as a gateway to the network.

Different roads to connectivity

Since this blog post is not focused on the evaluation of new features or use cases for connected cars, we now take a look on the technical implementations of how to connect a car to the internet and its environment and the possible attack surfaces for hackers.

At the moment, the paradigm of connecting a car splits into three different variations.

1) Direct Integration

The most holistic way for a connected car-approach is the direct integration. The built-in infotainment systems contain an e-simcard and a cellular module for the connection to the internet. In most cases, those systems also have a built in screen with an advanced graphical user interface, applications for entertainment, navigation and productivity purposes, like an email browser and a calendar. Moreover, those systems have options to influence the state of the car, like the climate control or the engine response, as well as functions to get various information from the car itself.

To get these type of information and to control physical parameters of the car, integrated and connected infotainment systems are often more or less directly connected to the Controller Area Network(CAN)-Bus. The CAN-Bus is known as the vehicle’s internal network. It’s a robust bus standard, designed to allow microcontrollers and devices like the electronic control units (ECUs) for viable vehicle functions to communicate with each other in a serial, democratic way. The CAN-Bus was introduced 1986 and became standard for intra-vehicle-networks. Modern cars could have various CAN-Busses with different broadcast rates, depending on the devices connected on. The typical methods to secure the CAN against compromising are bit monitoring, form check or cycling redundancy check. These are basically techniques to check if there is something unexpected going on inside the CAN, but don’t offer any methods to verify where the commands for the different ECUs came from. The lacking hedge against remote compromising constitutes the first possible attack surface.

In most cases, directly integrated connected car systems offer also a control application for the driver’s smartphone. Due to their direct internet connectivity, they can send data from the car’s state to the application. More advanced systems also offer remote controls to viable car functions like the lights, the horn and even the door locks. Seen in a technical way, those apps communicate via a server with the connected infotainment system, which controls different parameters on one of the internal car networks, like the CAN-Bus. Below is a graphic, which illustrates the basic architecture of a direct integration.

2) Mobile device connectivity

Car connectivity via mobile device is not that sophisticated as a fully integrated approach. However, besides the out-of-car remote control functionalities, where you need a connected sender (smartphone) and receiver (car), a infotainment system, which is connected to the smartphone’s data network could offer pretty similar features. Since 2015, you also have the possibility to mirror some applications from your smartphone directly on the infotainments screen via Apple Carplay and Android Auto. The basic architecture on this type of implementation does not vary fundamentally from the first approach, apart from the way the systems are connected to the internet. That means, that the infotainment still could have access to one of the viable busses of the car’s internal network.

3) Connectivity via On-board diagnostics (OBD)-II-device

OBD-devices are dongles or adaptors, which you connect directly to a CAN-Bus gateway (BCM in the shown picture). The devices are plugged into the female OBD-II-socket of the car. OBD systems give the vehicle owner or repair technician access to the status of various vehicle subsystems. They’re mostly used for software-updates or diagnostic purposes.

Since several years however, the OBD-II is not only used by professionals and hobbyists to repair vehicles. Different dongle-sized devices are now available to retrofit your car with a variant of connected features, like tracking, telematics analysis and even remote controls. The amount of possible functionalities depends on the type of plugged-in-device and the features of the car. Connectivity is implemented with e-simcards in the actual devices or via Bluetooth or WiFi-connection to your smartphone. The first implementation theoretically allows all the possibilities of a direct integration whereas the second variant has the same limitations in terms of connected sender and receiver-issues like the mobile device connectivity.

So we see, that there are different ways to connect a vehicle to the network and make it part of the IoT. But as with all others connected devices, you should ask yourself how secure they actually are? Especially considering the fact, that the connected device in this case weighs several tons and can accelerate to over 200 km/h. Speaking about vehicle hacking, which occurs, when someone with a computer gains unauthorized access to vehicle systems to manipulate the vehicle functionality or to query it for driver data and other sensitive information, we just have to make clear, which fatal effect a remotely hacked car can have. That’s why we now take a closer look on possible attack surfaces and therefore controllable units of a vehicle.

Attack surfaces on connected vehicles

Referring to the different methods to implement connectivity into a vehicle, you can see all three ways as possible open gates for an exploitation. A potential attack could go through the connected infotainment system’s WiFi- or bluetooth-port, as wells as via its cellular-network-module. Applications on the system, which require the internet and even the USB-Port of the system could also be potential gates for an attack. A mobile device that is connected to a vehicle is also a potential attack surface, especially when you have remote functionalities via an app. That those scenarios aren’t science fiction, showed a zero-day vulnerability in BMW’s ConnectedDrive app for iOS and Android in 2016. A client-side cross site scripting web base vulnerability allowed remote attack to inject own malicious script codes to the client-side of the affected module context. These allowed the attacker to block some functions of the application or even to execute them.

A pretty similar flaw showed the Tesla app for remote control and monitor functionalities of the Model S in 2015. Even unlocking the car was possible for attackers. The way, the compromising was executed, was nothing new for connected devices. The only “good” thing on these attacks was the fact, that the attacker was not able to access viable vehicle functions like the ignition. But there’s also a pretty easy solution for this, although it has nothing to do with hacking a fairly connected car. If you are interested you can read the linked article about keyless-go-hacking, which is indeed also a potential attack surface to hack a car.

The OBD-II-port and all the newly available connected devices to plug in, could also be an open gate for attackers. Especially because the security measures to prevent remote hacking attacks are mostly implemented in the devices itself. Since the OBD-II-port exists since the early 90s, an era, where connected vehicles were dreams of the future, you can imagine, that there’s a certain lack in security measures against remote exploitations.

Besides the attack gates, which were made possible through the different ways of connectivity, modern cars provide even more ways for remote exploitations. Examples for a “non-connected” gate are the sensors of the Tire Pressure Monitor System (TPMS), which is a required standard feature in the European Union and the North American markets. Besides the components for pressure monitoring, those sensors have radio frequency(RF)-components to talk to a receiver inside the car, which sends the data to one of the ECUs, that monitor the general state of the car. The receiver is usually the same one that is used for the remote key. The TPMS sends either on 315Mhz or 433Mhz-frequency and uses encoding but no signal encryption. Therefore it’s possible to compromise the signal in a fairly easy way and forcing the sensors to send false signals. This leads to a tire pressure warning light on your dashboard, which may cause you to stop your car. On first hand, this is annoying, but when you think about it twice, this can lead to a scenario where a possible thief can force you to stop and leave your car. This could may be a stressful moment, where you leave the doors open, which is a pretty obvious invitation for a carjacking, especially when you consider that the attack range of this kind of exploitation is up to 50 meters. This issue is known since the introduction of TPMS-systems, which send on radio frequencies. Sensor and car manufacturers rate the effect of those attacks as rather low and don’t have any aspirations to implement any cryptographic mechanisms, which seems to be a mostly cost-related decision.

Real sized remote control cars?

Since we already spoke about one possible scenario and its effect in context with the TPMS, we now just take a quick look on possible controllable units in a theoretical exploitation scenario. After compromising one of the attack surfaces and getting access to the internal car networks like the CAN-Bus, an attacker may could have also access on ECUs, which control viable vehicle functions.

Due to the persistent development of new assistance systems in our cars, many components got electrified.  The steering power support for example, was up to the mid-2000s driven hydraulically. With the introduction of features like self-parking-pilot or line-keeping-assistance, the steering got electric power support, which enables the control units of various assistance systems to self-perform steering maneuvers. The brake system, accelerator pedal, transmission and many other systems undergone the same electrification, which made them completely controllable by an electric unit without any mechanical input.

With this paradigm change in mind, the theoretical risks of compromising a connected vehicle are devastating. Imagine the following scenario. An attacker gets remote access to one of the internal car networks via a compromised gateway, such as the connected infotainment system. The system itself also has a gateway to the main CAN-Bus, providing functionalities such as the activation and deactivation of driver assistance systems. After compromising the infotainment systems and gaining access to the CAN-Bus gateway, the attacker can infiltrate the bus with malicious commands for those ECUs, which are responsible for the control of fundamental vehicle functions. As a result, the attacker has now fully remote control over a vehicle, just over the network. One would rather not think about the disastrous consequences such a worst-case-scenario could have.

You think, that this whole scenario is exaggerated and only theoretical? Well, maybe in the eyes of the carmakers and suppliers, who develop and sale connected car devices. The majority of them is pretty convinced about the security of their solutions, but the reality says something different, like we see in the following example. 

Jeep Hack 2015 – The mother of all car hacks

In 2015, the automotive cybersecurity researchers Charlie Miller and Chris Valasek caused with their experiments on a 2014-MY Jeep Cherokee a worldwide recall for 1.4 million vehicles. How they did that? They demonstrated that the imagined horror-scenario from above is actually not that “James Bond-ish” as you might think. The two researches worked in this field since 2010 and showed already various showcases to infiltrate a car, but with the Jeep Hack, which was actually a zero-day exploit, they took the whole thing to the next level, since they implemented a remote exploitation along with getting remote control of fundamental vehicle functions. Their code was and still is a nightmare for the manufacturers and suppliers in the connected car industry.

Due to the already existing research paper and many other articles and blog posts about the Jeep Hack, we just take a brief look on the details and technical execution to understand the security flaws of the system. For a better understanding we subdivide the attack paradigm now in three steps

1) Remote compromise

Fiat Chrysler Automobiles (FCA), the corporation behind Jeep, like practically all carmakers, is doing its best to integrate their cars in the IoT-environment. To realize those efforts, they launched the so called Uconnect-systems in their cars. Uconnect is an internet-connected system in hundreds of thousands of Fiat Chrysler cars, SUVs and trucks. It controls the vehicles entertainment functionalities, the satellite navigation, enables phone calls and connected services like real time traffic information or point of interests on the navigation. It even offers a WiFi-hotspot.

The Uconnect-version in the compromised vehicle is built by Harman and contains a mainboard with a texas-instrument chip running on QNX. It also has two daughter boards. One is the cellular-communication module (Sierra Wireless) with a built-in sim card from Sprint and the other is a so called Reneseas V850 processor, which serves as a gateway to the CAN-Bus of the car. There is an air gap between the two daughter boards, but both are physically connected to the mainboard. This is a fairly typical setup for connected infotainment systems in cars and served as the pivot point for the researchers’ attack.

The first attempt to compromise the Uconnect system was conducted via the WiFi-port and due to the fact, that the WPA2-passphrase is generated automatically, based on the time when the car and its infotainment system is turned on for the very first time, not that difficult as expected.  So in fact, if you know the year and month, when the car is produced, which isn’t that hard to guess, and you can suppose that the car is produced at day time, you have about seven million possible combinations. A brute force attack could get the passphrase in about one hour. But – surprise – there’s a much easier solution.

Instead of being based on the real time, it turned out, that the Wi-Fi passphrase is generated before the actual time is set and therefore based on a default system time plus a few seconds, depending how long the head unit needs to boot up. So the number of possible variations shrinks to roughly 30, which is even for an amateur hacker a pretty easy task to solve.

2) Lateralization

Once connected with the system, they used a network mapper (Nmap) to scan the system for open ports on the default gateway. As a result, they found the open port 6667, which provided access to the so called D-Bus. D-Bus is an inter-process and remote procedure call, which is used for communication between processes and contains an execute method, which is designed to perform arbitrary shell commands on the system. This opened a quite impressive set of possibilities for the hackers. Valasek and Miller were now able to completely control the entertainment system and track the GPS-signal from the navigation system. To exploit this possibilities you don’t even needed to change Uconnect’s software, it’s virtually a built-in option.

The only drawback in this scenario was that only a minor part of the Uconnect systems had the WiFi-option permanently on. Since the system is also connected to the cellular network with its Sprint (mobile connection provider) sim card, they researched for a flaw in this way of connectivity and tried to exploit it – with success. With a so called femtocell, which is a compact cellular base station, they were able to get into Sprint’s internal network and manage a mass scan of IP-addresses, listening to the certain calls they already knew from their experiences with the WiFi-compromising.

Since the D-Bus related port 6667 was also open in the cellular network, they could perform the same attacks as on the WiFi-hack – theoretically for all vehicles, equipped with the Uconnect. So it was possible for them to track the position of over one million cars in the United States of America, easily from their notebooks at home on their couch – hail to the privacy

3) CAN-Bus infiltration

Obviously, the next step was to find a way to get access to the CAN-Bus and its sensitive ECUs. Like mentioned before, there is an air gap between the infotainment’s cellular- and WiFi-connection-module, but unfortunately it’s only a theoretical isolation. Speaking about the V850-gateway to the CAN-Bus. The V850 controller’s software was designed in some cautious way, making it possible to listen to CAN bus, but not to send commands over it. But you know, it’s a computer after all. And if there’s no capability you need out-of-the-box, you can simply add one by reprogramming the computer. The researchers found a way to reprogram the firmware of the V850 through a software update for the whole system. The maliciously crafted software update made it possible to interconnect all hardware modules inside the Uconnect, which offered the actual possibility to remotely send CAN-messages via the infiltrated system. After this move, Miller and Valasek were able to control nearly every fundamental component of the car remotely, since the majority of viable functions were controlled by an ECU and supported with electric motors. The video below demonstrates the performed attack and its consequences.

The result was devastating for FCA. After the release of the research results, Chrysler recalled nearly 1.4 million vehicles to fix the security issues with a software update. For the concern, this fix was embarrassing and costly. But as a positive effect, you can see that the security awareness for connected cars increased a bit. However, car hacks still occurred afterwards, as another research team demonstrated last year on a Tesla Model S, which was also remotely exploited via the Wi-Fi hotspot of the infotainment including access to the CAN-Bus. And also Tesla reacted with a software update over the air to close the gap. Read more here. 

The problem is not solved

The Jeep-, as well as some other vehicle-hacks, which occurred in the last years, impressively demonstrated that mostly all possible attack surfaces show vulnerabilities for different malicious scenarios. Just to get a quick impression, the following list gives a brief summary about theoretical attack scenarios with a following discussion about possible solutions for the security problems in the car industry.

• DDos-Attack

A distributed-denial-of-service attack on a compromised infotainment system could block fundamental functionalities on the device, like the navigation. In the worst-case, the attacker also has access to CAN-functions and is able to immobilize the whole car. Hypothetical it’s also possible, that the compromised infotainment systems becomes part of a DDos-bot net.

• Manipulations

Like in the example with the hacked Jeep Cherokee, remote exploitations of vehicles and compromising viable functions is not science fiction anymore.

• Location-Tracking

The GPS-location of a compromised vehicle can be fetched. This helps to track certain vehicles, which may be interesting for organized crime. Fetching the location of a car and its driver is also a huge issue in terms of privacy.

• Ransomware

A blackmail message on your head unit in style of “Pay 10.000$ to the following paypal-account to unlock your vehicle”? Also a potential attack scenario.

• Spying

Since modern vehicles are equipped with several cameras for various driving assistance systems, a compromised vehicle could also be used for spying and tapping purposes.

• Fraud

Analogue to malicious fraud on mobile phones, connected cars with built-in e-simcards and the corresponding provider contracts could also be used for the same purposes.

• Spam

Like on any other device, connected to the internet and equipped with a graphical user interface, the car’s infotainment system could also receive spam messages, or even worse, get part of a spam bot net.

As you can see, connected cars suffer the same security and privacy issues as many other “conventional” devices. But how is this possible, for products which stem from companies, where safety is one of the highest development goods? A possible explanation lies in the whole car development culture, which is a rather heavy weight and stiff process. New topics, especially in terms of digitalization are often not prioritized properly, due to a lack of understanding and expertise. Looking at a study from McKinsey in 2016, which stated, that 75% of all OEMs don’t have an actual strategy in the event of a car hack, emphasizes this assumption. 

The general mindset should be “safety through security” since connected features indeed have a big benefit for driving assistance systems. To realize such new development cultures, car manufacturers have to open their systems and collaborate with other OEMs and service providers in this area. This would be the end for the current “security through obscurity”-paradigm. White-hat-hackers like Miller and Valasek aren’t researching in this area to cause vehicular mayhem. The intent of researchers like them is to create an awareness for security and possible worst-case-scenarios in the connected car environment and work on solutions against the security gaps.

As a final point of discussion and inspiration for future research, I want to bump some possible solutions to make connected cars finally secure.

• Secure the bus

Carmakers should implement functions to monitor the CAN network for signs of intrusion. All ECUs on the bus should be authenticated with an input validation, in the best case also using security certificates. A step further is the end to end encryption of all CAN-messages, but these would require less complexity, so the number of  ECUs on the CAN has to be reduced or curated.

Maybe the readers of this blog have another ideas to secure the CAN as the last instance of a firewall-system in a connected car. Let me know in the comments!

• Update-culture

No system in this world is “unhackable”. So it’s even more important, that possible point of attacks were made obsolete as quick as possible. On most devices, security gaps are closed as soon as possible via patches, available as download. Some automakers already introduced the “update-over-the-air” culture, but there are still connected cars on our roads, which have to be recalled to the workshops for every software-update they get. Some owners don’t even update their car software in years. Just imagine this on your computer at home…

• Culture change

As already stated, the whole development culture in the automotive industry has to change and adapt best practices from IT- and tech-companies. An open cooperation with consortiums of all carmakers and service providers is needed, to define standards in car security and combine expertise in the cyberwar against car hackers. Additionally they have to be open for models like a bounty hunting program and the open cooperation with researchers and white-hat-hackers.

And now interaction time – do you have any other ideas, how to define standards for connected car security and make them bullet-proof against malicious attacks?