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

INTRODUCTION

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

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

ANATOMY
OF
AN
ATTACK

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

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

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

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)

ELECTRONIC CONTROL UNITS (ECUS)

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

ECU
Structure

Ford
PCM
Connector

Ford
PCM
ECU

CAN
BASICS

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

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

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…

STANDARDS
&
PROTOCOLS

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

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

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

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

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

CURRENT
ATTACKS

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

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

Speedometer:
Ford
II

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

Braking:
Toyota
II

Steering:
Toyota
II

Accelera/on:
Toyota
II

DIAGNOSTIC
CAN
INJECTION

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

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

Reversing the Ford IDS tool

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”}

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

Kill
Engine:
Ford

Lights:
Toyota

Lights:
Ford

Horn:
Toyota

Seat
Belt:
Toyota

Doors
Lock/Unlock:
Toyota

Fuel
Gauge:
Toyota

Disable
brakes:
Ford

FIRMWARE

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

Disassembling target processor Motorola
HCS12X

Con/nued
access

SECURING
THE
MODERN
VEHICLE

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

CONCLUSION

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

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