Survey on Vehicular Attacks - Building a Vulnerability ... - IEEE Xplore

Proceedings of the 2015 IEEE International Conference on Vehicular Electronics and Safety, Yokohama, Japan. Nov. 5-7, 2015.

Survey on Vehicular Attacks – Building a Vulnerability Database Martin Ring, Jürgen Dürrwang, Florian Sommer, and Reiner Kriesten University of Applied Sciences Karlsruhe Institute of Energy Efficient Mobility Germany, Karlsruhe Emails: {rima0003, duju0001, sofl1011, krre0001}@hs-karlsruhe.de Telephone: +49(0)721 925 1428 Fax: +49(0)721 925 1429

Abstract—Modern cars are significantly linked to the outside world because of rising number of connections in the vehicle, connections between the vehicle and the exterior environment , e.g. diagnostics and flash interfaces or the numerous amounts of bus systems for data exchange. All these connections are potential security breaches. Previous papers and this research work show that there are a lot of security vulnerabilities in modern car connections. The aim of this paper is to merge the found vulnerabilities and the available results in literature, categorise them in the same way as in Information Technology (IT) and give an outlook on how most problems can be solved. This paper also aims to introduce an example database for automotive IT vulnerabilities.

I.

I NTRODUCTION

Modern cars feature multiple networks of Electronic Control Units (ECUs). They are interconnected by different bus systems. These buses in today’s automobiles are Local Interconnect Network (LIN) bus, Controller Area Network (CAN) bus, FlexRay and only recently Ethernet [25]. These networks were until recently isolated from the environment with little to no possibility to connect to them. This changed dramatically over the last years. In part responsible for this trend are standardizations like the ISO 15031 [15]. The automotive bus systems were never designed for such an access; this is bluntly obvious by the broadcast nature of the CAN bus. The design decisions of the bus systems combined with the absent of security are the reasons for vulnerabilities that can be found today. We aim to present a complete overview of found vulnerabilities as of today and their classification into six classes: –

Malicious code

–

Intrusion attemps

–

Fraud

–

Intrusion

–

Information security

–

Availability

The detailed explanation and the categorization of the found attacks is described in Section III. This notation is a derivative approach of the Computer Emergency Response Team (CERT) [4], [34].

208

The focus of explanations in this paper is the CAN bus, as it is still the most prevalent network in automobiles and it is quite easy to understand the fundamental functions that lead to the found vulnerabilities. There is a fundamental difference between normal traffic on the CAN bus and diagnostic messages. Figure 1 shows the most important parts of a CAN message structure that was focused for this task. During a diagnostic session the CANIdentifier (ID) doesn’t describe the priority or the content of a message but only the intended recipient. The first byte of the data field contains the so called Protocol Control Information (PCI)-byte. This byte is used by the Transport Protocol (TP). There are multiple TPs as shown in Table I at Layer 4. For the CAN bus the relevant protocols are ISO TP [16] and the proprietary TP 2.0 used by the VAG group. The fundamentals of the diagnostic data are described in detail in Section IV. Header

Data Field

PCI-Byte

CAN-ID

Fig. 1.

Trailer

Diagnostic Data

Structure of a diagnostic CAN frame

II.

R ELATED W ORK

As previously stated, modern cars offer broad attack surfaces on different types of networks. These networks can be divided into two classes: wired and wireless. Attacks on wire bound networks require a physical connection whereas wireless networks can be linked over the air. Therefore wireless networks offer the easiest way to attack a modern car. However in literature, wireless attacks are not mentioned as the most dangerous attacks in relation to safety. But it does not mean that there are no safety relevant attacks using wireless networks because in most cases local networks which are linked with wireless networks are involved in the attack tree. This can be explained with the architecture of modern cars and their segmentation of wired and wireless networks. In majority of the cases, a direct connection between local and wireless networks does not exist, instead an ECU or gateway translates the communication between these two networks. Hence this work is in search for attacks which have at least one wire


TABLE I.

C LASSIFICATION OF THE AUTOMOTIVE PORT SCANNER IN Application / Example Automotive UDS, OBD & KWP

  

ISO TP, TP 2.0 CAN

THE

O PEN S YSTEMS I NTERCONNECTION (OSI)

Layer

Application / Example Ethernet

7. Application 6. Presentation 5. Session 4. Transport 3. Network 2. Data link 1. Physical

HTTP (Port 80), SMTP (Port 25)

MODEL

TCP, UDP IP (e.g. 192.168.0.1) Ethernet

bound network in their attack tree as in many cases the CAN bus was used to cause threats.

catalogue which includes successfully performed attacks. Six classes were used into which the found attacks were sorted.

One comprehensive collection was carried out by Miller and Valasek [19]. In this publication twenty attacks can be found which exploit different vulnerabilities. The researchers were able to manipulate a car’s lights, automatic car parking, anti-lock braking system, turn off the combustion engine and perform further attacks. Furthermore, Checkoway [5] et al. obtained access to the CAN by using an update feature of the on board CD player. They also showed that a special build Windows Media Audio (WMA) file is sufficient to infiltrate a car’s CD player. After controlling this media player they were able to send arbitrary CAN messages. Additionally they used Bluetooth, Tire Pressure Monitoring System (TPMS), serial interface and mobile network to gain access. To be clear, they did not violate safety functions like Miller and his colleague but they showed the first stage of an attack accessing the CAN.

Malicious code refers to input or uploading of modified or malicious code on the target. This can be done by writing a modified firmware or malicious code to an ECU using its update functionality.

Koscher [18] took the CAN access as precondition and presented twelve attacks against different automotive functions. They were able to display arbitrary messages like false speedometer values and fuel levels. Additionally they presented some more sophisticated attacks like engaging and releasing brakes, killing the engine, increasing the RPM of the engine and disabling a cylinder. For example one of the attacks can cause the driver unable to brake and also it was possible to kill the engine during normal operation of the car. Accordingly these attack patterns were extremely dangerous with regard to a car’s safety. Lastly Hope et al. showed a successful implementation of a Denial of Service (DoS) attack [10] on the CAN, to suppress an anti-theft function. Likewise on the side of wireless attacks (in combination with wire bound networks), Schröder was able to create a ghost car which leads to an emergency braking [23]. He forged position messages on Vehicular Ad Hoc Networks (VANETs) in such a way that the attacked car believed that another car was in front of it. Consequently, the pre-collision system braked rapidly to prevent an accident. At this point it should be clear that all researchers engage existent car functions for their attacks. Thus researchers just modified loads or initiated existent functions for their attacks. However most of these threats could be prevented using plausibility checks and / or authentication [18], [19], [10]. III.

E XISTENT ATTACKS

As mentioned in the earlier section, a significant number of automotive attacks exist in publications with a growing number of researches. But unfortunately there is no summary or classification presented. Therefore we have collected the available published information to construct a vulnerability

209

Intrusion attempts describes exploiting vulnerabilities like the absent of a length check in a function that deals with data (buffer overflow). Here, targeted memory cells were overridden to alter the behaviour of a system. Fraud means gaining advantages by stealing information from a system. This can be done by the extraction of firmware, stealing secrets or extracting private data from a car. Additionally this class is related to key-less entry attacks where information is transmitted over a greater distance to fake the keys position. This is useful to fake location information like position of the key and thus open a car even when its owner is hundreds of meters away. Intrusion describes in our case, the triggering or application of existing functions in a way that the target system acts unordinary. In the automotive context this is e.g. misuse of standard functions. Therefore manipulated data can be used to bring a system in a harmful condition state. Exemplary is triggering of a diagnostic function like brake bleed while the vehicle is in motion. Information security describes the act of gaining of unauthorized access to a system. For example, this can be done by bypassing a protection like an encryption. Un-Availability describes any method which leads to the unavailability of a service, function or host. In most cases a DoS attack is used where the network is flooded with a huge number of requests. The bar chart (Figure 2) presents our summary of automotive attacks. The filled grey bars show attacks found in publications while the patterned ones represent attacks that are found in this research work (see Section IV). As illustrated in Figure 2, the classes malicious code, intrusion attempts and intrusion have the highest occurrence. Moreover the class intrusion with a number of 34 published attacks, represents by far the most important attack class. It also includes the most dangerous threats against a car’s safety. Accordingly the search was focused on such attacks in the analysis and 5 attacks were found while attacking vehicles from two premium car manufacturers. A more detailed explanation of these attacks can be found in Section IV. The high number of attacks in this class can be explained with the open standards like Unified Diagnostic Services (UDS), Onboard diagnostics (OBD) and Keyword Protocol 2000 (KWP).


A. Security Access Monitor The details about this program can be found in [22]. This program allows us to monitor the bus traffic; it indicates when a security access is performed, what CAN-IDs are involved in the authorisation process as well as the exchanged seed and key pair. Furthermore the program allows us to extract keys. It is possible to perform this task manually by sending out single seeds of potential interest or to generate a simple text file which contains seeds that can be read in and automatically sent out when the program detects the request for a seed in the bus traffic. The GUI of this tool can be seen in Figure 3.

Number of occurrence

30

20

fo rm

Fr au d

In

M al

ic

io us In co tru de sio n at te m ps

0

In tru sio at n io n se cu rit y Av ai la bi lit y

10

Fig. 2. Occurrence of automotive attacks in science [5], [18], [12], [19], [10], [21], [8], [1], [17], [24], [6], [23], [11], [2] (attacks which are done by us are marked with gray patterns).

Fig. 3.

The GUI of our security access tool [22]

B. Port scanner for CAN and LIN They provide sufficient information to easily start an attack against a car. But to become a safety critical attack, plausibility or authentications have to be absent. Unfortunately in most cars these mechanisms are absent or they are badly implemented e. g., [22]. If these mechanisms are missing, an attacker can execute diagnostic functions while a car is moving instead of standing still like it is supposed to be by the Original Equipment Manufacturers (OEMs). This misuse of diagnostic functions can lead to dangerous situations like losing braking power.

IV.

S URVEY ON V EHICULAR ATTACKS

The port scanner comprises as many basic features of Nmap as possible. The port scanner is designed to perform tests when it is connected to the OBD connector in the car. As all three diagnostic standards (Unified Diagnostic Services (UDS) [13], Keyword Protocol 2000 (KWP) [14] and Onboard diagnostics (OBD) [15]) use the same message format it is possible to find every ECU that has one of these standards implemented. The basic format of the diagnostic payload is shown in Figure 4. As UDS originated from KWP, they both use the same message format; they only differ in the standardized services and that UDS has summarized some services under KWP under one Service Identifier (SID). All three norms use SIDs to categorize services. UDS and KWP use Level Identifier (LEV) to denote services while the OBD standard uses Parameter Identifier (PID). Diagnostic Data

After this introduction and the overview given in Section III, this section presents additional attacks found by the authors of this paper. To find these vulnerabilities the same approach was used as the penetration testing of IT-systems [3]. A blackbox concept was used because there was little to no information of the ECUs and networks which were analysed. In the given automotive conditions there are almost no tools available. One of the more prominent tools that features a basic CAN support is Wireshark [27]. One of the problems with the CAN bus is the possibility of presence of TP-information embedded into the data field as described in detail in Section I. This makes it rather difficult to decipher the messages. Thankfully there are a few standards that allow us to map the CAN bus. We implemented two tools that allow us to monitor the bus traffic on any given car for a security access. The security access is recommended to protect the security, safety, and emissions critical functions according to the ISO 14229 [13]. We also implemented a port scanner much like Network Mapper (Nmap) for automotive networks [9].

210

Service ID (SID)

Subfunction LEV

Parameters

Byte 1

Byte 2

Byte 3...

Fig. 4.

CAN data field content, according to UDS standard

The first subject of interest is to find out how many hosts are available in the network. In classic IT networks these would be equivalent to the search for the available Internet Protocol (IP) addresses in a network. Thanks to the diagnostic standards, it is known that for diagnostic communication the CAN ID does not represent the priority of a message but is equivalent to the IP in IT networks. There are basically two ways to find out how many hosts are available. The first one is by use of the network management [20]. If the car uses a direct network management and this information is available at the OBD port it is simply a matter of counting how many


ECUs participate in the logic ring that is used by the network management. But because not every car uses a direct network management or these messages are not available on the OBD port because they are filtered by a gateway we opted to use the brute force method. To determine how many hosts / ECUs are available a DiagnosticSessionControl message (SID = 0x10) is sent asking for a default diagnostic session (LEV = 0x01). No matter what the answer is, as long as an answer is received, there is an active host behind the last sent CAN-ID. The task to find all present hosts only takes us about 30 sec. on a modern top-of-the-range vehicle. To set this into perspective, a generic diagnostics tester needs up to ten times longer for the same task.

symptoms varied but are most prominent on Human Machine Interfaces (HMIs).

In an IT network the search would continue for open ports and the services behind these ports. As Table I shows, automotive networks don’t feature a direct equivalent as ports in IT networks. In IT networks behind each port is a service while according to automotive standards services are grouped, e.g. DiagnosticSessionControl under SID 0x10, ReadDataByIdentifier under SID 0x22, Communication Control under SID 0x28 and so on [13], [14], [15]. Like before the brute force method is used to search for supported SIDs. The search for supported SIDs is limited to hosts that were found before. The last step is the search for supported LEVs / PIDs with respect to previously found hosts and SIDs.

A brief overview of the vulnerabilities published by other researchers is given in Figure 2 as evaluation process in this work. It also shows that the combination of the lacking concept for protection of diagnostic functions can lead to harmful effects. Therefore it seems feasible to ask car manufacturers to implement protection mechanism to prevent a misuse of useful functions. In the same way the concept of plausibility checks should get the necessary attention. Furthermore, a mix of plausibility checks and authentication could solve the problem with functions forced by standards. Indeed the applied mechanisms or algorithms should follow a selection procedure like the Competition for Authenticated Encryption: Security, Applicability, and Robustness (CAESAR) [30].

C. Found Security Issues

A. Future Work

The search is performed in a default session (SID 0x10, LEV 0x01). Most ECUs send out information in the process of port scanning; a typical example is shown in Table II. This is the information provided by an instrument cluster of an Audi A6 4F; it includes the part number of the component as well as the information what component it is (in the table KOMBIINST. is the German short form for instrument cluster). The OBD standard says that certain information must be available this is one of the reasons why it is possible to read out these information. These informations can be used to target certain ECUs and their services. This is if it is not possible to find potential targets due to the information provided by standards.

A big challenge in information security is to respond to new vulnerabilities in a timely manner. For that, public vulnerability databases have been build [4]. These public databases list vulnerabilities that are found by manufactures or researchers. Thus each one has access to and can inform itself of existent vulnerabilities. Unlike for automotive vulnerabilities such databases do not exist. Consequently, we want to initiate the process of building such databases. One approach for an automotive database is shown in Figure 5.

It is not only possible to collect these information but also to perform a lot of diagnostic functions without the car checking further plausibility of these services. Our port scanner triggers a lot of functions unintentionally. We are able to perform an ECU reset on most ECUs across several classes of multiple OEMs. This is possible without further ado. There are no checks if the vehicle is in motion, if a gear is engaged or any other checks if it is safe to perform the requested service. We do not even need to spoof any messages, perform a security access or change into an extended diagnostic session to reset the High Voltage (HV) ECU of a modern German Battery Electric Vehicle (BEV) which renders any driving assistant system useless. It is easy to alter standard diagnostic function to be a potential hazard. One example of these altered functions is a function that allows workshops to check for malfunctions of individual cylinders, disabling individual fuel injectors. It is possible to deactivate all injectors at once. Even DoS attacks are possible dependent on start of the attack it has a significant impact on the car or none at all. When it has an effect, the

211

TABLE II.

DATA

PROVIDED BY AN INSTRUMENT CLUSTER

HEX 5A 30 30 C2 4B 53 20

9B 39 32 00 4F 54 48

34 33 34 00 4D 2E 32

46 30 30 00 42 20 33

ASCII 30 43 03 00 49 4D 20

V.

39 20 36 00 49 37

31 20 C3 00 4E 33

Automobile manufacturers

Public Private Key Key

E-Mail with encrypted exploit

E-Mail Server

Webserver

Private Key

Fig. 5.

Z> 4F0910930C 0240 Ã ˆ KOMBIINST. 6A M73 H23

C ONCLUSION

Trusted CA

Vulnerability database

[33]

Public Private Key Key

Webinterface

User with vulnerability and exploit

Approach for an automotive vulnerability database

Figure 5 shows a database structure that uses a Public key infrastructure (PKI). This concept guarantees that uploaded


exploits are only available for designated persons, as the exploits are encrypted by a public key. Thus, the exploit can only be decrypted by its associated private keys (one in the property of a trusted certification authority (CA) and the other one in the hand of the designated addressee). The approach proposes three key actors: A trusted CA, existent automobile manufactures and users who have found vulnerabilities (white hat). Users gain access to a database through a web page. This web page is part of an infrastructure of the trusted CA and it includes web and E-Mail servers and the database itself. After registration, users can list their found vulnerabilities and upload the related exploits for automobile manufacturers. Moreover, each exploit will be encrypted with the public key of the trusted CA and the regarding manufacturers. The encrypted exploits will then be saved in the database. After that, the affected manufacturers will be informed of the new vulnerabilities by E-Mail. This E-Mail will consist of two parts. Part one will contain the vulnerability description in textual format. Part two will be the encrypted exploit which can be decrypted by the private key of the manufacturer. Simultaneously a counter in the database will start to run. If the counter expires, the exploit will be decrypted by our CA and be published. As a possible time value 45 days could be used, like proposed by the CERT [29]. Obviously the shown approach fulfils on one side that no black hat can use an exploit to gain an advantage and second the manufactures should ensure that known vulnerabilities will be fixed. Consequently, the presented concept can satisfy the desires of security researches and automobile manufacturers as well.

[13] [14] [15] [16] [17]

R EFERENCES

[26]

[1] M. Bacchus, A. Coronado, and M. A. Gutierrez, “The Insights into Car Hacking,” 2014. [2] D. Bailey, “War texting: Identifying and interacting with devices on the telephone network,” Blackhat USA, 2011. [3] BSI, “Ein Praxis-Leitfaden für IS-Penetrationstests,” Internet, 2015. [Online]. Available: https://www.bsi.bund.de/Penetrationstest [4] CERT, “Vulnerability Notes Database: Advisory and mitigation information about software vulnerabilities,” Internet. [Online]. Available: https://www.kb.cert.org/vuls/ [5] S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, S. Savage, K. Koscher, A. Czeskis, F. Roesner, T. Kohno et al., “Comprehensive Experimental Analyses of Automotive Attack Surfaces,” in USENIX Security Symposium, 2011. [6] S. Craig, “Car Hacker’s Handbook: by OpenGarages,” Internet, 2014. [Online]. Available: http://opengarages.org/handbook/ [7] E. Evenchick, “CANtact,” Internet, 2015. [Online]. Available: https://github.com/CANtact [8] A. Francillon, B. Danev, and S. Capkun, “Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars,” in NDSS, 2011. [9] L. Gordon, “Nmap - Free Security Scanner For Network Exploration & Security Audits.” Internet. [Online]. Available: https://nmap.org/ [10] T. Hoppe, S. Kiltz, and J. Dittmann, “Security threats to automotive CAN networks—Practical examples and selected short-term countermeasures,” Reliability Engineering & System Safety, vol. 96, no. 1, pp. 11–25, 2011. [11] B. Howard, “Hack the diagnostics connector, steal yourself a BMW in 3 minutes,” 2012. [Online]. Available: http://www.extremetech.com/extreme/132526-hackthe-diagnostics-connector-steal-yourself-a-bmw-in-3-minutes [12] Ishtiaq Roufa, Rob Millerb, H. Mustafaa, Travis Taylora, Sangho Ohb, W. Xua, M. Gruteserb, W. Trappeb, and I. Seskarb, “Security and privacy vulnerabilities of in-car wireless networks: A tire pressure monitoring system case study,” in 19th USENIX Security Symposium, Washington DC, 2010, pp. 11–13.

212

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

ISO, “ISO 14229 Unified diagnostic services (UDS),” 15.03.2015. ——, “ISO 14230 KWP,” 01.06.2015. ——, “ISO 15031 OBD,” 15.02.2015. ——, “ISO 15765-2:2011 ISO-TP,” 08-05-2014. G.-H. Kim, K.-H. Lee, S.-S. Kim, and J.-M. Kim, “Vehicle Relay Attack Avoidance Methods Using RF Signal Strength,” Communications and Network, vol. 5, no. 03, p. 573, 2013. K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, and S. Savage, “Experimental Security Analysis of a Modern Automobile,” in 2010 IEEE Symposium on Security and Privacy, pp. 447–462. C. Miller and C. Valasek, “Adventures in automotive networks and control units,” in DEF CON 21 Hacking Conference. Las Vegas, NV: DEF CON, 2013. OSEK/VDX, “OSEK/VDX Network Management Version 2.5.3,” Internet, 2004. [Online]. Available: http:\\portal.osek-vdx.org/files/ pdf/specs/nm253.pdf K. Poulsen, “Hacker Disables More Than 100 Cars Remotely — WIRED,” 2010. [Online]. Available: http://www.wired.com/2010/03/ hacker-bricks-cars/ M. Ring, T. Rensen, and R. Kriesten, “Evaluation of Vehicle Diagnostics Security: Implementation of a Reproducible Security Access,” Secureware, vol. 2014, 2014. H. Schröder, “Analysis of Attack Methods on Car-to-X Communication Using Practical Tests: Analyse Von Angriffsmethoden Auf Die Carto-X Kommunikation Durch Anwendung Praktischer Tests,” Ph.D. dissertation, 2013. D. Spaar, “Sicherheitslücken bei BMWs ConnectedDrive,” Internet, 2015. [Online]. Available: http://www.heise.de/ct/ausgabe/2015-5Sicherheitsluecken-bei-BMWs-ConnectedDrive-2536384.html I. Stroh, “Ethernet revolutioniert die Fahrzeug-Vernetzung: Interview mit BMW,” 04.11.2013. [Online]. Available: http://www.elektroniknet. de/automotive/bussysteme/artikel/102613 Vector Informatik GmbH, “Handbuch CANoe - Google-Suche,” Internet. [Online]. Available: http://www.vector.com/portal/medien/ cmc/manuals/CANoe75 Manual EN.pdf Wireshark-users, “CAN-Sniffing,” Internet, 2013. [Online]. Available: https://www.wireshark.org/lists/wireshark-users/ 201302/msg00004.html W. Zimmermann and R. Schmidgall, Bussysteme in der Fahrzeugtechnik: Protokolle und Standards ; mit ... 99 Tabellen, ser. ATZ-MTZ-Fachbuch. Vieweg, 2007. [Online]. Available: https://books.google.de/books?id=iv1VDZLKkDIC CERT, “Vulnerability Disclosure Policy — Vulnerability Analysis — The CERT Division,” Internet, 2015. [Online]. Available: http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm? D. J. Bernstein, “Crypto competitions: CAESAR: Competition for Authenticated Encryption: Security, Applicability, and Robustness,” 2015. [Online]. Available: http://competitions.cr.yp.to/caesar.html I. Stroh, “Ethernet revolutioniert die Fahrzeug-Vernetzung: Interview mit BMW,” 04.11.2013. [Online]. Available: http://www.elektroniknet. de/automotive/bussysteme/artikel/102613/ ENISA, “Existing taxonomies: Existing taxonomies,” Internet. [Online]. Available: https://www.enisa.europa.eu/activities/cert/support/incidentmanagement/browsable/incident-handling-process/incidenttaxonomy/existing-taxonomies T. Hoppe, “Prävention, Detektion und Reaktion gegen drei Ausprägungsformen automotiver Malware: eine methodische Analyse im Spektrum von Manipulationen und Schutzkonzepten,” Ph.D. dissertation, Magdeburg, Universität, Diss., 2014, 2014. ENISA, “Existing taxonomies: Existing taxonomies,” Internet, 2015. [Online]. Available: https://www.enisa.europa.eu/activities/cert/support/ incident-management/browsable/incident-handling-process/incidenttaxonomy/existing-taxonomies