Car Hacking
Patrick, James, Penny
What is…?
What is a car?
Why are there computers
in cars?
Why can something other
than a car access these
computers?
Not an Outline
● Internal Structure
o
o
o
o
ECUs
Controller Area Networks
Seed to Key Algorithms
Device Control
● Exploits
o Testing Methodology
o Attack Strategies
o Attack Results
Why is car hacking bad?
●
●
●
●
Control car components remotely
Physical implications
Privacy concerns
You won’t know about it afterwards
Controller Area Network
● CAN: Controller Area Network
● ECU: Electronic Control Unit
o Car computers in general
● Comprised of 2 buses
o High speed bus: safety critical, more trusted
o Low speed bus: non-critical, convenience modules
● Required in all cars sold in US since 2008
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
Seed to Key Algorithms
● Authentication method for sensitive operations
o One ECU sends the seed (the challenge)
o 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
DeviceControl
● Essentially debuggers for cars
o Assists in diagnosis of a car’s components
o Examines state
o Manipulates state
● In operating systems debuggers are limited by access-control
● CANs do not have access-control
Testing Methodology
● Bench
o Testing individual ECUs
● Stationary Car
o Car on jacks
● Car in motion
o Professional driver, closed course.
o Do not attempt.
● CarShark
Attack Vectors
● Packet Sniffing and Target Probing
o Analyze packets with CarShark
o Only sees normal operations
● Fuzzing
o Send random or partially random packets
o Useful for system disruption
o Exploit the DeviceControl service
● Reverse-Engineering
o Dump assembly code & analyze
o Adding new functionality
Non-Moving Car Testing
● I.E. Stationary
● Tested on all ECUs in the car
● Radio
o First ECU tested, easiest to exploit
o Disable user control
o Display arbitrary messages and play arbitrary sounds
● Brakes
o Fuzzing showed how to lock individual brakes as well as sets
o DeviceControl Key not needed
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
o Car functions return to normal shortly after laptop is removed
● Only difference was EBCM
Issues
● Required (almost) physical access to car via
o OBD-II port
o Bluetooth
o Wireless Tire Pressure Sensors
● Given physical access an attacker could
o Cut breaks
o Set fire to car
o Place bomb in car
Future (to the paper) work
Comprehensive Experimental Analyses of Automotive Attack
Surfaces
http://www.autosec.org/pubs/cars-usenixsec2011.pdf
[In] Conclusion
Cars are insecure.
You’re all engineers, fix it.
Questions?
Too bad.
Defenses
● Prevent reflashing
● Signed firmware updates
● Disallow 3rd party components