the current state of automotive security by chris valasek
DESCRIPTION
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.TRANSCRIPT
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 – [email protected]
• Chris Valasek (@nudehaberdasher) – Director of Security Intelligence @ IOAc/ve – [email protected]