Validating vehicleLang, a domain- specific threat modelling language, from an attacker and industry
perspective
WILLEM VAN DER SCHOOT
KTH ROYAL INSTITUTE OF TECHNOLOGY
SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
domain-specific threat
modelling language, from an attacker and industry
perspective
WILLEM VAN DER SCHOOT
Master in Computer Science Date: June 2, 2020
Supervisor: Robert Lagerström, KTH & Lyudmila Gerlakh, Scania Examiner: Mathias Ekstedt
School of Electrical Engineering and Computer Science Host company: Scania AB
Swedish title: Validering av vehicleLang, ett domänspecifikt
hotmodelleringsspråk, från ett bransch- och angriparperspektiv
Abstract
Today’s vehicles are incredibly complex devices with vast networks of inte- grated electronics and connectivity. This has led to improved safety, fuel effi- ciency and comfort. However, with more electronics and connectivity comes an ever-increasing attack surface for adversaries to exploit. To help vehicle de- signers better understand the security risks and therefore reduce them, threat modelling can be utilised. vehicleLang is a threat modelling language explic- itly created for vehicles to model and simulate attacks to produce probabilis- tic attack graphs. An accompanying tool to vehicleLang called securiCAD provides a GUI to design and analyse vehicleLang models. This thesis anal- yses vehicleLang and securiCAD by modelling Scania vehicles and several well-known attacks, while also using insights gained from penetration testing.
vehicleLang and securiCAD are found to be good proofs-of-concept but do
not support the level of detail and features required to fully model the attack
surfaces in vehicles and be of use in a vehicle designers workflow. Thus this
thesis goes on to analyse and suggest features for vehicleLang and securiCAD
to achieve this.
Sammanfattning
Dagens fordon är otroligt komplexa maskiner med omfattande nätverk av inte-
grerade elektroniska komponenter och anslutningar. Detta har lett till förbätt-
rad säkerhet, bränsleeffektivitet och komfort. Men med mer elektronik och
fler anslutningar följer en ständigt ökande attackyta för angripare att utnytt-
ja. För att hjälpa fordonsdesigner att bättre förstå säkerhetsriskerna och där-
med minska dem, kan man använda sig av hotmodellering. vehicleLang är
ett hotmodelleringsspråk uttryckligen skapat för fordon för att modellera och
simulera attacker så att probabilistiska attackgrafer kan framställas. Ett med-
följande verktyg till vehicleLang vid namn securiCAD erbjuder ett GUI för
att designa och analysera vehicleLangmodeller. Denna avhandling analyserar
vehicleLang och securiCAD genom att modellera Scaniafordon och ett flertal
välkända attacker, samt genom insikter från penetrationstester. vehicleLang
och securiCAD visar sig vara bra konceptvalideringar, men stödjer inte den
detaljnivå och de funktioner som krävs för att fullt ut modellera attackytorna
i fordon och därmed vara användbara i en fordonsdesigners arbetsflöde. Där-
med går denna avhandling vidare med att analysera och föreslå funktioner för
att få vehicleLang och securiCAD att uppnå detta.
Acknowledgements
This thesis marks the end of a wonderful four years of study, the first three at Imperial College London, the last year on an Erasmus exchange at KTH Stock- holm. This thesis would not have been possible without the help of KTH super- visor Robert Lagerström and my supervisors at Scania, Lyudmila Gerlakh and Niklas Wiberg. It was a pleasure to work with all colleagues at Scania, who always went above and beyond to help. Likewise, a huge thanks to Alessandro Astolfi and Adrian Hawksworth, who made the Erasmus exchange possible and for their continued support throughout the exchange.
People often say the people you meet throughout your degree define the
experience, and that has certainly rung true for me. My flatmates Dan and
Martin, along with Tizard hall 16/17 second floor. Fellow EIE classmates,
with special mention to Georgios, Bill, Andrei, Oscar, Yinghao, Leszek and
Suparnan. EIE elders Fu Yong, Bing, Ben, Tom and Piotr. Lastly, those at
KTH, including my fellow Imperial classmates Yasmin and Stevan, and the
KTH Malvinas 14 duo Jeffrey and Harold.
1 Introduction 1
1.1 Background . . . . 1
1.2 Thesis Purpose . . . . 2
1.3 Research Question . . . . 3
1.4 Ethics and Sustainability . . . . 3
1.5 Schematic Outline . . . . 4
2 Literature Review 5 2.1 The Field of Vehicle Hacking . . . . 5
2.2 Vehicular Threat Modelling . . . . 7
3 Background 9 3.1 Vehicle Basics . . . . 9
3.1.1 ECU . . . . 9
3.1.2 Networks . . . . 10
3.1.3 Network Architecture . . . . 12
3.2 Attack Surfaces . . . . 12
3.2.1 Physical Access . . . . 13
3.2.2 Short Range Wireless Access . . . . 13
3.2.3 Long Range Wireless Access . . . . 15
3.3 Prominent Attacks . . . . 15
3.3.1 Jeep Hack . . . . 15
3.3.2 Tesla key-fob . . . . 16
3.3.3 GM On-Star App . . . . 17
3.4 Threat Modelling . . . . 18
3.4.1 Introduction . . . . 18
3.4.2 Attack Graphs . . . . 19
3.4.3 Probabilistic Threat Modelling . . . . 19
3.4.4 MAL . . . . 20
vi
3.4.5 vehicleLang . . . . 25
3.4.6 securiCAD . . . . 25
4 Methods 27 4.1 Research . . . . 27
4.1.1 Vehicle Architecture & Security Research . . . . 27
4.1.2 Penetration Testing Research . . . . 29
4.1.3 Threat Modelling Research . . . . 29
4.2 Penetration Testing . . . . 30
4.2.1 Setup . . . . 30
4.2.2 Tools . . . . 31
4.2.3 Testing . . . . 31
4.3 vehicleLang analysis . . . . 32
4.3.1 Model Analysis . . . . 32
4.3.2 Model Coverage . . . . 33
4.3.3 Expert Opinion . . . . 33
5 Results 35 5.1 Model I: Jeep Hack . . . . 35
5.2 Model II: Tencent’s Keen Lab BMW Hack . . . . 36
5.3 Model III: US Autosec Research Group’s Hack . . . . 37
5.4 Model IV: Tesla Key Fob hack . . . . 38
6 Analysis 39 6.1 Hardware . . . . 39
6.1.1 Obtaining Hardware . . . . 39
6.1.2 Processors, Memory, Wireless Chips, Femtocells . . . 40
6.1.3 Firmware Recovery . . . . 41
6.1.4 Debugging Ports . . . . 41
6.1.5 OBD-II port . . . . 42
6.1.6 USB, CD, SD card . . . . 42
6.2 Software . . . . 42
6.2.1 Bootloader, Kernel, OS, Applications, File system . . 42
6.2.2 Reverse Engineering Firmware . . . . 43
6.2.3 Firmware Modification . . . . 44
6.2.4 Console Access . . . . 44
6.3 Networking . . . . 44
6.3.1 In Vehicle Network Communication . . . . 44
6.3.2 External Networking: Cellular, WiFi, Bluetooth . . . . 45
6.3.3 Configuration . . . . 45
6.3.4 RF/Key Fob Attacks . . . . 46
7 Discussion 47 7.1 Attack Graphs . . . . 47
7.1.1 Recon vs Exploit Chain . . . . 47
7.1.2 Model Depth for Designers . . . . 47
7.2 Limitations . . . . 48
7.2.1 Over The Air Updates (OTA) . . . . 48
7.2.2 Social Engineering . . . . 48
7.2.3 Mobile Apps & Servers . . . . 48
8 Future Work 49 8.1 vehicleLang . . . . 49
8.2 MAL . . . . 49
8.3 securiCAD . . . . 50
9 Conclusion 52 Bibliography 54 A Appendix 60 A.0.1 Key . . . . 60
A.1 Model I : Jeep Hacks . . . . 60
A.1.1 Architecture Model . . . . 61
A.1.2 Diagnostic Tools . . . . 62
A.1.3 Diagnostic CAN reverse engineering . . . . 63
A.1.4 Infotainment reverse engineering . . . . 64
A.1.5 WiFi . . . . 66
A.1.6 Cellular . . . . 67
A.1.7 V850 chip reverse engineering . . . . 68
A.2 Model II : Tencent BMW Hacks . . . . 69
A.2.1 Architecture Model . . . . 70
A.2.2 Infotainment - USB . . . . 71
A.2.3 Infotainment - Diagnostic Service . . . . 72
A.2.4 Infotainment/Telematics - WebKit . . . . 73
A.2.5 Infotainment - CAN injection . . . . 74
A.2.6 Telematics - Remote Service CAN injection . . . . 75
A.2.7 Gateway forwarding . . . . 76
A.3 Model III : 2010/11 Autosec Hacks . . . . 77
A.3.1 Architecture Model . . . . 78
A.3.2 Media Player . . . . 79
A.3.3 OBD-II Diagnostic Tool . . . . 80
A.3.4 Bluetooth . . . . 81
A.4 Model IV : Tesla Key fob . . . . 83
A.4.1 Architecture Model . . . . 83
Introduction
1.1 Background
Vehicles are ubiquitous in the world, being the primary mode for transport our society heavily relies upon them. The original vehicles were mechanical devices powered by a combustion engine with the first patented vehicle by Karl Benz in 1886 [1]. It was not until just under 100 years later, in 1975, that the first variant of an Electronic Control Unit (ECU) came into production by Ford, it was named the Ford EEC-I. The motivation for the EEC-I stemmed from the need for improved engine efficiency in the air-fuel ratio for combustion.
Since the introduction of the Ford EEC-I, the number of ECUs in vehicles has significantly grown, controlling not just air-fuel ratio, but also features such as the Anti-Lock Braking System (ABS), Cruise Control, Entertainment System and Driver Assist. The number of ECUs present in modern cars can be around 150 [2], thus proving the incredibly complex nature of modern vehi- cles. With this in mind, it is easy to see that these networks of ECUs now make vehicles look more like a series of connected computers rather than a mechan- ical device. The result is that vehicles have become safer, more efficient and comfortable but more prone to attacks.
Vehicle designers have put incredible efforts into component safety and the introduction of electronic safety features such as ABS, however, vehicle designers have thought relatively little about the presence of an adversary. This is becoming ever more important since the attack surfaces on vehicles grow with the increasing connectivity and electronic complexity.
On the adversary side, vehicle hacking first evolved from motor enthusiasts wanting to tune their cars by reverse-engineering the firmware. In the last 10 years, adversaries capabilities have significantly advanced, extending to being
1
capable of carrying out fully remote attacks, with perhaps the most famous being the Jeep hack in 2015 [3]. Security researchers remotely hacked the Jeep while the reporter was driving on the highway, overriding many vehicle functions and killing the engine.
To improve vehicle security, designers face a difficult task since vehicles are becoming ever more complex and connected. Threat modelling is useful for this problem since it allows the vehicle designer to understand the security risks better early on in and prevent them. It has proved vital in other domains such as IT infrastructure, and while many vehicles designers use it to a varying level of degree, there is no complete language and tool that can successfully model vehicle threats in detail.
One possible candidate which may aid the vehicle industry is a threat mod- elling language called vehicleLang [4]. It was created in 2018 based on a lit- erature review but has not yet been verified on real vehicles. The language is based on the Meta-Attack Language (MAL) framework [5] and integrates with a GUI software tool called securiCAD [6]. Designers can map out the network of the vehicle, and the resulting model is then used to run probabilistic simu- lations to determine possible attack graphs for the vehicle. The attack graphs can then be studied efficiently and in turn, feedback into the design process of the vehicle’s security.
The theme of this thesis is in the studying of vehicleLang and securiCAD to provide improvements so that it can be used successfully in the vehicular industry. The method of study is primarily based on white/grey box penetra- tion testing of vehicles and the study of previous security research on vehicle hacking. By posing as an attacker, a deep understanding of the workings and attack paths of a vehicle is gained so that models, threats and attack graphs can be verified.
1.2 Thesis Purpose
In the larger picture, the purpose of the thesis is to contribute towards the Threat MOVE project funded by the Swedish Government Innovation Agency, Vinnova [7].
“The goal of the project is to develop a threat modeling and simulation lan-
guage that allows for real-world modeling and simulation of vehicle informa-
tion system attacks, as well as implementing and testing the language with
real-world systems. The aim is to help automotive IT security to be modeled
and simulated in both design and operational phases, thus contributing to in-
creased understanding of security challenges and risks.” - Vinnova
The collaborators of the project are the Software Systems Architecture and Se- curity Group at KTH Royal Institute of Technology, Foreseeti AB, F-Secure, Volvo Cars and Scania.
1.3 Research Question
Can vehicleLang and it’s integration with securiCAD be used as a successful threat modelling language for the vehicular industry?
vehicleLang was created purely based on a literature review and domain expert questionnaires, while securiCAD has been developed by Foreseeti AB.
Little work has been done experimentally to test usability and to verify the suggested attack paths. This research question is addressed by modelling parts of several vehicles, including a Scania vehicle which in parallel was used for penetration testing. The modelling serves to assess whether vehicleLang can successfully model the architecture of real vehicles. The penetration testing serves to understand if the level of detail of vehicleLang models and attack paths are sufficient. Based on these results, vehicleLang will either be verified, modified or rewritten. For securiCAD, suggestions are gathered to improve the user interaction for modelling with vehicleLang and how to integrate it into a workflow for a vehicle designer.
1.4 Ethics and Sustainability
The ethical considerations for this thesis focus on attackers, the malicious ac- tors. The goal of this thesis looks to thwart these attackers by improving the security of vehicles and therefore improving the safety of countless possible victims and mitigating disruption to key logistics chains.
However, since vehicleLang is open source, information about attacking vehicles will be readily accessible for attackers. vehicleLang only contains at- tack and defence steps though, leaving the implementation up to the attacker.
This leaves the user requiring in-depth architectural knowledge of the vehi-
cle to utilise vehicleLang. Vehicle designers have this knowledge and there-
fore, can use the tool much more effectively, preventing possible attacks in
the future. An attacker, on the other hand, would have to compromise several
steps before achieving this knowledge, and therefore, one could argue an attack
would happen regardless of the tool existence.
For sustainability, one common attack is for adversaries to tune the vehicle;
increasing the engine power and turning off the supply of the diesel exhaust fluid. These attacks lead to the violation of environmental regulations. This thesis aims to model these attacks in the design stage of the vehicle so designers can prevent or at least make these types of attacks more difficult, reducing the occurrence.
1.5 Schematic Outline
The research is structured as follows. Chapter 2 is a literature review that sum-
marises the evolution of vehicle hacking and vehicle threat modelling. Chapter
3 provides a background into the topics of vehicles, vehicle security, promi-
nent vehicle attacks and threat modelling both generally and in the case of ve-
hicleLang. Chapter 4 describes the methods used to carry out the thesis, from
navigating the literature, penetration testing and analysing vehicleLang and
securiCAD. Section 5 is the results section, giving an overview for each of the
models. Section 6 analyses the results going into detail about suggestions to
improve the language. Section 7 discusses the limitations and considerations
of the results and analysis. Section 8 details future work generally in vehicle-
Lang, MAL and securiCAD. Section 9 is the conclusion, concisely presenting
the research findings. The Appendix A, contains all the models, attack graphs
and comments used for the analysis.
Literature Review
The Literature Review focuses on the two main themes of the thesis; the field of vehicle hacking and threat modelling for vehicles.
2.1 The Field of Vehicle Hacking
Vehicle hacking began almost as soon as the ECUs entered the mainstream industry in the 1980s, with car enthusiasts seeking to tune their vehicles by modifying the ECU firmware. It was not until much later in 2010 that the first comprehensive research into vehicle security was published, by Koscher and Checkoway et al. [8]. Prior to this study, other research in this field was primarily theoretical.
The study demonstrated practically on two cars the security flaws which still exist today and form the basis of most attacks. They are firmware modi- fication and CAN message injection, both requiring reverse engineering. The firmware can be modified, and messages can be spoofed to control many as- pects of the car, including engine speed, braking, dashboard messages. De- spite these attacks being sophisticated, the researchers required physical ac- cess to the vehicle, and so the attacks could be matched for example, by the cutting of brake wires.
Koscher and Checkoway et al. released a follow on paper in 2011, demon- strating remote attacks on the same vehicles [9]. This significant paper ex- posed remote vulnerabilities in the information entertainment (infotainment) system, Bluetooth stack and Telematics unit. By exploiting these remote entry points, the CAN bus was then reachable and CAN message injection possible.
Therefore, the previous physical access attacks were now able to be carried out remotely. This paper proved vehicle hacking to be a serious wake-up call
5
to the industry.
In 2012, DARPA funded two hackers inspired by the previous work of Koscher, Checkoway et al., with the goal being to release open-source hack- ing tools to inspire more research into this area. The two researchers, Miller and Valasek, released their first investigation with example attacks on a 2010 Ford Escape and a 2010 Toyota Prius [10]. These attacks were based on phys- ical access to the vehicle and once again showed the great ease of CAN bus injection and firmware modification. DARPA then followed with another grant in 2013 for Miller & Valasek, this time to produce a platform that would help researchers conduct automotive security research without having to purchase a vehicle [11].
Miller & Valasek, inspired to turn the attacks from physical to remote, be- gan analysing remote attack surfaces of 21 vehicles [12]. They identified the 2014 Jeep Cherokee as the most vulnerable and continued to research this ve- hicle culminating in perhaps the most publicised remote hack of a vehicle [3].
In this attack, Miller & Valasek demonstrated the remote attack on a journal- ist driving the Jeep on a highway; controlling the speakers, window-wipers, dashboard and finally killing the engine. This sophisticated attack was the culmination of their 3 years of research, leading to an attack chain exploiting vulnerabilities in the vehicles remote networking, infotainment architecture and poorly designed CAN bus gateways.
The Jeep Hack, like the Koscher 2011 paper, inspired another wave of researchers to get involved in vehicle hacking and these researchers were also now armed with the introduction ’bible’ of vehicle hacking, authored by Craig Smith [13].
At DEFCON 23, in 2015, the renowned hacker conference, a plethora of research was presented on the topic, and the Car Hacking village was formed; a CTF with physical cars and components to hack. Samy Kamkar’s presentation first revealed the vulnerabilities in General Motors car app OnStart with the ability to remotely turn on/off engine, horns and locate the vehicle. Kamkar then presented rolling code key relay attacks for car key entry [14]. Marc Rogers and Kevin Mahaffey’s presentation revealed the first major investiga- tion into Tesla vehicle security, resulting in the ability to access and remotely control the infotainment system [15].
Also in 2015, the well-known hacker George Hotz started the company Comma AI which commercially sells autopilot hardware to attach onto cars.
This hardware hack can control the steering and speed through CAN message
injection accessed by the OBD-II diagnostics port [16]. In 2016 Tencent Keen
Security Research Lab formed becoming a formidable research lab, releas-
ing Tesla vulnerabilities every year since and more recently BMW [17] [18].
KeenLab has exploited a wide range of vulnerabilities from hacking the Tesla infotainment console through a WebKit [19] vulnerability to fooling Tesla au- topilot with adversarial examples [20].
Vehicle hacking has since significantly grown, and the number of researchers and penetration testing companies in this line of work has increased similarly.
The manufacturers are becoming ever so more vigilant with vehicle security and adapting their strategies. One such strategy is offering bug bounty pro- grams [21] [22], where independent hackers get paid for disclosing their find- ings. Looking towards the future, vehicles will remain a somewhat easy target to hack, mainly due to the inherent complex vehicle networks but also due to vehicles containing many third-party systems.
2.2 Vehicular Threat Modelling
Vehicular threat modelling is an active area of research with many vehicle manufacturers working together with academics to present in both academic conferences and vehicle conferences such as ESCAR. The standards associ- ation for the vehicle industry, SAE, recommends security by design princi- ples in their upcoming standard ISO 21424[23], emphasising the usefulness of threat modelling. Since threat modelling began and developed heavily in the IT industry, a lot of research and methods have been transferred to the vehicle industry. The most popular adaption being the Microsoft STRIDE methodology [24], which is the cornerstone of IT threat modelling with the accompanying Microsoft Threat Modelling Tool (MTMT) [25], allowing the drawing of Dataflow graphs and the generation of threats.
There are many papers on hybrid approaches to threat modelling in the ve- hicle industry with Microsoft’s methodology. They are similar and aim for the user to step through the methodology manually and produce a report from the threats. Volvo cars and Chalmers University, in their paper, A Risk Assess- ment Framework for Automotive Embedded Systems [26], first use MTMT to generate the threats before performing a more in detail risk assessment. Kara- hasanovic et al. look at adapting IT threat modelling methodologies STRIDE and TARA [27], and Winsen proposes a hybrid threat methodology primarily based on Microsoft STRIDE [28]. Wolf analysed Winsen’s work and others to come up with another hybrid methodology, taking into account the component safety side as well [29].
To automate most of the manual steps in threat modelling and to allow
designers with less expertise to conduct a security assessment, specific tools
in this field have also been developed commercially and academically. The Yakindu Security Analyst tool [30], a commercial tool, although there is not much public information on this tool, their website lists that it offers graphical modelling of the architecture, threat value assignment, version management of projects, propagation of threat values and risk analysis charts. The Threat- Get tool [31], an academic-led project, offers a subset of the Yakindu Security Analyst. While vehicleLang’s integration with securiCAD [6], offers graphi- cal modelling of the architecture with perhaps the most detail of attacks and defences of each asset and provides the unique feature of probabilistic attack graph generation.
The development of tools in this area is vital for companies with employ- ees of all levels to model their architectures and quickly analyse their security, allowing for seamless design improvement. Currently Yakindu [30] and se- curiCAD [6] with vehicleLang [4] offer the most features.
The previous work around the MAL framework for the vehicle domain primarily consists of the Master Thesis on the creation of vehicleLang [4] by Sotirios Katsikeas. Two minor other works exist, the first a similar study on validating vehicleLang in its infancy at Scania [32], which resulted in proving vehicleLang was not capable of modelling vehicle architectures at that time.
Secondly, a MAL language was designed for the AutoSar architecture [33].
Background
3.1 Vehicle Basics
3.1.1 ECU
The Electronic Control Unit (ECU) is the fundamental building block for the electronic architecture of a vehicle. The ECU can be described as an embed- ded system, but the complexity varies greatly. ECUs have been found to run Linux distributions such as Ubuntu, bare-metal Real-Time Operating Systems (RTOS) and others only basic firmware. The function of an ECU is to elec- tronically control and monitor a sub-system of the vehicle, interfacing with sensors, actuators, wireless chips, and to communicate with other ECUs.
Some examples of ECUs:
• Anti-lock Braking System (ABS) - ABS is vital for driver safety, pre- venting the wheels from locking up during braking, thereby ensuring tractive contact with the road. The ABS ECU is likely to run an RTOS, with multiple input sensor information on individual wheel speeds, ac- celeration, tire pressure and output actuators for brake line valves and pumps.
• Infotainment console unit (ICU) - The ICU on a car normally comes in the form of an interactive screen controlling features such as the Ra- dio, Bluetooth and Navigation. Tesla’s ICU runs the Linux distribution Ubuntu and is essentially a tablet where users can play games and surf the internet.
• Fuel Tank Pump (FTP) - The FTP controls the force of the fuel into the engine, it is a relatively simple ECU and therefore is usually found
9
to run simple firmware controlling only the pump actuator.
Figure 3.1: Hardware testing by Pen Test Partners [34]
The vehicle manufacturer has several choices for ECUs, they can either design the ECU purely in-house, buy one from a supplier or go for one in between which they buy, but is then somewhat customisable. Vehicles contain many ECUs all communicating among each other via the in-vehicle network, and in some cars, the number of ECUs have been found to reach 150 [2]. Figure 3.1 shows some strip-downs of hardware similar to ECUs.
3.1.2 Networks
ECUs communicate with each other over a vehicle network, and there are sev- eral types of networks in use today. Table 3.1 displays some of the most com- monly used networks in vehicles today.
Protocol Use Bandwidth
(Mbps) Relative cost Access Control
CAN robust 1 $$ CSMA/CA
Flexray real-time
w/ high bandwidth 10 $$$$ TDMA
LIN low cost 0.002 $ Polling
Automotive
Ethernet very high bandwidth 100 $$$ CSMA/CD J1939 robust heavy vehicles 0.5 $$ CSMA/CA
Table 3.1: In-vehicle network relative comparison
CAN
The Controller Area Network communications protocol was officially intro- duced in 1986 by Robert Bosch GmbH [35]. It was specifically designed for vehicles in mind, with the aim of an efficient, robust, distributed, real-time control protocol. It is the most common protocol used in vehicles and one with many variations and modifications. There are CAN protocols based on speed, such as low (CAN-LS/CAN-C), medium (CAN-MS) and high (CAN- HS) while others are built upon the basis of CAN, such as J1939 which is used primarily in heavy-duty vehicles and CAN-FD that is for decreased latency and larger payloads.
The physical connection on a CAN is the CAN bus, which is a twisted pair of wires, CAN high and CAN low, which use differential signalling. Figure 3.2 shows a typical CAN frame. The main difference between a CAN and J1939 frame is the extended identifier in J1939 allowing for more information to be encoded. CAN frames have no source or destination IDs and are broadcast messages. Each ECU filters the frames by identifier and thereby deciding if the frame is relevant for that ECU. Other features in CAN include 3 bits for priority and error checking (CRC).
Figure 3.2: CAN frame by Ken Tindell [36]
Flex-ray, LIN, Ethernet
Flex-ray [37], first introduced in 2006, was designed to be faster and more
reliable than CAN but it is much more expensive. Flex-ray can be seen in
many Audis and BMWs today. The Locally Interconnected protocol (LIN)
[38], was designed in the late 1990s as a cheap alternative for small non-critical
sub-systems where speed and bandwidth were not significant. Ethernet, the
primary protocol for computer networking has recently been seen in parts of
Teslas and other luxury brands. Automotive Ethernet implementations have a
much higher bandwidth that is particularly important for the new data-heavy
driver-less technology but comes at the expense of high cost, weight, higher latency and yet to prove to be as robust as CAN.
3.1.3 Network Architecture
There is no standardised vehicle network architecture; they vary greatly by the number of ECUs, protocol types, gateway ECUs and size. To give an example of a possible architecture, refer to Figure 3.3. It can be seen that the network is segmented into different feature domains each running a different protocol, with the more critical such as the powertrain running both CAN and the faster FlexRay [37] protocol, while the in-vehicle experience utilises Ethernet for increased bandwidth. The Gateway ECU is a significant ECU to note since it has the ability to segment the network for adversaries and act as a firewall for messages but also allows for coordination between the different sub-systems.
Figure 3.3: Vehicle Architecture schematic by NXP Semiconductors [39]
3.2 Attack Surfaces
To explain the attack surfaces on vehicles, it is useful to break down the level
of access by Physical, Short-range Wireless and Long-range Wireless, similar
in style to Koscher et al. [9].
3.2.1 Physical Access
Physical access implies the attacker is able to access the vehicle and therefore connect to ports on the vehicle and examine/strip-down electronics for further analysis.
OBD-II port
The OBD-II port is the on-board diagnostics port. The port directly interfaces with the vehicle network allowing for diagnostic messages to be sent and read, and it is primarily designed for mechanics and emission testers. Practically every vehicle has one now since US law in 1996 [40] required OBD-II to be mandatory for all cars and since 2005 for Heavy-Duty Vehicles. Interfacing with the vehicle network means attackers have easy access to listen to and send messages, and this is primarily useful for reverse-engineering the messages.
Debugging Ports
The ECUs electronics are on one or more printed circuit boards, similar to those seen in Figure 3.1. Manufacturers often leave debugging ports on these boards allowing serial communication to the device, such as UART or JTAG.
A poorly secured port interface may allow an attacker to get privileged control of the device. From this, the attacker can start to work out how the ECU works, finding vulnerabilities and opening up possibilities to re-flash the firmware.
Infotainment peripherals
Infotainment ECUs often contain peripherals such as USB ports, SD card slots and CD drives. These slots can be used to upload malicious code, re-flash firmware and extract information. For example, Koscher et al. [9] found two vulnerabilities in a vehicle media player. One where an ISO 9660-formatted CD with a specific file name led to the unit being re-flashed. The second used a specially formatted CD to exploit a buffer overflow so that when the CD played music, it also sent CAN messages. This CD formatting attack could spread far and wide where an attacker could modify many peer-to-peer network files which users then flash and use in their vehicles.
3.2.2 Short Range Wireless Access
Short-range wireless implies the attacker is up to approximately 50 metres
away from the vehicle but has no physical access.
Vehicle Keys
The wireless transmitters on vehicle keys, also commonly referred to as key fobs, allow for a multitude of attacks. The annual Upstream vehicle security report [41] continually shows this is the most common attack vector, with the most common and straightforward of these attacks being the relay attack. Here the attackers have two devices, one close to the key fob with the victim, and one in close proximity to the car. The attackers replay the key signal from one device to another to unlock and drive away with the car.
One security workaround is here is the immobiliser, requiring the key to continually be in the range of the vehicle for it to drive. However, manufactur- ers often use weak encryption algorithms, such as mentioned in section 3.3.2.
Bluetooth
The Bluetooth interface in vehicles is commonplace nowadays, allowing users to play music, connect to apps and make phone calls. The software stack for Bluetooth has been found to have numerous vulnerabilities [42] though and often designers choose to customise parts of the stacks increasing the number of vulnerabilities. When analysing this attack surface, there are two classes, one being authentication to the Bluetooth service and the other being sending an arbitrary command.
For example, Koscher et al. [9], found numerous exploitations through strcpy calls to the stack; these eventually led to any paired Bluetooth device having control over sending arbitrary CAN messages.
WiFi
WiFi is becoming more commonly supported in vehicles nowadays, either with a dedicated access point or a cellular hotspot. It is primarily thought of as pro- viding users with a way to access the internet, but the vehicle can also utilise a WiFi hotspot to communicate with online services and download updates. The two classes of attack surfaces here are similar to Bluetooth with the authen- tication and then code execution. However, since WiFi interfaces are similar to traditional ones, it enables more possibilities for attacks once the device is authenticated.
WiFi authentication usually uses WPA2, but the strength of the password
has been found in many cases to be poor. In the Jeep hack [12], the default
password was created during a specific period with the time as an input to the
password generation, allowing for easy and quick cracking in seconds. In a
hack on the Mitsubishi Outlander [43] it was found the password was short and a GPU rig could crack it in 4 days. Once on the WiFi, further exploits can then be used from open ports and services.
3.2.3 Long Range Wireless Access
Cellular
Perhaps the most important remote attack surface is cellular used by the ECUs such as the Telematics ECU. With 3G/4G connections, the vehicle can be con- nected to from possibly all over the world. The Jeep Hack proved to be ac- cessible throughout America [12]. The attacker might try to exploit services and ports open to control the bus network messages, tracking vehicle position, re-flashing of ECUs and Denial of Service attacks.
Radio, GPS
Satellite Radio, Digital Radio and GPS are all possible attack surfaces. Past attacks have shown navigation systems are vulnerable to GPS spoofing [44].
Re-flashed infotainment systems can parse crafted metadata such as album names from Radio data resulting in CAN messages spoofing [9].
3.3 Prominent Attacks
The attack surfaces give a good overview of the vehicle attacks possible. This section goes into detail on the exploit chains of some of the most successful public vehicle hacks.
3.3.1 Jeep Hack
The Jeep Cherokee 2014 hack was carried out by security researchers Charlie Miller & Chris Valasek in 2014 [12]. In this attack they achieved remote arbi- trary CAN message injection, targeting the majority of Fiat-Chrysler vehicles in the US on the Sprint Network [45]. After the release, Fiat-Chrysler recalled approximately 1.4 million vehicles.
The exploit chain, please refer to Figure 3.4 for a schematic of the exploit:
1. Connect to Sprint Network and scan - The first step was to have a
device connected to the Sprint network. Once connected, the vehicles
were found to be within two IP ranges. From the IP address, you could
query the open D-BUS service to get GPS coordinates and the Vehicle Identification Number (VIN) to identify the target.
2. Connect to D-BUS service and upload SSH Keys - The infotainment ECU’s D-BUS service port was open for anyone to connect to with no authentication. After connecting, an execute method was vulnerable, and therefore SSH keys could be uploaded to allow for future easier access.
3. Reflash ECU - The OMAP chip, which the attacker now has control over, cannot send arbitrary CAN messages since the communication with the processor (V850) with access to the two CAN buses disallowed this. The attacker gets around this by commanding the OMAP to re-flash the V850 with custom firmware to allow arbitrary CAN messages over the SPI communication between the OMAP processor and V850.
4. Send arbitrary remote commands onto the CAN bus - With the V850 re-flashed, the attacker can then send arbitrary command messages to control many aspects of the car including the engine, dashboard, lights and window-wipers.
Figure 3.4: Jeep exploit chain
3.3.2 Tesla key-fob
In 2017, researchers at KU Leuven reverse-engineered the Tesla key fob [46].
They reverse-engineered both the firmware on the key fob and the radio signals
between the fob and the vehicle. From this, they figured out the algorithm used
was DST-40 [47] and that to create a look-up table with all the responses could make the attack very simple and quick to execute.
The exploit chain (please refer to Figure 3.5 for the protocol):
1. Sniff CAR ID - The attacker here must have some hardware to sniff radio signals. Every half a second, the car sends out a message to find the nearby key-fob, this message contains the car ID and a command.
This message can be sniffed by the attacker and the Car ID used later for further responses.
2. Send a crafted challenge to key fob - To get the key, the attacker sends crafted challenges to the key fob a few times. A pre-computed look-up table for all possible key responses to the attackers crafted challenges is the key to this attack here. The first time, the attacker can narrow down the search to 2 ˆ 16 keys using the look-up table that is pre-computed for this challenge, then the attacker sends another crafted challenge to narrow it down once more.
3. Send response to unlock and start - With the key, the attacker can now unlock the vehicle, and the mechanism for unlocking and starting is the same, so once the response is sent, the vehicle can be unlocked, started and driven away.
Figure 3.5: Tesla key fob, PKES protocol by Lennert Wouters [46]
3.3.3 GM On-Star App
At DEFCON 2015, whitehat hacker Samy Kamkar revealed several hacks, one
of which affected GM vehicles using the GM Onstar App [14]. The attack was
a simple man-in-the-middle attack between the app and the GM servers, where Kamkar could then impersonate and retrieve credentials.
The exploit chain:
1. Force user device to connect to attackers network - To man-in-the- middle, the attacker must intercept the communications between the app and GM servers. To do this, the attacker can create a network for the user to connect to. To force the user to connect, the attacker first sniffs for probe requests from the user’s device for previously connected WiFi net- works. The attacker can then rename their network to a probed network, so the victim automatically connects to the attacker’s network.
2. Man-in-the-middle - The attacker can then Man-in-the-middle the com- munication since the SSL certification is not checked and subsequently obtain the credentials.
3. Relay details to the attacker, use app - The attacker can then relay the credentials from the device that impersonated the network to login into the GM Onstar app. The app can then be used to control some vehicle functions such as unlock, engine start, use the horn or request GPS coordinates.
3.4 Threat Modelling
3.4.1 Introduction
Threat modelling is the process in which a system is analysed to identify threats so the designer can understand and mitigate them. The threats help inform the designer which assets are the most vulnerable, what an attack may look like and which defences could be added. It is a task which every safety aware IT de- signer carries out for security analysis of their systems. There are several main threat model methodologies, including STRIDE by Microsoft [24], P.A.S.T.A [48] and those based on MAL languages created by KTH [5]. They are similar in many ways, following the main process of studying each asset (e.g. router, software application), it’s I/O interactions, access control, defences and pos- sible attacks.
A rudimentary example of a threat modelling methodology:
1. Create a diagram of the system, labelling assets, dataflows and defences.
2. Analyse each asset for possible threats.
3. For each threat list the severity.
4. Go through each threat by severity and note the defence needed to pro- tect the asset and dataflow.
Threat modelling is a common thought process in everyday life; for example, this methodology could be used when you assess your home security or when you make a decision when cycling regarding your safety.
Historically, threat modelling has been carried out manually with designers following the methodological approach, drawing models manually and writing the threats out. The manual aspect can be quite a tedious process, and for the designer to know all attacks and defences applicable requires highly-technical domain expertise. Computer-aided tools help solve these problems, leaving the designer with only graphically modelling the design and the software takes care of the threat identification and reports.
Several tools exist with varying levels of automation, but the most widely used is Microsoft’s Threat Modelling Tool (TMT)[25]. TMT is free software, though the assets and threats are specific to Microsoft and Azure [49]. Another tool called OWASP Threat Dragon [50] is supposed to be the open-source future of TMT, sharing many of the functions as TMT and is constantly being developed. There are also commercial tools which cater for more specific domains, these are securiCAD [6], Yakindu Analyst [30] and Threat Modeller [51].
3.4.2 Attack Graphs
Further extending threat modelling is to translate threats into a series of con- secutive attack steps resulting in an attack graph. Attack graphs allow the designer to see more clearly the propagation of an attacker throughout their system, immediately identify weaknesses and helping to spot patterns.
3.4.3 Probabilistic Threat Modelling
The field of probabilistic threat modelling builds upon the standard threat mod-
elling methodologies, with the addition of probability distributions for threats
or attack paths. These distributions can be models for the Time to Compro-
mise (TTC) for an attack step on an asset. An example would be brute-forcing
a password where the distribution would be relative to the cracking algorithm
and hardware used. With the combination of probability distributions for each
possible attack step in one path, a total probability distribution graph is created
which can then be used to identify an indication of TTC. Additionally, using an algorithm to calculate the shortest path, different attack paths can be com- pared to find the most critical path the designer should initially focus on. This once more enhances threat modelling by providing the designer with parts of the systems to prioritise.
3.4.4 MAL
Introduction
The Meta-Attack Language (MAL) [5] is an open-source framework for build- ing domain-specific languages upon and incorporates probabilistic attack graphs.
MAL formalises how to define assets, attack steps, defence steps, associations and cumulative probability functions for the attack steps. The domain expert can build their domain-specific language according to the MAL framework and then use the MAL compiler to generate the probabilistic attack paths. Here Monte Carlo simulations are used to compute the most likely paths efficiently.
The MAL framework takes much inspiration from an object-oriented ap- proach with inheritance, and the current implementation of the compiler is in Java. The syntax of a subset of MAL is explained concisely in Table 3.2.
Symbol Meaning Description
-> Leads to
The successful compromise of this attack step allows the attacker to consequently compromise further attack steps.
Also specifies steps affected by defences and existence checks.
+> Append
Child assets only. When parent and child assets have overlapping elements, child expressions are appended to parents’. The child expressions will otherwise override those of the parent.
| OR An OR attack step A can be reached if any of the attack steps which refers to A is reached.
& AND An AND attack step A can be reached only if all of the attack steps which refer to A are reached.
# Defence
A defence step represents the countermeasure of an attack step and are boolean (defence is ON or OFF).
It is also possible to assign a Bernoulli distribution to govern the activation.
Table 3.2: MAL symbols, adapted from [52]
Assets
The assets in MAL represent all the objects in the designer’s system, from physical objects such as routers and ECUs to logical objects such as credentials and software. Within the asset, the attacks and defences are defined, and the MAL compiler translates an asset to a Java class. The other type of Asset in MAL is the Abstract Asset with the only difference to an Asset being that it cannot be instantiated, only extended.
An example of an abstract class is a Machine from which two assets, Lap- top and Mobile device are inherited from.
1
abstract asset Machine {
2
| connect
3
−> access
4
}
5
6
asset Laptop extends Machine {
7
| passwordAuthentication
8
−> authenticate
9
}
10
11
asset Mobile extends Machine {
12
| fingerprintAuthentication
13
−> authenticate
14
}
Listing 3.1: MAL Asset, Abstract Asset example
Attacks, Defences, Associations
To illustrate a defence, both ’AND’ and ’OR’ attack step types and associa-
tion, here is an example of a possible OBD-II port asset. The ultimate attack
step here is the ’craftedMessageInjection’, where the attacker can send crafted
messages into the vehicle network such as killing the engine. For this to hap-
pen, the first steps require the attacker to gain physical access to the port then
connect to the port. One immediate option for the attacker is to send diagnos-
tic messages, such as a mechanic would do. To craft messages, the attacker
must know the protocols used for the vehicle; here there are two choices, one
is to eavesdrop on the CAN bus and reverse engineer the messages, the other
is to gain access to the vehicle manufacturer’s CAN database listing all the
CAN messages the ECUs send/receive. The ’AND’ attack step here is that
the attacker must be connected to the port and have a CAN database to send
crafted messages. However, there is also a defence here called the gateway
which blocks all non-diagnostic messages sent from the OBD-II port. If the
gateway exists, the attacker is only able to send diagnostic messages in their
attack. Figure 3.6, displays the possible attack paths for the OBD-II port.
1
asset OBD2Port {
2
| physicalAccess
3
user info: physically access the car and port
4
−> connect
5
6
| connect
7
−> diagnosticMessageInjection,
8
craftedMessageInjection,
9
eavesdrop
10
11
| diagnosticMessageInjection
12
−> vehicleNetwork.diganosticInjection
13
14
| eavesdrop
15
−> vehicleNetwork.eavesdrop,
16
reverseCANMessages
17
18
| acquireCANDatabase
19
−> createCANDatabase
20
21
| reverseEngineerCANMessages
22
−> createCANDatabase
23
24
| createCANDatabase
25
−> craftedMessageInjection
26
27
& craftedMessageInjection
28
−> vehicleNetwork.craftedInjection
29
30
# gateway
31
user info: OBD2 Gateway only allows Diagnostic Messages to be sent
32
−> craftedMessageInjection
33
}
34 35
36
asset VehicleNetwork {
37
...
38
}
39
40
// Associations
41
OBD2port [connects] 0..1 <−− Interface−−> ∗ [interfaces] VehicleNetwork
Listing 3.2: MAL Attack, Defence, Association example
Associations are the fundamental connection between assets; they are anal-
ogous to UML class diagram associations, denoting the potential bidirectional
relationship between two assets. In the above example, 0 or 1 OBD2 ports can be connected to any number of networks.
Figure 3.6: MAL introductory example Arrows represent attack step progression
Dashed lines indicate OR step, double dashed indicate a defence
The probabilistic element is in the cumulative probability functions asso- ciated with an attack step. For example, a password could be 8 characters, and the brute-forcing using a dictionary attack could follow the Gamma distribu- tion.
1
class Laptop {
2
| dictionaryCrack [GammaDistribution(1.5, 15)]
3
−> authenticate
4
