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?