Projects:2018s1-105 Cyber security - Car Hacking

Project Team

Lazarus Lai De Oliveira

Michael Pfeiffer

Takudzwa Taziva

Project Supervisors

Dr. Matthew Sorell

Aaron Frishling (DSTG)

Bradley Cooney (DSTG)

Daniel Coscia (DSTG)

Introduction

Since 1991, the CAN Bus protocol has become the most commonly used diagnostic and data transfer system in vehicular systems. These include car networks, marine applications and push-bicycles with electronic gear-shifting. The lack of built in security and the very nature of the CAN bus protocol in an ever evolving digital world presents problems for manufacturers, consumers and other stakeholders as digital security becomes more relevant. Hence it is quickly becoming beneficial to be able to easily test CAN equipped systems.

Testing a CAN bus in a real-world environment can be dangerous and costly as it generally involves working with a vehicle. A well laid out testbed is safer, more portable and removes the limit of working exclusively with one vehicle.

This project intends to investigate the security issues of modern vehicles by designing and developing a testbed which will be able to accurately simulate a motor vehicle. The testbed allows us to verify and demonstrate attacks and vulnerabilities and discuss defence mechanisms. By adding virtualised components to the testbed, the project can evolve into a highly flexible testbed which can motivate new cyber research or be extended to work with other vehicles.

Definitions and Abbreviations

• CAN = Controller Area
• ABS = Anti-lock Braking System
• COTS = Commercial Of The Shelf
• OBD = On Board Diagnostics
• IDS = Intrusion Detection System
• ECU = Electronic Control Unit (also interchangeably referred to in this document as 'embedded system')
• ECM = Engine Control Module
• ICR = Interdisciplinary Cyber Research workshop
• SAS Module = Sophisticated Airbag Sensor Module (but also referred to as Safety control module)
• PCM = Powertrain Control module
• IC = Instrument Cluster, also referred to as 'dashboard'

Research Questions

How can a testbed facilitate simpler investigation of vehicular security and make new research on car security more accessible? How will a virtual and physical testbed environment help to improve security?

A flexible tabletop solution with plug-and-play functionality will allow for nodes to be added without complication. A portable testbed allows the vehicle environment to be simulated without needing the entire vehicle. The testbed will also eliminate the financial risk related with tests on a full vehicle.

Previous Work

Previous work such as and have used an entire vehicle as their testing environment and have used specific methods in order to execute their attack. Article [1] connects to the CAN bus via a laptop through the OBD-II port or have organised rewriting firmware on a vehicle component, and uses the CD player, Bluetooth and cellular interfaces as attack vectors. There are other well known attacks such as that demonstrate the ability to hack a full vehicle.

Objectives

The primary objective of the project is to build and use a vehicle testbed and demonstrate proven CAN bus and vehicle attacks on the testbed.

Reaching this objective will allow us to begin investigation into attacks on commercial vehicle control systems and internal networks and learn about attack vectors in modern vehicles and the security implications of these attacks. Recent work on full vehicle attacks date back to 2011, aside from the Jeep hack , through a specific firmware vulnerability back in 2015. With our testbed vehicle only dating back to 2016, we will confirm if attacks from 2011 are still relevant or whether manufacturers have acted on the discovered vulnerabilities in their vehicles. We will also consider refining the testbed by creating a modular system that can be adapted for use in any vehicle. We can expand this further to allow for nodes to be added in a plug-and-play style to allow for more in-depth analysis of the CAN Bus and other networks.

For example, once we learn how the basic system operates, we could attach a Bluetooth module to the testbed, learn the Bluetooth protocol and demonstrate a simple Bluetooth instruction injection attack.

The testbed aims to make vehicle security research more accessible to other applications which can allow developments to happen faster.

The project lends itself to objectives; including compiling a list of detection methods for the attack vectors on the CAN platform in the vehicle hacking context. With the ability to detect an attack taking place on the CAN bus. This will enable for further research to be conducted using the testbed with a focus on defence measures and implications, as outlined in Future Work.

Method

The aim to build a simulated car in a workbench environment to research automotive security concepts followed the following means:

• Scope out an appropriate minimum level of table-top vehicle functionality to enable research and demonstration of these attacks.
• Include devices that would be appropriate to have to simulate a real vehicle's operation (ECUs and sensors) as well as actuators and components to provide interactive and visible capabilities (dash gauges, door locks, pedals/levers)
• Scope out the potential avenues through which common attacks may be performed against vehicles
• Design an appropriate configuration for deploying and interacting with the testbed
• Neat/well presented, but with the ability to change over components and tap into communications.
• Reasonably representative of how the components are configured/connected in real systems
• Demonstrate operation of testbed as a functional, simulated vehicle operating as intended.
• Demonstrate previously researched attacks on the testbed to verify the state of security in our vehicle.

Results

CAR HACKING!!!

We have acquired core components of a common 2016 mass production car

Core electronic components from a common mass production car were obtained. The low university budget constrained how said components were sourced. Components were sourced from a wrecker, meaning more effort was required to extend the wire loom and a risk taken with the PCM potentially being restricted in crash mode.

Wiring Diagrams

Using wiring diagrams from the vehicle manufacturer, we were able to identify communication wires and relay switch inputs which power the testbed and allow it to function as if still in a vehicle. Wiring diagrams were obtained quite easily from the manufacturer's website. The ease in obtaining these can give a sophisticated adversary much of the needed knowledge for initiating a hacking strategy against their target vehicle. Using these wiring diagrams, the team were able to brute force the dashboard and other components into the 'ignition' [on] state. The components were connected up in a configuration that resembled their connections in a vehicle. Some of the pieces such as antenna, lighting, fuses, fuel injector relays, etc were missing from the testbed, though these were optional for the operation.

We established communication with the CAN bus

Using the PiCAN interface, and can-utils, CAN messages could be received and later, replayed. Once a device is set up for CAN communication, it is really easy to connect and use it with other CAN interfaces. The CAN device was able to be used to gather CAN messages from a vehicle on the road. The ease of setup and use of CAN devices is important in discussing how an adversary will realise control over their victim's vehicle.

Replayed messages

Messages captured over the CAN interface were able to be replayed. This included CAN communication captured from a fully working vehicle, allowing reverse engineering to occur rather easily, though time consuming.

Crafted our own messages (control over dashboard elements)

Supplementing replaying messages, the team were able to craft their own CAN messages based on common node identifiers seen communicated over the CAN bus. The team were able to craft messages which control;

• Changing the “no key” light green,
• Making the “no key” light flicker,
• Various continuous audible tones,
• Making the hazard lights turn on and off,
• Flickering the brake warning and headlights lights,
• Control over the speedometer,
• Allowing the indicators to turn on and off arbitrarily,
• Turning off the oil light,
• Turning off the check engine light,
• Turning off the low battery light,
• Turning off the service light,
• Changing the engine temperature light colour,
• Changing the captured temperature,
• Turning off or on the traction control lights,
• Turning off the handbrake lights,
• Turning off the ABS light,
• Flashing the no seatbelt light,
• Turning off the power steering light,
• Turning on the high beam light,
• Alternating state for “door open” light,
• Control over the tachometer,
• Turning the airbag light off,
• Control over the gear changes,
• Turning off the master warning light.

Built the testbed and made it neat (could take apart a vehicle and rebuild it with wiring diagrams and reverse engineering)

Using wiring diagrams, the core vehicle components were assembled and connected in a state similar to their original form in the vehicle. We have constructed a testbed with plug and play functionality. The testbed uses common connections assigned to inputs common to most vehicle components (such as power, the CAN bus, etc). The testbed is a portable platform which mounts the components and hides the wiring behind. The testbed facilitates a plug-and-play format and is neatly presented such that anyone interested in investigating vehicle hacking can use the testbed as a launchpad for their research endeavours.

BeagleBone - simulating sensors and actuators

   *Section under construction*

Presented at ICR

As part of the collaboration with Universities from Germany and Estonia, we presented our research at the Interdisciplinary Cyber Research (ICR) Workshop in Tallinn, Estonia in June 2018 [2]. It was an opportunity to discuss issues in cyber with other Researchers and to get feedback on our current research. We spoke to a few highly technical cyber security researchers who reiterated that car hacking is a difficult field to get in to. Those spoken to had mentioned that researchers in the car security scene typically do not release their working which enabled their results. By keeping their working concealed, they keep information from adversaries, but they also keep information from researchers who are keen to expand on their developments.

Fuzzed the CAN Bus (attack)

One common attack method used to find faults in automated systems is fuzzing. We used this technique to see how the vehicle system would behave when it receives certain CAN messages. Through this process we managed to gather more CAN messages that result in meaningful responses from the vehicle system. These messages, when replayed, lead to the demo label "Car Hacking!!!" above. This helped us understand the structure and construction of the CAN messages specific to our vehicle.

Verifying that there is no state of security in our vehicle

The CAN bus grew in popularity among car manufacturers in a time when cyber [security] was not on the radar, at least in the motor vehicle industry. As a result, the systems built did not have security of this nature in mind and such is the case with the CAN bus. Vehicles have since advanced and integrated more internet and connected technologies however, the underlying systems are still lagging behind. This fact led to us verifying that there is no state of security in our 2016 vehicle. The CAN bus could be exploited with ease, allowing for injection of messages without any authentication methods or firewalls in place.

Future groups should expect to demonstrate previously established attacks using the testbed with a focus on the CAN bus framework and analyse end-user impact. Examples include attacks that affect the performance or control of a vehicle with minimal physical interaction. This should allow for replication of the results achieved by previous research in an environment which is more accessible and easier to control.

Challenges / Risks / Mitigations

Connector and loom standardisation

To implement a "plug-and-play" format for the testbed, we standardised the connections to essential input/output ports from different components to an agreed pin layout on a common connector.

Simulating sensors, actuators, relays and other inputs and outputs

Certain vehicle components require signals from sensors in order to function correctly. A prototyping device, a Raspberry Pi, simulates behaviour of these sensor components, thereby making the overall testbed more compact and flexible. Extensive testing will be required to ensure the accuracy of the simulated signals.

The need for CAN bus monitoring and the ability to inject commands onto the bus

We need to have software to facilitate reading the CAN bus and diagnostics elements of the car. Ideally this can be addressed through the OBD-II port with a Raspberry Pi or computer software through USB. The Raspberry Pi used is quite slow when replaying CAN dumps. The slow speed is likely due to the limited buffer space on the PiCAN interface. The buffer space is very small when using a cheap serial USB to CAN interface. Trying to send many CAN messages over the USB to CAN interface will cause the unit to cease working until reset.

Reverse engineering the CAN bus

The act of reverse engineering the CAN bus required obtained data from a working version of the vehicle so that the team had somewhere to start in identifying the commonalities between messages sent in the testbed components. The team would replay a CAN message and make observations based on what changed on the instrument cluster. This was a time consuming process and the function of many CAN messages are unknown, as many of the CAN messages would not have resulted in a visual response. Observing any changes when testing the thousands of messages generated by the fuzzing CAN message generator created in MATLAB demanded concentration and motivation. An adversary interested in reverse engineering a manufacturer's CAN bus implementation for malicious purposes needs to be highly motivated. The process demands that the adversary has a lot of spare time.

Crafting CAN messages

CAN messages were crafted in software created in MATLAB. With this software, the team were able to single out a particular identifier and input arbitrary decimal 'data' values, which were later converted into the hexadecimal CAN messages to be sent over the Raspberry Pi. By creating their own messages, the team were able to reverse-engineer many visual functions, and as such, can send CAN messages to the tachometer, speedometer, gear suggestion and temperature sensor to display any chosen value. This is shown in the demo above where the speeds, revs, temperature and gears are changed in a cyclic fashion.

Ensuring we do not 'brick' the ECU or other components during code injection

- Previous articles such as [3] and [4] have accidentally "bricked" the ECUs in their test environments on attempt at code injection or reflashing of the ECU. Given our tight budget, extra caution will be taken to ensure the ECU(s) are not accidentally "bricked".

Taking the lessons learned and applying to forensic, security, penetration testing and other applications

With lessons learned about the architecture of internal car networks, we will have knowledge that can push us into other areas. These include forensics, where victims of car hacking could be identified. Whatever information we can find that is stored in non-volatile memory could also be incredibly useful in the forensic department [5]. Many deaths caused on roads could be investigated with better hindsight as to what components were communicating in the internal vehicle network at the time.

PCM Crash Mode

It is unknown whether the PCM currently installed in the testbed is disabled in a "crash mode" state. The team has limited access to the internal pins of the PCM. We are also unsure if the PCM stores data before a crash, however with the present CAN bus developments, if a PCM did store data before a crash, the team could write false or misleading data in its place. Writing "permanent" data to the PCM over CAN would cause it to be inherently unsafe and easy to change what is taken to court. The adversary could write CAN messages that cause the crash to appear deliberate and not an accident for example. Writing this data causes many issues for crash investigators. The team has also received information that CAN bus is potentially used on air planes. Can we cause the same chaos on a plane black box?

Extended Objectives and Future Work

The testbed created aims to be robust and open-ended to allow for extensions to be implemented in later years. Future investigations and additions could include;

• Simulation of the vehicle in cyber ranges
• Adding new components to the existing modelled vehicle
• Learning signalling interfaces between devices for debugging or forensic purposes
• Reconfiguring the design by replacing components that could
  • Change the make of the vehicle (from a sedan to a SUV from the same manufacturer)
  • Update the car from a 2015 model to a 2020 model for example
  • Emulate a different car (from a Toyota to a Mercedes for example)
• Extend the testbed, adding components that can detect and potentially protect against a variety of theoretical and practical attacks

In future applications, we expect to be able to conduct extensive penetration testing on the testbed. Many cars now include various external inputs which can potentially be vulnerable to attack. There are a plethora of potential attack vectors that have been introduced rapidly through new technology in cars into the market in the last few years.

Car security very much relies on limited knowledge of the broad public, just as personal computers were once “secure by obscurity”. With people becoming more familiar with cyber security in connected applications, solutions from emerging threats will need to be implemented in vehicles before lives are put at risk.

References

[1] K. Koscher A. Czeskis F. Roesner et al, ["Experimental Security Analysis of a Modern Automobile" http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5504804&isnumber=5504699]

[2] S. Checkoway, D McCoy, B. Kantor et al, "Comprehensive experimental analyses of automotive attack surfaces". Available: http://dl.acm.org/citation.cfm?id=2028067.2028073

[3] K. Koscher, A. Czeskis, F. Roesner et al, "Experimental Security Analysis of a Modern Automobile". Available: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5504804&isnumber=5504699

[4] S. Checkoway, D McCoy, B. Kantor et al, "Comprehensive experimental analyses of automotive attack surfaces". Available: http://dl.acm.org/citation.cfm?id=2028067.2028073

[5] [6] A. Greenberg, "Hackers remotely kill a jeep on the highway - with me in it". [Online]. Available: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway

[7] "Proceedings of the 4th Interdisciplinary Cyber Research Workshop 2018", Tallinn University of Technology, 9 June 2018 [Online]. Available: http://cybercentre.cs.ttu.ee/wp/wp-content/uploads/2018/06/CRW_2018_0806.pdf

[8] F. Martinelli, F. Mercaldo, V. Nardone, A. Santone, "Car hacking identification through fuzzy logic algorithms". Available: http://dx.doi.org/10.1109/FUZZ-IEEE.2017.8015464

[9] S. Checkoway, D McCoy, B. Kantor et al, "Comprehensive experimental analyses of automotive attack surfaces". Available: http://dl.acm.org/citation.cfm?id=2028067.2028073

[10] R. Opie, "Smartwatch data helped police make arrest in Adelaide murder case, court hears". [Online]. Available: http://www.abc.net.au/news/2018-03-29/smart-watch-data-helps-police-find-suspect-in-murder-case-court/9602832