Automotive computers, or Electronic Control Units (ECU), were originally introduced to help with fuel efficiency and emissions problems of the 1970s but evolved into integral parts of in-car entertainment, safety controls, and enhanced automotive functionality. This presentation will examine some controls in two modern automobiles from a security researcherís point of view. We will first cover the requisite tools and software needed to analyze a Controller Area Network (CAN) bus. Secondly, we will demo software to show how data can be read and written to the CAN bus. Then we will show how certain proprietary messages can be replayed by a device hooked up to an ODB-II connection to perform critical car functionality, such as braking and steering. Finally, weíll discuss aspects of reading and modifying the firmware of ECUs installed in todayís modern automobile. Chris Valasek Christopher Valasek is the Director of Security Intelligence at IOActive, an industry leader in comprehensive computer security services. Valasek specializes in offensive research methodologies with a focus in reverse engineering and exploitation. Valasek is known for his extensive research in the automotive field and his exploitation and reverse engineering of Windows. Valasek is also the Chairman of SummerCon, the nation’s oldest hacker conference. He holds a B.S. in Computer Science from the University of Pittsburgh.

1. The
current
state
of
automo/ve
security
Dr.
Charlie
Miller
(@0xcharlie)
Chris
Valasek
(@nudehaberdasher)

2. INTRODUCTION

3. Who
• Charlie
Miller
[Security
Engineer]
|Twi2er|
• Chris
Valasek
[Director
of
Security
Intelligence]
|
IOAc8ve|

4. Agenda
• Anatomy
of
an
aJack
• CAN
Basics
• AJacking
the
CAN
bus
• Securing
the
modern
vehicle

5. ANATOMY
OF
AN
ATTACK

6. Step
1:
Code
execu/on
• Remote
Telema/cs
unit
TPMS
Bluetooth
“Connec/vity”
apps,
Web
browser,
etc

7. Step
1:
Code
execu/on
(cont.)
• Local

8. Step
2:
CAN
message
injec/on
Compromised
ECU
ABS
ECU
Steering
ECU
Other
ECUs…

9. AJack
Scenario
• A
remote
vulnerability
s/ll
relies
on
‘local’
informa/on
– Example:
A
remote
exploit
targe/ng
a
vulnerability
in
the
Bluetooth
receiver
is
only
harmful
if
the
aJacker
knows
specific
informa/on
about
the
vehicle
• Both
learning
the
local
control
and
remote
vulnerability
are
required
• Local
can
actually
take
longer
due
to
being
different
for
every
vehicle
– Remote
can
span
makes/models
due
to
nature
of
OEM
purchasing
of
devices
(i.e.
infotainment
systems)

10. ELECTRONIC
CONTROL
UNITS
(ECUS)

11. Electronic
Control
Units
• Controls
almost
every
aspect
of
the
modern
automobile
• Take
input
from
sensors
and
provide
output
to
actuators
• Located
in
various
places
throughout
the
car
• ECUs
are
running
custom
code
on
unusual
hardware
– Infotainment
systems
may
be
Linux/Windows
variant,
but
func/on
ECUs
are
custom
code

12. ECU
Structure

13. Ford
PCM
Connector

14. Ford
PCM
ECU

15. CAN
BASICS

16. CAN
Overview
• CAN
IDs
can
be
11
or
29
bits
long
• Data
length
can
be
0
to
8
bytes
in
length
• CAN
ID
is
used
as
a
priority
field
– CAN
ID
00
has
priority
over
CAN
ID
01
• Interes/ng
data
is
in
the
applica/on
layer
• Broadcast
in
nature.
Therefore
all
nodes
on
a
bus
will
see
all
messages

17. Normal
CAN
message
• Ford
Escape
– IDH: 03, IDL: B1, Len: 08, Data: 80 00 00 00 00 00 00 00
• Toyota
Prius
– IDH: 00, IDL: B6, Len: 04, Data: 33 A8 00 95
• Varying:
Lengths,
IDs,
Data
– Toyota
has
a
checksum
of
“95”
at
the
app
layer
*
This
format
was
designed
by
us
to
be
human
readable
and
diges/ble
by
our
API

18. Diagnos/c
Example
• Ford
Escape
communica/ng
with
ABS
ECU
– IDH: 07, IDL: 60, Len: 08, Data: 03 14 FF 00 00 00 00 00
IDH: 07, IDL: 68, Len: 08, Data: 03 7F 14 78 00 00 00 00
IDH: 07, IDL: 68, Len: 08, Data: 03 54 FF 00 00 00 00 00
• Each
ECU
has
one
or
more
IDs
associated
– In
this
case,
ABS
is
0760
• Responses
are
8
more
than
ID
• Mainly
used
by
mechanics,
but
we’ll
show
how
some
are
used
by
us…

19. STANDARDS
&
PROTOCOLS

20. Useful
Standards
&
Protocols
• ISO
15765-­‐2
(ISO-­‐TP)
– Standard
for
sending
arbitrary
length
data
over
CAN
• ISO
14229/14230
– Standard
for
services
running
on
the
ECU
– No
service
is
mandatory
– Defines
certain
bytes
for
diagnos/c
purposes

21. Services:
SecurityAccess
• SecurityAccess
is
used
to
perform
sensi/ve
diagnos/c
ac/ons
(such
as
reprogramming
an
ECU)
– IDH: 07, IDL: 26, Len: 08, Data: 02 27 01 00 00 00 00 00
IDH: 07, IDL: 2E, Len: 08, Data: 05 67 01 54 61 B6 00 00
IDH: 07, IDL: 26, Len: 08, Data: 05 27 02 D0 B6 F1 00 00
IDH: 07, IDL: 2E, Len: 08, Data: 02 67 02 00 00 00 00 00
• Authen/ca/on
with
0726
(SJB)
– 27
01
=>
Request
Seed
• ECU
sends
back
OK
and
seed
(challenge)
• Programmer
sends
back
response
• ECU
Sends
back
OK
– 67
02
=>
OK
for
security
level
02

22. Services:
InputOuputControl
• Authorized
tools
to
control
or
monitor
external
inputs
to
the
ECU
(i.e.
do
stuff)
– IDH: 07, IDL: E0, Len: 08, Data: 06 2F 03 07 03 00 00 00
IDH: 07, IDL: E8, Len: 08, Data: 06 6F 03 07 03 36 90 00
• Send
inputOutputControl
test
to
07E0
– 2F
=>
ISO-­‐14229
code
for
inputOutputControl
– 03
07
=>
The
control
to
be
tested
– 03
00
00
=>
Data
provided
for
the
test

23. Some
other
interes/ng
PIDs
• ECUReset
• ReadMemoryByAddress
• Rou/neControl
• RequestDownload
• RequestUpload
• TransferData
• TesterPresent
• WriteMemoryByAddress

24. Systemic
Issues
• CAN
was
designed
decades
ago
without
security
in
mind
• CAN,
by
nature,
does
not
support
authoriza/on,
authen/ca/on,
or
encryp/on
• An
industry
relying
solely
on
entry
point
security
is
doomed
to
fail
• Although
aJack
data
will
vary,
methods
are
universal
across
make
and
manufacturer

25. CURRENT
ATTACKS

26. Injec/on
Limita/ons
• Not
all
func/ons
in
an
automobile
are
performed
over
CAN
(yet)
– Electric
ThroJle
in
Ford
Escape
• Original
vs.
Forged
Messages
– S/ll
have
legi/mate
coming
from
the
ECU,
forging
may
produce
varying
results
• Safety
features
might
need
bypassed
– Toyota
speed
limit
for
steering
during
IPAS

27. Speedometer:
Ford
• Set
the
speedometer
to
arbitrary
values
• CAN
ID:
0201
• Length:
08
• Format:
AA
BB
00
00
CC
DD
00
00
• Speed
=>
0.0065
*
(CC
DD)
–
67
• RPM
=>
0.25
*
(AA
BB)
–
24
• Example
(20.1mph
|
2233
rpm):
IDH: 02, IDL: 01, Len: 08, Data: 23 45 00 00 34 56 00 00

28. Speedometer:
Ford
II

29. *
Please
see
paper
for
packet
dissec/on
and
code.

30. Braking:
Toyota
II

31. Steering:
Toyota
II

32. Accelera/on:
Toyota
II

33. DIAGNOSTIC
CAN
INJECTION

34. SecurityAccess
• A
few
ECUs
from
each
car
responded
and
accepted
the
SecurityAccess
service
• For
these
ECUs
we’ve
figured
out
the
secrets
to
produce
valid
keys
from
the
seeds
provided
• This
permits
the
ECUs
to
be
put
in
reprogramming
mode
and
other
special
diagnos/c
states

35. SecurityAccess:
Ford
• PAM
doesn’t
send
random
seeds
• IDH: 07, IDL: 36, Len: 08, Data: 02 27 01 00 00 00 00 00
• IDH: 07, IDL: 3E, Len: 08, Data: 05 67 01 11 22 33 00 00
• IDH: 07, IDL: 36, Len: 08, Data: 05 27 02 CB BF 91 00 00
• IDH: 07, IDL: 3E, Len: 08, Data: 02 67 02 00 00 00 00 00
• Other
ECUs
do
send
random
seeds

36. Reversing
the
Ford
IDS
tool

37. Ford
Escape
keys
secret_keys = {
0x727: "50 C8 6A 49 F1",
0x733: "AA BB CC DD EE",
0x736: "08 30 61 55 AA",
0x737: "52 6F 77 61 6E",
0x760: "5B 41 74 65 7D",
0x765: "96 A2 3B 83 9B",
0x7a6: "50 C8 6A 49 F1",
0x7e0: "08 30 61 A4 C5",}
secret_keys2 = {
0x7e0: "44 49 4F 44 45",
0x737: "5A 89 E4 41 72”}

38. Academic
research
• securityAccess
to
ECU
then
diagnos/c
messages
using
the
‘DeviceControl’
Service

39. Kill
Engine:
Ford

40. Lights:
Toyota

41. Lights:
Ford

42. Horn:
Toyota

43. Seat
Belt:
Toyota

44. Doors
Lock/Unlock:
Toyota

45. Fuel
Gauge:
Toyota

46. Disable
brakes:
Ford

47. FIRMWARE

48. Dumping
firmware
Freescale
USB
S08/HCS12
BDM
Mul/link
In-­‐Circuit
Debugger/
Programmer
is
connected
to
the
BDM
header

49. Disassembling
target
processor
Motorola
HCS12X

50. Con/nued
access

51. SECURING
THE
MODERN
VEHICLE

52. There
are
a
few
strategies
• Secure
remote
endpoints
• Cryptographically
verify
messages
• Segment
CAN
network/isolate
ECUs
• Detect/prevent
aJacks
real-­‐/me

53. Industry
Statement
“Our
focus,
and
that
of
the
en/re
auto
industry,
is
to
prevent
hacking
into
a
vehicle's
by-­‐wire
control
system
from
a
remote/wireless
device
outside
of
the
vehicle.
Toyota
has
developed
very
strict
and
effec/ve
firewall
technology
against
such
remote
and
wireless
services.
We
con/nue
to
try
to
hack
our
systems
and
have
a
considerable
investment
in
state
of
the
art
electro-­‐magne/c
R&D
facili/es.
We
believe
our
systems
are
robust
and
secure.”
-­‐
John
Hanson
|
Toyota
Motor
Sales
U.S.A

54. External
Security
Dependencies
• Total
security
is
not
achievable
– Humans
make
mistakes
– We
haven’t
been
able
to
secure
PCs,
what
make
you
think
automo/ve
is
different?
– Enterprises
do
not
implement
a
single
/ered
approach
with
PCs,
why
should
automobiles?
– 3rd
party
assessment
appears
to
be
rare
– ECU
patching
for
known
vulnerabili/es
can
be
complicated
– Addi/onal
remote
aJack
vectors
being
added
each
year

55. Cryptography/Authen/ca/on
• Many
suggest
encryp/ng
applica/on-­‐layer
data
– Unfortunately
doesn’t
seem
viable
at
this
point
due
to
real-­‐/me
necessity
of
the
automo/ve
system
– Example:
The
brakes
have
to
work
in
real-­‐/me
and
can
NEVER
take
too
long
– Key
management
is
also
difficult
• If
its
in
the
ECU,
it
can
probably
be
reversed
– Reverse
Engineering
of
the
ECU/mechanics
tools
can
result
in
cryptography
being
subverted
– Should
not
rely
on
obscurity
to
protect
driver

56. More
on
obscurity
and
security
• "One
reason
for
the
industry's
success
in
preven4ng
bad
actors
from
doing
malicious
things
to
vehicles
is
that
individual
automakers
have
done
a
very
good
job
of
keeping
security
sensi4ve
informa4on
from
falling
into
the
wrong
hands,"
wrote
Mitch
Bainwol,
the
CEO
of
the
Alliance
of
Automobile
Manufacturers
and
Mike
Stanton
of
the
Associa/on
of
Global
Automakers
• If
the
only
thing
preven/ng
a
bad
guy
from
crashing
your
car
is
that
they
have
to
look
hard
for
the
info,
there
is
no
real
security

57. Segmenta/on
• Isolate
ECUs
on
different
CAN
buses
– Bridging
traffic
is
s/ll
necessary
• Example:
Infotainment
system
s/ll
needs
to
get
messages
about
speed
• Status
of
car
must
be
presented
on
instrument
cluster
– Bridge
must
NOT
forward
incorrect
traffic
– Bridge
is
now
the
weakest
link
/
aJack
target
– CAN
bridges
will
be
proprietary
in
nature,
forcing
them
to
be
updated
&
augmented
constantly

58. Detec/on
of
aJacks
• Don’t
exclusively
rely
on
making
aJacks
difficult,
instead
focus
on
detec/ng
aJacks
and
taking
ac/on
• Can’t
always
stop
aJack,
but
you
can
take
ac/on
when
one
is
happening
• Analogous
to
IDS/IPS
in
enterprise
environments

59. Advantages
• Vehicular
networks
are
especially
well
suited
for
aJack
detec/on
• CAN
messages
are
very
standard
and
predictable
• The
frequency
of
messages
and
their
content
vary
in
predictable
ways
• AJacks
stand
out
and
can
easily
be
detected

60. CAN
Traffic
is
Simple
• We
recorded
CAN
traffic
while
driving
around
for
15
minutes
• The
CAN
ID’s
found
in
the
first
second
of
the
trip
were
recorded
for
both
Ford
and
Toyota
• No
addi/onal
CAN
ID’s
were
found
the
rest
of
the
trip
• Any
addi/onal
CAN
ID’s
(such
as
diagnos/c
messages)
would
be
suspicious

61. Frequency
of
CAN
messages
• Frequency
of
messages
from
IDs
does
not
have
much
devia/on
• Comparison
of
messages
from
the
start
of
a
capture
and
in
random
loca/ons
within
the
same
capture
Hit
Counts:
Primary[03A9]
=>
9
|
Secondary[03A9]
=>
5
Hit
Counts:
Primary[0255]
=>
166
|
Secondary[0255]
=>
119
Hit
Counts:
Primary[0230]
=>
991
|
Secondary[0230]
=>
1011
Hit
Counts:
Primary[0250]
=>
168
|
Secondary[0250]
=>
209
Hit
Counts:
Primary[03C4]
=>
41
|
Secondary[03C4]
=>
46
Hit
Counts:
Primary[0340]
=>
80
|
Secondary[0340]
=>
82
Hit
Counts:
Primary[0422]
=>
83
|
Secondary[0422]
=>
36
Hit
Counts:
Primary[0423]
=>
17
|
Secondary[0423]
=>
6
Hit
Counts:
Primary[0420]
=>
83
|
Secondary[0420]
=>
47
Hit
Counts:
Primary[0200]
=>
496
|
Secondary[0200]
=>
630

62. Detec/ng
AJacks:
Normal
Packets
• Our
injec/on
aJacks
are
‘loud’
– Use
high
frequency
of
packets
to
ensure
that
it
out
numbers
legi/mate
traffic
• Example:
Sending
speed
packets
will
conflict
with
actual
speed
(in
MPH
and
frequency)
• Frequency
per
second
(we
send
about
20x
faster)
0
10
20
30
40
50
60
70
80
90
100
Frequency distribution of 0201 CAN id

63. Detec/ng
AJacks:
Diagnos/c
Messages
• Diagnos/c
packets
are
usually
performed
when
mechanics
are
performing
tests
– Not
while
car
is
moving
(or
at
least
driving
at
highway
speeds)
• Our
aJacks
based
on
this
would
easily
be
detected
• ALL
significant
aJacks
outlines
in
“Experimental
Security
Analysis
of
a
Modern
Automobile”
stem
from
diagnos/c
messages

64. Ac/ons
to
take
• Alert
driver
• Shut
down
CAN
network
(for
example,
short
CAN
Hi
to
CAN
Lo)
• Safely
stop
vehicle
• Poten/ally
ignore
certain
messages
for
a
period
of
/me
(if
not
cri/cal)

65. The
detec/on
code
• Add
an
IPS
ECU
to
each
CAN
network
• Add
code
to
exis/ng
ECUs
• Add
hardware
module
which
plugs
into
obdii
port

66. CONCLUSION

67. Conclusion
• AJacks
consist
of
two
sides:
compromise
&
control
• Vehicles
can
be
physically
controlled
via
the
CAN
bus
by
malicious
aJackers
• CAN
and
corresponding
architecture
were
NOT
designed
with
security
in
mind
• Relying
solely
on
external
input
security
is
imperfect
at
best
• A
layered
approach
to
security
is
beJer
(and
cheaper)
• Generically
detec/ng
&
protec/ng
the
vehicle
appears
to
be
the
most
effec/ve
method
for
automo/ve
safety

68. Ques/ons?
• Dr.
Charlie
Miller
(@0xcharlie)
– TwiJer
Guy
– cmiller@openrce.org
• Chris
Valasek
(@nudehaberdasher)
– Director
of
Security
Intelligence
@
IOAc/ve
– cvalasek@gmail.com