ppt - School of Computing and Information Sciences

fatfallenleafElectronics - Devices

Nov 15, 2013 (3 years and 6 months ago)

81 views

-
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 Savage

Department of Computer Science and Engineering

University of California San Diego


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


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


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



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




250 million automobiles in US


Automotive Embedded Systems:
Self contained
embedded systems called ECUs in 1970s


Integrated into cars functioning and
diagnostics


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







Luxury
sedans
even
offer automated parallel
parking features.
e
g
:

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


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 mechanism


CLS must also be connected to safety

critical systems


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



Framing the
vehicle security and privacy
problem
space


Security problems of vehicle
-
to
-
vehicle
systems


Tuner subculture


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
.


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.



Experiments
with these cars

and their
internal components

in
three principal
settings
:

1.
Bench

2.
Stationary car

3.
On the road

Bench


Extract hardware


Variant of CAN



protocol



Stationary car:


Used CAN
-
to
-
USB



interface


Atmel AT90CAN128


development board



with custom firmware





On the road:




Assess the security properties of CAN bus

A. CAN Bus: link layer data protocol used for
diagnostics used by BMW, Ford, GM, Honda


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


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




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




ECU Firmware Updates and Open Diagnostic
Control:

1.
Software only upgrades to ECUs

2.
As
DeviceControl

Service used in diagnosis
of cars components, many attacks can be
built on it

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




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


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


Noncompliant Access Control
: Device
overrides:



DeviceControl

service
override state of
components



ECUs should reject unsafe
DeviceControl

override requests



Certain requests succeeded without
authenticating


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

A. Attack Methodology

1. Packet Sniffing and Targeted Probing:


Used
CARSHARK to observe
traffic on CAN
buses


Combination
of replay and informed
probing



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


B. Stationary Testing:



1. Radio: completely control, disable user
control and display arbitrary messages

2. Instrument Panel Cluster (IPC):

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

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


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

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

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 Driver

Information Center



Kills the engine and activates the door lock
relay



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


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


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

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

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


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





?


THANK YOU !!