Presentation is loading. Please wait.

Presentation is loading. Please wait.

Comprehensive Experimental Analyses of Automotive Attack Surfaces

Similar presentations


Presentation on theme: "Comprehensive Experimental Analyses of Automotive Attack Surfaces"— Presentation transcript:

1 Comprehensive Experimental Analyses of Automotive Attack Surfaces
Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, and Stefan Savage University of California, San Diego Karl Koscher, Alexei Czeskis, Franziska Roesner, and Tadayoshi Kohno University of Washington Based on slides by Paul F. Roysdon This presentation is based on the slides from the 2012 presentation by these guys from UCSD and U-Dub I made several modifications to include the work from this groups papers through 2015.

2 Intro How many here own or drive a car?
How many of those are newer than 1996? How many believe that their car is secure? I would like to get some feedback from the class.

3 Abstract Modern automobiles are pervasively computerized.
Vulnerable to attacks. Internal networks within modern cars are insecure. Whether automobiles are susceptible to remote compromise. Broad range of attack vectors. Wireless communications channels usage. Structural characteristics of automotive system and practical challenges. There are 2 statements here The first is somewhat well known The second is really the focus of this presentation

4 Outline Paper (2012) and current works (thru 2015) Introduction
Threat Model Vehicle Attack Surface Vulnerability Analysis Indirect Physical Exploits Short-range Wireless Exploits Long-range Wireless Exploits Threat Motivation Fixes & Conclusion Paper (2012) and current works (thru 2015)

5 Introduction Modern cars controlled by complex distributed computing systems. Systems are controlled by 10s-100s of processors (called ECUs) ECUs : is a controller with responsibilities including braking, lighting, GPS, etc. Each ECU has multiple interfaces from different buses Millions of lines of code So, what new attacks are possible? Analysis of external attack vectors

6 Threat Model Technical (theoretical) Capabilities
Capabilities in analyzing the system and developing exploits Focuses on making technical capabilities realistic Operational (real-time) capabilities Provide and analysis of attack surface of vehicles Show how malicious payload is delivered Exploits Indirect physical access short-range wireless long-range wireless accesses Lets look at technical versus operational capabilities

7 Vehicle backbone Typical automotive electronics backbone is via a CAN-BUS Engine Transmission Instruments Locks Media system Etc.

8 Vehicle attack surface
OBD-II (On Board Diagnostics version 2) Connects to all key CAN buses of vehicle Used during vehicle maintenance Entertainment Disc USB iPod Now lets consider the attack surface First consider the physical access via 2 vectors

9 Vehicle attack surface
Short-range wireless access Bluetooth Remote Keyless Entry Tire Pressure (TPMS) Wifi Next consider short range remote access

10 Vehicle attack surface
Long-range wireless access GPS Satellite radio Remote Telematics Systems Finally consider long range remote access

11 Vehicle attack surface
Why are we considering these attack vectors. Well mostly because the cars today are comprised of critical components which were once mechanical and are now electrical Up-to the 1980s the cars were largely mechanical. Here is an example of a carburetor, which mixes the gas with air before going into the engine. A complex system of vacuum hoses, levers and valves controlled the fuel-to-air mixture so that the engine would operate properly. Too much fuel, and the engine cylinders will saturate and the engine will be “flooded”, no ignition. Too little fuel, and the engine will run hot, ultimately causing a melt-down. These systems require regular mechanical tuning! Require changes if you move to places with a higher elevation (air is thinner). Today, the engines use fuel-injectors, where a computer takes sensor measurements, calculates the proper fuel-to-air mixure and then meters the fuel at the engine cylinder head. Today

12 Vehicle attack surface
Now lets consider some of the attack vectors.

13 Vulnerability Analysis
Focused on moderately priced sedan with standard options and components Cars < 30 ECU’s comprising both critical drivetrain components & less critical components OBD-II PassThru device for ECU diagnosis and reprogramming Every vulnerability demonstrated allowed complete control of vehicle’s system General Procedure: Identify microprocessor (PowerPC, ARM, Super-H, etc) Extract firmware and reverse engineer using debugging devices or software like IDA Pro, or other custom tools. Exploit vulnerability or simply reprogram ECU How did the authors evaluate the problem?

14 Vulnerability Analysis – lab characterization
First, several ECU’s were removed from the car and evaluated on a bench

15 Vulnerability Analysis
Inject action Record response Characterize system On a bench the system could be characterized for vulnerabilities when physical access is possible. It also reveals remote vulnerabilities.

16 Exploitation Summary

17 Indirect physical exploits
Media Player Accepts compact discs and inputs from the microphone or two-way comm. system Software running on CPU handles audio parsing, UI functions, handles connections Two exploits .WMA audio file parser vulnerability Audio file parse/plays correctly on a PC While, in vehicle sends arbitrary CANBUS packets Update capability of the media player via remote access Updates when user does nothing/ not aware This is a particularly nice hack

18 Indirect & Direct physical exploits
OBD-II Looked at OBD-II PassThru devices from manufacturers Found no authentication for PC’s on same WiFi network using PassThru’s Found exploit allowing reprogramming of OBD-II PassThru Allows for PassThru worm Allows for full remote control of vehicle reprogramming Also are Linux-based and included unsecured and unused programs Now consider the device which connects to the OBD-II port, called a PassThru device. It is a common device, with common parts and software Neither are secure.

19 Indirect & Direct physical exploits
Service Center All service centers use Windows OS All PassThru’s designed for Windows Vulnerable to social networking Spread to all cars, not just one. How is the pass-through device vulnerability a problem? All automotive service centers use one. Compromise one PassThru, you can spread the attack to all Cars that they service. How can this be achieved? They all use Windows OS, specifically Windows XP. So through some clever social engineering, the attack can be mounted remotely.

20 Indirect & Direct physical exploits
Service Center All service centers use Windows OS All OBD-II designed for Windows OS Vulnerable to social networking Spread to all cars, not just one.

21 Direct physical exploits – method 1
Consider again direct physical attacks. In the case of Jeep, When performing a firmware update, the media center is looking for an ISO file with a particular name No checks are performed on the .ISO file, other than the name. Oh, and they run a version of Ubuntu. If you load a file via the USB with the right filename, then you can load any software you like.

22 Direct physical exploits – Off the shelf
Without expensive lab hardware, how hard is a physical attack Turns out it is quite easy. This OBD-II port scanner is just $15 on amazon And you connect right under the dashboard

23 Direct physical exploits – DIY
How about more sophisticated hardware A cheap DIY solution uses an Arduino and a CAN-BUS Arduino shield, roughly $40 More expensive than Amazon, but this is fully customizable.

24 Direct physical exploits – method 2
Here is another method. On a particular car, the media center run a full version of Ubuntu. To upload new firmware, it looked for a binary file ending with the ASCII character S No checksum No protections Just “S” So if we look at the binary file that the Auto Mechanic uses, does it have an “S” at the end?

25 Direct physical exploits – method 2
Yup, there it is!

26 Direct physical exploits – method 2
SSH anyone? Here is an example where the attacker just wanted to access the system via SSH. Is it possible?

27 Direct physical exploits – method 2
Yup! If you could SSH into the car, what else it possible. Could you, for example, manipulate the instrument display while the car is in park?

28 Direct physical exploits
Yup 140 MPH and the car is in Park Oh, and while your at it Why not display your own message! Pwned by CarShark.

29 Short-range wireless exploitation
Bluetooth: Found on most cars that the popular Bluetooth protocol stack was used with some custom manufacture code on top Custom code contained 20 unsafe calls to strcpy() Indirect attack  assumes attacker has paired device Implemented Trojan on Android device to compromise car Direct attack  exploits with a paired device Requires brute force of the PIN to pair device in 2012 took 10 hours (supposedly fixed for 2013 models) in 2015 took <1 minute Up till now we have looked at physical access to the car Now consider remote access. The attackers found a vulnerability in the Bluetooth system.

30 Long-range wireless exploitation
Cellular attack Telematics Software modem Voice channel (CDMA, …) Cell phone (3G) Now consider long range remote access Here are the sub-systems of the car that are readily available via a long range connection.

31 Long-range wireless exploitation
Call the car Play the file Mic listens for key tones CAN-BUS compromised

32 Long-range wireless exploitation
Call the car Play the file Mic listens for key tones CAN-BUS compromised

33 Long-range wireless exploitation
So what cars use this stuff? GM – On Star BMW - Connected Drive Ford – Sync And third-party systems like BlueLink

34 Long-range wireless exploitation
Telematics Connectivity: Similar to Bluetooth  Just a 3rd party device with manufacturer code on top Again found exploit in “Command” program for data transfer Though the program required an authentication code A bug that where “random” nonce is not so random A bug that allows authentication without correct response So what was found with remote access?

35 Long-range wireless exploitation via Smartphone
Here is an example of an app from the Android marketplace that they modified app with malicious code The result was full remote access via smartphone. Unlock the car Engine start (physical) Drive away

36 Long-range wireless exploitation via IRC server
What long range exploits are possible? Can we control multiple vehicles at the same time? Finally. Since we have seen that remote access is possible. What about controlling several cars from an IRC server? Well of course you can install an IRC server on the cars, where the cars were actually programmed to join the channel automatically.

37 Long-range wireless exploitation via IRC server
Yup. See that the authors cars joined while one located in Washington, and the other was in San Diego, California. This is more than 1500 miles apart! Then the author logs in, and has control.

38 Threat motivation Theft:
Scary version  mass attack cellular network creating vehicle botnet Able to have cars report VIN and GPS Can unlock doors and start the engine Cannot disable steering column lock (solved by simple manual attack) Surveillance: In-cabin microphone allows audio recording and transfer via the cellular connection. So what motivates remote access and how could it be used?

39 Security fixes Looked at easily available fixes to exploits:
Standard security engineering best-practices e.g. don’t use unsafe strcpy  instead strncpy Removing debugging and error symbols from code Limit ECU communication No inbound calls Restrict internet connections Use stack cookies and ASLR Remove unused Linux services (e.g. telnet and ftp) Use code guards Require authentication before re-flashing firmware What recommendation could be made?

40 2012 vs. now? Are cars getting more safe to cyber-physical attacks?
Reported findings to manufactures in 2012 Perform test on new cars and found Same attack vectors exist Some are now actually easier (faster) Increased automotive complexity provided additional attack vectors that did not exist in 2012. What recommendation could be made?

41 Conclusion Vulnerability causes (why is it not fixed?):
Lack of adversarial pressure Conflicting interests of ECU software manufacturers and automotive manufacturers Ex: Telematics, Bluetooth & Media Player made by individual 3rd party suppliers. Lack of software testing at the system/assembly level Lack of penetration testing at all levels Why have the auto manufactures not fixed these issues earlier?

42


Download ppt "Comprehensive Experimental Analyses of Automotive Attack Surfaces"

Similar presentations


Ads by Google