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? We don’t know.

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

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

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

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

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

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

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

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.

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.

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

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

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.

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

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

Future (to the paper) work Comprehensive Experimental Analyses of Automotive Attack Surfaces http://www.autosec.org/pubs/cars-usenixsec2011.pdf

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.

Questions? Too bad. http://www.specialist-auto.fr/wp-content/files_uploads/2014/12/aston-martin-db10-bond-1.jpg

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?