{"id":3283,"date":"2017-10-25T10:05:01","date_gmt":"2017-10-25T08:05:01","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=3283"},"modified":"2023-08-06T21:50:07","modified_gmt":"2023-08-06T19:50:07","slug":"vulnerable-vehicles","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2017\/10\/25\/vulnerable-vehicles\/","title":{"rendered":"Vulnerable Vehicles – Connected cars and their security issues"},"content":{"rendered":"

In times of the continuing Internet-of-things- and connectivity-hype, a connected variant of \u201cthe German\u2019s favourite toy\u201d 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.<\/span><\/em><\/p>\n

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.<\/span><\/p>\n

<\/p>\n

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 \u201cold values\u201d 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.<\/span><\/p>\n

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 \u201cunder the bonnet\u201d 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. <\/span><\/p>\n

The rolling WiFi-hotspot<\/b><\/span><\/p>\n

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,<\/i> since data transfer is only one directional and not interactive with the connected environment.<\/span><\/p>\n

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. <\/span><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

\"\"<\/a><\/p>\n

Owing to the described bidirectional data transfer, cars with those capabilities are now labeled as Connected Car 2.0. <\/i>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. <\/span><\/p>\n

Different roads to connectivity <\/b><\/span><\/p>\n

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. <\/span><\/p>\n

At the moment, the paradigm of connecting a car splits into three different variations.<\/span><\/p>\n

1) Direct Integration<\/strong><\/p>\n

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. <\/span><\/p>\n

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\u2019s internal network. It\u2019s 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\u2019t 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.<\/span><\/p>\n

\"\"<\/a><\/p>\n

In most cases, directly integrated connected car systems offer also a control application for the driver\u2019s smartphone. Due to their direct internet connectivity, they can send data from the car\u2019s 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.<\/span><\/p>\n

2) Mobile device connectivity <\/b><\/span><\/p>\n

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\u2019s 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<\/i> and Android Auto<\/i>. 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\u2019s internal network. <\/span><\/p>\n

3) Connectivity via On-board diagnostics (OBD)-II-device<\/b><\/span><\/p>\n

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\u2019re mostly used for software-updates or diagnostic purposes.<\/span><\/p>\n

\"\"<\/a><\/p>\n

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. <\/span><\/p>\n

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\u2019s why we now take a closer look on possible attack surfaces and therefore controllable units of a vehicle. <\/span><\/p>\n

Attack surfaces on connected vehicles<\/b><\/span><\/p>\n

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\u2019s 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\u2019t science fiction, showed a zero-day vulnerability in BMW\u2019s ConnectedDrive app <\/a>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. <\/span><\/p>\n

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 \u201cgood\u201d thing on these attacks was the fact, that the attacker was not able to access viable vehicle functions like the ignition. But there\u2019s 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<\/a>, which is indeed also a potential attack surface to hack a car.<\/span><\/p>\n

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\u2019s a certain lack in security measures against remote exploitations. <\/span><\/p>\n

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 \u201cnon-connected\u201d 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\u2019s 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\u2019t have any aspirations to implement any cryptographic mechanisms, which seems to be a mostly cost-related decision. <\/span><\/p>\n

Real sized remote control cars? <\/b><\/span><\/p>\n

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. <\/span><\/p>\n

Due to the persistent development of new assistance systems in our cars, many components got electrified.  <\/span>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. <\/span><\/p>\n

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. <\/span><\/p>\n

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. <\/span><\/p>\n

Jeep Hack 2015 \u2013 The mother of all car hacks <\/b><\/span><\/p>\n

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 \u201cJames Bond-ish\u201d 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.<\/span><\/p>\n

Due to the already existing research paper <\/a>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<\/span><\/p>\n

1) Remote compromise<\/b><\/p>\n

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. <\/span><\/p>\n

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\u2019 attack.<\/span><\/p>\n

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.  <\/span>So in fact, if you know the year and month, when the car is produced, which isn\u2019t 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 \u2013 surprise \u2013 there\u2019s a much easier solution.<\/span><\/p>\n

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.<\/span><\/p>\n

2) Lateralization<\/b><\/p>\n

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\u2019t even needed to change Uconnect\u2019s software, it\u2019s virtually a built-in option. <\/span><\/p>\n

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 \u2013 with success. With a so called femtocell, which is a compact cellular base station, they were able to get into Sprint\u2019s 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. <\/span><\/p>\n

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 \u2013 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 \u2013 hail to the privacy<\/span><\/p>\n

3) CAN-Bus infiltration<\/b><\/p>\n

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\u2019s cellular- and WiFi-connection-module, but unfortunately it\u2019s only a theoretical isolation. Speaking about the V850-gateway to the CAN-Bus. The V850 controller\u2019s 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\u2019s a computer after all. And if there\u2019s 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. <\/span><\/p>\n