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.

Research Question

How can a testbed facilitate simpler investigation of vehicular security make attacks and 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 [1] and [2] have used an entire vehicle as their testing environment and have used specific methods in order to execute their attack. [3] Connects to the CAN bus via a laptop through the OBD-II port or have organised rewriting firmware on a vehicle component, and [4] uses the CD player, Bluetooth and cellular interfaces as attack vectors. There are other well known attacks such as [5] 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[6], 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

We intend to build a simulated car in a workbench environment to research automotive security concepts. We aim to achieve our objectives through 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.

* ~ 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

LAZARUS TO FILL THIS STUFF IN

• ~ Presented at ICR

just because we felt like it

• ~ Fuzzed the CAN Bus (attack)

because we needed more CAN message and demo material

• ~ Verified that there is no state of security in our vehicle.

mazda engineers were just lazy and wanted to make the most money

We 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 us to replicate 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 will standardise 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, such as a Raspberry Pi or Arduino will simulate 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.

~ * Mention the speed of the Pi being slow

~ * Reverse engineering and Crafting CAN messages is hard by hand - MATLAB

~ * Observing many messages on the dash takes a long time

• Ensuring we do not 'brick' the ECU or other components during code injection; Previous articles such as [7] and [8] 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 [9]. 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.

~ * Mention the current state is insecure - we know the answer!

~ * Even if PCM did store data before a crash - we could store bogus data in its place. Makes it inherently unsafe and easy to change what is taken to court and looks like it was deliberate and not an accident for example. Causes many issues for crash investigators. Can we do the same on planes?

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.

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

References

[1] 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

[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] 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

[8] 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

[9] 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