- presented by gaurav mastakar. karl koscher, alexei czeskis, franziska roesner, shwetak patel, and...
TRANSCRIPT
Experimental Security Analysis of a Modern
Automobile
- Presented by Gaurav Mastakar
Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel, and Tadayoshi Kohno
Department of Computer Science and Engineering University of Washington
Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham,
and Stefan SavageDepartment of Computer Science and Engineering
University of California San Diego
Authors
Automobiles are monitored and controlled Introduction of new potential risks Demonstration of fragility of system
structure Electronic Control Unit (ECU) Range of experiments performed Possible to bypass network security Composite attacks
Abstract
Automobiles contains myriad of computers Luxury sedan contains 100 MB binary code
spread across 50-70 computers Safety the main concern Onboard Diagnostics port User-upgradable subsystems
Introduction
Telematics system by GM’s OnStar features Integration of internal automotive
subsystems with a remote command center via a wide-area cellular connection
Hughes Telematics App Store Ford’s Sync Telematics system
Introduction (contn’d)
Experiments on two passenger cars Test cars components to assess resilience Demonstrate ability to control components Combining these mount attacks Evaluation of security properties of each
component and analyze network substrate
Introduction (contn’d)
250 million automobiles in US Automotive Embedded Systems: Self
contained embedded systems called ECUs in 1970s
Integrated into cars functioning and diagnostics
Background
ECU Coupling: complex interactions across ECUs Electronic Stability Control (ESC): monitors
wheel speed, steering angle, throttle position and accelerometers; modulates engine torque and wheel speed to increase traction
Antilock Breaking System (ABS) Roll Stability Control (RSC): apply breaks, reduce
throttle, modulate steering angle Activity Cruise Control (ACC): scan road ahead
and increase decrease throttle. Eg: Audi Q7 Also provide pre-crash features
Background (contn’d)
Luxury sedans even offer automated parallel parking features. eg: Lexus LS460
Electric driven vehicles require precise software control over power management and regenerative braking to achieve high efficiency, by a slew of emerging safety features
Eg: GM’s OnStar will offer integration with Twitter
Background (contn’d)
Car contains multiple buses (high-speed and low speed)
Buses are bridged to provide subtle interaction requirements
Eg: Central Locking System (CLS) controls power door locking mechanismCLS must also be connected to safety critical systems
Background (contn’d)
Telematics: automation in automobiles GM’s OnStar: analyze OBD detect vehicle
problems ECUs monitor crash sensors; OnStar
personnel to perform functions; to do so bridge all important buses, connect to Internet via Verizon’s digital cellular service
Background (contn’d)
Framing the vehicle security and privacy problem space
Security problems of vehicle-to-vehicle systems
Tuner subculture
Related Work
What an attacker could do? How an attacker could gain access? 1. Physical access: insert malicious component
into cars internal network via OBD-II port 2. Via wireless interfaces: five kinds of digital
radio interfaces accepting outside input; remotely compromise key ECUs in our car via externally-facing vulnerabilities, amplify the impact using the results in this paper, and ultimately monitor and control our car remotely over the Internet.
Threat Model
Two 2009 automobiles with electronically controlled components and telematics system
Two vehicles to allow differential testing and to validate the results were not tied to one car
Also purchased individual replacement ECUs via third-party dealers to allow additional testing.
Experimental Environment
Experiments with these cars—and their internal components—in three principal settings:1. Bench2. Stationary car3. On the road
Experimental Environment (contn’d)
Bench Extract hardware Variant of CAN protocol
Experimental Environment (contn’d)
Stationary car: Used CAN-to-USB interface Atmel AT90CAN128 development board with custom firmware
Experimental Environment (contn’d)
Experimental Environment (contn’d)
On the road:
Experimental Environment (contn’d)
Assess the security properties of CAN busA. CAN Bus: link layer data protocol used for
diagnostics used by BMW, Ford, GM, Honda
Intra-Vehicle Network Security
CAN variant includes Slight extensions to framing Two separate physical layers Gateway bridge is used to route data Protocol standards define a range of
services to be implemented by ECUs
Intra-Vehicle Network Security (contn’d)
B. CAN Security Challenges: Broadcast Nature: Malicious component can
snoop packets Fragility to DoS: CAN has priority based
arbitration scheme with states dominant or recessive
No Authenticator Fields: Any component can send CAN packet to any other component
Intra-Vehicle Network Security (contn’d)
Weak Access Control: Protocol standards specify a challenge response sequence to protect ECUs
1. Reflashing and memory protection:2. Tester Capabilities: restricts access to
DeviceControl services Fixed challenge-response pairs are 16 bits ECUs allow response attempt every 10 sec Multiple ECUs can be cracked in parallel Physically removing the component
Intra-Vehicle Network Security (contn’d)
ECU Firmware Updates and Open Diagnostic Control:
1. Software only upgrades to ECUs2. As DeviceControl Service used in diagnosis
of cars components, many attacks can be built on it
Intra-Vehicle Network Security (contn’d)
C. Deviation from Standards Not all components follow standards Disabling Communications: ECUs should
reject “disable CAN communications” Reflashing ECUs while driving: “The engine
control module should reject a request to initiate a programming event if the engine were running.”
Could place ECM and TCM into reflashing mode
Intra-Vehicle Network Security (contn’d)
Noncompliant Access Control: Firmware and Updates: ECUs must be protected by challenge-response protocol• Telematics Unit connected to cars CAN buses use hardcoded challenge and response common to all units• can reflash the unit and can load our own code into telematics unit • Should deny rights to read sensitive memory areas
Intra-Vehicle Network Security (contn’d)
• Standard states defining memory addresses that will not allow tester to read under any circumstances
• But could read reflashing keys out of BCM• DeviceControl keys for ECM and TCM• Extract telematics units entire memory
Intra-Vehicle Network Security (contn’d)
Noncompliant Access Control: Device overrides: • DeviceControl service override state of components• ECUs should reject unsafe DeviceControl override requests• Certain requests succeeded without authenticating
Intra-Vehicle Network Security (contn’d)
Imperfect Network Segregation: standard states that gateways between the two networks must only be re-programmable from the high-speed network• 2 ECUs on both buses and can bridge signals: BCM and Telematics unit which is not a gateway• Verified that we could bridge these networks by uploading code into telematics unit
Intra-Vehicle Network Security (contn’d)
A. Attack Methodology1. Packet Sniffing and Targeted Probing: Used CARSHARK to observe traffic on CAN
buses Combination of replay and informed
probing
Component Security
2. Fuzzing: Damage can be done by fuzzing of packets DeviceControl allows testing devices to override
normal output functionality of ECU DeviceControl takes an argument called CPID
Eg. BCM
3. Reverse Engineering: Dumped code via CAN ReadMemory service and
used third party debugger (IDA pro) Essential for attacks that require new functionality
to be added
Component Security (contn’d)
B. Stationary Testing:
Component Security
Component Security
Component Security
1. Radio: completely control, disable user control and display arbitrary messages
2. Instrument Panel Cluster (IPC):
Component Security
3. Body Controller: control is split across low-speed and high-speed buses
4. Engine: attacks were found by fuzzing DeviceControl requests to the ECM
Attack like disturb engine timing by resetting the learned crankshaft angle sensor error
5. Brakes: how to lock brakes without needing to unblock EBCM with its DeviceControl key
6. HVAC: control the cabin environment
Component Security
7. Generic DoS: disable communication of individual components on CAN bus
C. Road Testing: car was controlled via a laptop running CARSHARK and connected to the CAN bus via the OBD-II port. Laptop controlled via wireless link to another laptop in chase car
Component Security
EBCM needed to be unblocked to issue DeviceControl packets
Able to release brakes and prevent from breaking
Able to continuously lock brakes unevenly Road testing helped to completely
characterize the brake behavior
Component Security
A. Composite Attacks:1. Speedometer: display an arbitrary speed
or an arbitrary offset of the current speed intercepting speed update packets implemented as a CARSHARK module and as custom firmware for the AVR-CAN board tested by comparing displayed speed with actual speed
Multi-Component Interactions
2. Lights Out: disable interior and exterior lights
requires the lighting control system to be in the “automatic” setting
3. Self-Destruct: demo in which a 60-second count-down is displayed on the DriverInformation Center Kills the engine and activates the door lock relay
Multi-Component Interactions (contn’d)
B. Bridging Internal CAN Networks BCM regulates access between two buses Telematics unit connected to both buses can be reprogrammed from device connected to low speed bus; acts as a bridge any device attached to low speed bus can bypass BCM gateway
Multi-Component Interactions (contn’d)
C. Hosting Code; Wiping Code: Implant malicious code within telematics unit
Complicating detection and forensic evaluations Perform action and erase evidence if attack code installed as per above method simply reboot
Multi-Component Interactions (contn’d)
1. Extent of damage: Didn’t anticipate that we would be able to directly manipulate safety critical ECUs or create unsafe conditions
2. Ease of attack: Automotive systems are fragile, simple fuzzing infrastructure
3. Unenforced Access Controls: could load firmware onto ECUs like Telematics unit and RCDLR without authentication; Critical ECUs respond to DeviceControl packets
Discussion and Conclusions
4. Attack Amplification: Maliciously bridging high-speed and low-speed networks Design code to erase evidence Components designed to tolerate failures but tolerating attacks not part of design
Discussion and Conclusions (contn’d)
Future Work:1. Diagnostic and Reflashing Services:
Lock-down capabilities How could mechanics service and replace components Reflashing commands should only be issued with validation Physical access to car required before issuing dangerous commands
Discussion and Conclusions (contn’d)
2. Aftermarket Components: Allow owners to connect external filtering device between untrusted component and vehicle bus
3. Detection versus Prevention: if prevention is expensive, quick reversal is sufficient for certain class of vulnerabilities
4. Toward Security: See what is feasible practically and compatible with interests of a broader set of stakeholders
Discussion and Conclusions (contn’d)
?Questions
THANK YOU !!