Scribd
Upload
98 views50 pages

Experimental Security Analysis of A Modern Automobile: Presented by Gaurav Mastakar

The document summarizes an experimental security analysis of modern automobiles. The researchers analyzed two passenger vehicles to assess vulnerabilities in their electronic control units (ECUs) and intra-vehicle network. They were able to remotely control various components like the radio and brakes by exploiting weaknesses in the CAN bus protocol and lack of authentication. Their work demonstrates the need for more robust security in connected vehicles.

Uploaded by

Ionut Nicolae
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
98 views50 pages

Experimental Security Analysis of A Modern Automobile: Presented by Gaurav Mastakar

The document summarizes an experimental security analysis of modern automobiles. The researchers analyzed two passenger vehicles to assess vulnerabilities in their electronic control units (ECUs) and intra-vehicle network. They were able to remotely control various components like the radio and brakes by exploiting weaknesses in the CAN bus protocol and lack of authentication. Their work demonstrates the need for more robust security in connected vehicles.

Uploaded by

Ionut Nicolae
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 50

Experimental Security Analysis

of a Modern Automobile
 Presented by
Gaurav Mastakar
Authors
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
Abstract
 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
Introduction
 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 (contn’d)
 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


Background
 250 million automobiles in US
 Automotive Embedded Systems: Self contained

embedded systems called ECUs in 1970s


 Integrated into cars functioning and

diagnostics
Background (contn’d)
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 mechanism
CLS 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
Related Work
 Framing the vehicle security and privacy
problem space
 Security problems of vehicle-to-vehicle

systems
 Tuner subculture
Threat Model
 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.
Experimental Environment
 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 (contn’d)
 Experiments with these cars—and their
internal components—in three principal
settings:
1. Bench
2. Stationary car
3. 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:
Intra-Vehicle Network Security
Assess the security properties of CAN bus
A. CAN Bus: link layer data protocol used for
diagnostics used by BMW, Ford, GM, Honda
Intra-Vehicle Network Security (contn’d)
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 ECUs
2. 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


Component Security
A. Attack Methodology
1. Packet Sniffing and Targeted Probing:
 Used CARSHARK to observe traffic on CAN

buses
 Combination of replay and informed

probing
Component Security (contn’d)
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
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


Multi-Component Interactions
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 (contn’d)
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
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
Discussion and Conclusions
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 (contn’d)
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
Questions

?
THANK YOU !!

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy