1. Car Hacking
Patrick, James, Penny

2. What is…? What is a car? Why are there computers in cars?
Why can something other than a car access these computers?
We don’t know.

3. Not an Outline Internal Structure Exploits ECUs
Controller Area Networks
Seed to Key Algorithms
Device Control
Exploits
Testing Methodology
Attack Strategies
Attack Results

4. Why is car hacking bad? Control car components remotely
Physical implications
Privacy concerns
You won’t know about it afterwards
most components, such as windscreen wipers, to brakes can be controlled by a computer
our gps can be part of this network and have personal information on it like addresses
it’s easy for an attacker to wipe all evidence of an attack from the system

5. Controller Area Network
CAN: Controller Area Network
ECU: Electronic Control Unit
Car computers in general
Comprised of 2 buses
High speed bus: safety critical, more trusted
Low speed bus: non-critical, convenience modules
Required in all cars sold in US since 2008
required for diagnostics
a gateway can route things between the buses

6. Here is a list of various ECUs and which bus each is connected to.
Source: Article

7. CAN Security CAN packets: header that says where the packet goes
No addresses used
All packets broadcast physically and logically to all nodes
Each node decides if it should process the packet
Vulnerabilities:
All nodes see all traffic
All nodes communicate all other nodes
DoS-able
No identifiers
Firmware updates
Weak access controls that aren’t used
many vulnerabilities, and on are common to most implementations
because of the broadcast nature
vulnerable to denial of service attacks
Don’t know who sent a packet
answers to standard challenges for authentication when doing sensitive things, like reflashing components, are stored in memory
There are several protection mechanisms written into the protocol, but they are often ignored by ECUs, such as ignore disable communications command

8. Seed to Key Algorithms Authentication method for sensitive operations
One ECU sends the seed (the challenge)
The other replies with the key
Each ECU has its own seed and key
Keys and seeds are fixed and stored in the memory of each ECU
Algorithms used to compute them are not stored in ECUs for “security”
Return of challenge not always used
Brute forcible keys
The algorithm is the challenge and the response between the ecus, one ecu sends a packet requesting access to the protected resource the other responds with the challenge then the key
Also, all nodes see all requests so you can sit on the network and see all keys and seeds passed

9. DeviceControl Essentially debuggers for cars
Assists in diagnosis of a car’s components
Examines state
Manipulates state
In operating systems debuggers are limited by access-control
CANs do not have access-control

11. Testing Methodology Bench Stationary Car Car in motion CarShark
Testing individual ECUs
Stationary Car
Car on jacks
Car in motion
Professional driver, closed course.
Do not attempt.
CarShark
Bench: Working with individual ECUs. Setup involves an ECU either off the shelf or from a car, a CAN-to-USB connector, an oscilloscope, and a power supply
Stationary Car: Similar tests conducted on ECUs in the car through the Onboard Diagnostics II port to determine the effects hacking the CAN can have. For safety purposes, the car was on jacks.
Car in Motion: Testing the exploits in motion on the road to determine if there are any differences between stationary and in-motion effects. Testing was completed with a chase car with a wifi connection to a laptop plugged into the test car’s OBD-II port.

12. Source: Article
CarShark - CAN bus analyser and packed injection tool. Needed to be adapted for proprietary packets in the Car’s CAN. Having a custom tool also added additional testing abilities.

13. Attack Vectors Packet Sniffing and Target Probing Fuzzing
Analyze packets with CarShark
Only sees normal operations
Fuzzing
Send random or partially random packets
Useful for system disruption
Exploit the DeviceControl service
Reverse-Engineering
Dump assembly code & analyze
Adding new functionality
Determine how ECUs communicate with each other.
Perform many normal car operations (turn on the headlights, adjust the stereo, apply the brakes)
Packets for safety-critical actions, such as SRS or ABS, are not visible normally with this approach
Using packets picked up by the CarShark, determine the general format of the CAN packets of the vehicle
Send random packets of the same format into the CAN
Identified the small range of bytes that DeviceControl uses, and quickly determined what combinations control what
Only needed for the most complex ECUs, such as the telematics unit
Required to add functionality that is not available in any normal car operation, such as bridging buses

14. Non-Moving Car Testing
I.E. Stationary
Tested on all ECUs in the car
Radio
First ECU tested, easiest to exploit
Disable user control
Display arbitrary messages and play arbitrary sounds
Brakes
Fuzzing showed how to lock individual brakes as well as sets
DeviceControl Key not needed
Two arbitrary ECUs, there are plenty more.
BUT we are able to release the brakes at speed

15. Non-Stationary Car Testing
I.E. Moving
Tested on ECUs that don’t affect the safety of the car or driver
Exploits were transmitted from a chase car
Cancellation packet sent after exploit is verified
Laptop pulled from port if anything goes wrong
Car functions return to normal shortly after laptop is removed
Only difference was EBCM
Also not enough allotted time at airport
Laptop in test car plugged into OBD-II port and connects with chase car via local wifi
EBCM: When stationary no DeviceControl authentication was required, but after 5 MPH, DeviceControl was needed to apply the breaks. Contrary to that, DeviceControl is not required to release the breaks or prevent the breaks from being applied while stationary or at speed.

16. Source: Article
At speed means on jacks with wheels spinning at 40
On runway means actually tested while moving (some were too dangerous to try).
Need to unlock refers to DeviceControl. Nothing on this table needed to be unlocked, but on other tables the Engine Control Module did need to be unlocked, and the Electronic Brake Control Module did not need to be unlocked when stationary, but did need to be unlocked when going more than 5 MPH

17. Issues Required (almost) physical access to car via OBD-II port
Bluetooth
Wireless Tire Pressure Sensors
Given physical access an attacker could
Cut breaks
Set fire to car
Place bomb in car
OBD: On Board Diagnostics
Not in paper: can be accessed through a bad CD

18. Future (to the paper) work
Comprehensive Experimental Analyses of Automotive Attack Surfaces

19. You’re all engineers, fix it.
[In] Conclusion
Cars are insecure.
You’re all engineers, fix it.
Every electronic control unit in the cars in question was vulnerable to attack, and many of them were exploitable without DeviceControl authentication at speed.
This was not limited to a specific car at the time, and is likely not limited to specific cars now. Some high-end luxury car makers such as BMW and Merc may be implementing more security measures, however.

20. Questions?
Too bad.

21. Defenses Prevent reflashing Signed firmware updates
Disallow 3rd party components
Preventing reflashing is unrealistic
people may want to tune their car
would require you to trust certain mechanics
which ones do you trust
Less extreme: prevent arbitrary ECUs from using reflashing commands
Signed Firmware Updates
3rd Party components increase the attack surface
One option is to have all communication from 3rd party components to go through a “secure” communicator
The secure communicator will filter out bad commands
What is a bad command?