Attack Surface and Vulnerability Assessment of

Automotive Electronic Control Units

Martin Salfer and Claudia Eckert

Technische Universit

at M

unchen, M

unchen, Germany

Keywords:

Security Metrics, Embedded Systems, Cyber-Physical Systems, Exploit Engineering Cost Assessment.

Abstract:

Modern vehicles are controlled by an on-board network of ECUs (Electronic Control Units), which are spe-

cially designed computers that contain tightly tailored and customized software. Especially the trends for ECU

connectivity and for semi-autonomous driver assistance functions may have an impact on passenger safety and

require thorough security assessments, yet the ECU divergence strains those assessments. We therefore pro-

pose an easily automated, quantitative, probabilistic method and metric based on ECU development data and

software ﬂash images for the attack surface and vulnerability assessment automation. Our method and metric

is designed for the integration into an (iterative) engineering process and the facilitation of code reviews and

other security assessments, such as penetration tests. The automotive attack surface comprises especially in-

ternal communication interfaces, including diagnosis protocols, external and user-accessible interfaces, such

as USB sockets, as well as low-level hardware interfaces. Some exemplary indicators for the vulnerability are

access restrictions, casing tamper-resistance, code size, previously found vulnerabilities; strictness of compil-

ers, frameworks and application binary interfaces; conducted security audits and deployed exploit mitigation

techniques. This paper’s main contributions are I) a method and a metric for collecting attack surface and pre-

dicting the engineering effort for a code injection exploit from ECU development data and II) an application

of our metric and method into our graph-based security assessment.

1 INTRODUCTION

The automotive industry drives ECU (Electronic Con-

trol Unit) consolidation and connectivity for eco-

nomic, functional and environmental reasons. Yet,

the complexity of deep integration and internetwork-

ing also brings hardly foreseeable security implica-

tions. Some were revealed by practical attack stud-

ies, e.g., (Koscher et al., 2010; Checkoway et al.,

2011). Security researchers demand more objective

security engineering instead of mere expert intuition

(Schneier, 2012). The German National Road Map

for Embedded Systems explicitly demands reliable,

quantiﬁed security statements for embedded systems

(Damm et al., 2010).

A vehicle’s attack surface increases due to the

internetworking of control units with the environ-

ment and due to the integration of abundant services

and functionality, e.g., for highly automated driving.

The attack motivation rises due to asset accumula-

tion: A common car will bear payment credentials for

tolling, parking and electric charging and have access

to cloud services, including sensitive and personal

data.Security ﬁxes are rather expensive to create and

to deploy for the automotive industry, even compared

to enterprise systems: Every change requires thor-

ough and lengthy testing for guaranteed side-effect

free safety quality. A vehicle’s life cycle spans over

more than a decade, which makes security support ex-

tra costly. Hence, the automotive industry invests in

comprehensive engineering and security assessments

with a long-term foresight. One method is the assess-

ment of an ECU’s attack surface. A high grade of au-

tomation and efﬁciency is necessary for handling the

many, deeply customized automotive ECUs. “There

is a pressing need for practical security metrics and

measurements today” (Manadhata and Wing, 2011).

Data collection for security analysis is a tedious

task, which could be facilitated greatly by automa-

tion. Yet, typical corporate IT (Information Technol-

ogy) data collection software and methods are not ap-

plicable for automotive IT or CPSs (Cyber-Physical

Systems). ECUs/CPSs usually communicate hetero-

geneously and combine a large, fast-changing and ob-

scure variety of real-time and general-purpose oper-

ating systems, application binary interfaces and ﬁle

Salfer M. and Eckert C.

Attack Surface and Vulnerability Assessment of Automotive Electronic Control Units.

DOI: 10.5220/0005550003170326

In Proceedings of the 12th International Conference on Security and Cryptography (SECRYPT 2015), pages 317-326

ISBN: 978-989-758-117-5

317

systems for the sake of maximum dependability and

efﬁciency and thus sustainability. While corporate IT

usually communicates homogeneously with IP (In-

ternet Protocol), automotive IT communicates with

a combination of CAN (Controller Area Network),

MOST (Media Oriented Systems Transport), LIN

(Local Interconnect Network), FlexRay, ByteFlight,

BroadR-Reach, etc. While corporate IT usually op-

erates homogeneously on x86 with POSIX-(Portable

Operating System Interface)-compliant operating sys-

tems, automotive IT operates on TriCore, Super-H,

PowerPC, V850, x86, ARM, etc. with OSEK (Of-

fene Systeme und deren Schnittstellen f

ur die Elek-

tronik im Kraftfahrzeug) / VDX-(Vehicle Distributed

Executive)-, AUTOSAR-(AUTomotive Open System

ARchitecture)-, sometimes POSIX-compliant operat-

ing systems or even merely on bare metal. Online

data collection methods can therefore hardly cover all

available security measures that are integrated into au-

tomotive systems.

This paper focuses on the threat of injecting mali-

cious code using vulnerabilities of the actual imple-

mentation. Malicious code injection is one of the

most subtle and critical threats as it potentially en-

dangers all three main security goals at once: conﬁ-

dentiality, integrity and availability. A general secu-

rity assessment has to, of course, also consider other

threats, including the misuse of valid communication.

This paper presents a method for assessing the at-

tack surface and vulnerability likelihood for individ-

ual ECUs. However, it does not cover implications

of the on-board network architecture or the attractive-

ness of individual ECUs or functions for an attacker.

Our research on the complexity problem of compre-

hensive and reliable security assessments of an auto-

motive on-board network inspired us for this paper.

The contributions of this paper are:

I. We formalized a method and a metric based on

development data for systematically assessing the

attack surface and attacker effort for automotive

ECUs. The method and metric arose in coopera-

tion with automotive OEM security experts and is

designed for a seamless integration into a graph-

based on-board network security assessment.

II. We applied and integrated the method and met-

ric in our attack graph-based assessment and show

exemplary results.

Section 2 deﬁnes, describes and discusses our

method. Section 3 shows an application of our

method on a complete on-board network with an at-

tack graph construction algorithm. Section 4 gives

an overview over related work. Section 5 discusses

ideas for optimizing this assessment. And Section 6

concludes our automotive attack surface and vulnera-

bility assessment method.

2 METHOD

This section introduces a systematic approach for as-

sessing the attack surface and vulnerability of an auto-

motive ECU. The anticipated threat is the injection of

malicious code. We will systematically walk through

our method with the following steps or subsections.

1. Attack Surface Collection – How much and what

attack surface bears an ECU? An ECU can only be

exploited if it bears interfaces to the outside. We

collect accessibility information mainly by sourc-

ing different documents and databases.

2. Vulnerability Prediction – How likely is attack

surface vulnerable?

3. Vulnerability Finding Effort– How much effort is

presumably necessary to ﬁnd a vulnerability on

the attack surface?

4. Exploit Creation Effort – How much effort would

a potential vulnerability consume, considering the

effort for accessing the attack surface, engineering

a basic exploit against it and ﬁnally counteracting

possibly deployed exploit mitigation techniques?

2.1 Attack Surface Collection

The ﬁrst step for the attack surface estimation is the

collection of the attack surface. The attack surface is

the sum of interaction opportunities with an ECU, i.e.,

everything that can potentially inﬂuence the control

ﬂow of the software. Such attack surface is typically

incoming data that is parsed and processed. Incoming

data can be found by monitoring the interfaces of an

ECU in use or by evaluating speciﬁcation documents,

binary or source code. The attack surface comprises a

set of accessible services and inbound communication

as well as the system’s I/O and hardware interfaces.

Each software consists of program code and pro-

vides services. Each of these services could be poten-

tially abused for injecting code. An ECU’s “attack-

ability” correlates positively with its attack surface,

i.e., the more accessible a service is, the easier it is to

attack. Attack surface is obligatory for any attack. All

attack surfaces are treated as complementary, i.e., one

surface must be considered isolated from other attack

surface. Attack surfaces are not mentioned compre-

hensively as an attacker with enough creativity can re-

veal new, unlisted surface, so a residue called Others

will always exist. Specialized ECUs can have extra

SECRYPT 2015 - International Conference on Security and Cryptography

318

features and therefore attack surface not mentioned

here or not yet introduced into mass market ECUs.

We classify an ECU’s attack surface as below or

as seen in Figure 1.

• Incoming Data is any data arriving at an ECU.

– Job Parameters are input ﬁelds in ECU jobs.

Jobs are services that can be called via the

on-board network and are useful for mainte-

nance and diagnosis. Access to a subset of

jobs (and therefore to the on-board network) is

legally obligatory over the OBD-II (On-Board

Diagnostics) port and therefore represents at-

tack surface prescribed in all cars by law.

– User Input is data supplied directly by the user,

e.g., ﬁles, streams or user interface input.

– Signals are routinely received data chunks on

an on-board network for regular operation, e.g.,

wiper commands or speed information.

– Meta Data represents any supplementary data,

which could inﬂuence parsers or drivers, e.g.,

CAN or ethernet frame IDs.

• Apps are third party-supplied software packets.

• Reﬂash Routines are ways for replacing an ECU’s

software with a supplied ﬂash image.

• Hardware Attack Surface Spots are spots that can

be tampered with only with physical access.

– Boot Memory comprises any storage that could

allow execution of attacker supplied code,

e.g., an EEPROM (Electrically Erasable Pro-

grammable Read-Only Memory) or external

ﬂash memory.

– Debug Interfaces are any ports that are not used

in regular operation or maintenance, but were

used during development and might be used

again for advanced maintenance, e.g., JTAG

(Joint Test Action Group) interface. Debug in-

terfaces intentionally allow very deep analysis

and manipulation.

– Inter-Chip Communication Channels are any

data exchange links inside an ECU (usually

in between semiconductors) that could be re-

vealed and tampered with, e.g., UART (Univer-

sal Asynchronous Receiver/Transmitter), I2C

(Inter-Integrated Circuit) and SPI (Serial Pe-

ripheral Interface). Such interfaces could be re-

vealed and tampered with.

– A Side Channel Attack is measuring or ma-

nipulating an ECU physically for information

gathering or control ﬂow change, e.g., power

glitches or laser pulses can jump the program

counter or let operations silently fail.

• Other represents any other not explicitly men-

tioned attack surface. This listing is not exhaus-

tive and is subject to continuous extension.

class AttackSurface Taxonomy

Node

System Model::ECU

AttackSurface Spot

Incoming Data HW SpotReflash

Job Parameter

User Input

Apps

Signals

Meta Data

Boot Mem

Debug Interface

IC Communication

Side Channel Attack

Other

+attackSurface

Figure 1: Attack Surface Taxonomy – ECUs bears attack

surface that can be divided into Attack Surface Spots of ei-

ther Incoming Data, installed Apps, a Reﬂash mechanism,

HW Spots or any Other, yet to be found, attack surface.

Cars often also have a single exposed ECU for com-

munication and have Bluetooth, Wi-Fi, RDS (Radio

Data System), TMC (Trafﬁc Message Channel), DAB

(Digital Audio Broadcasting), GSM (Groupe Sp

ecial

Mobile), CDMA (Code Division Multiple Access),

UMTS (Universal Mobile Telecommunications Sys-

tem), LTE (Long Term Evolution), GPS (Global Po-

sitioning System) and other antennas and services

that count to their externally accessibly attack surface.

Some ECUs may also have 802.11p (vehicular WiFi)

for ITS (Intelligent Transportation System) support.

Typical ECUs are equipped with intra-vehicular com-

munication. Some may use radio communication for

internal communication, e.g., for comfort access ra-

dio keys or tire pressure control radio sensors on the

TPMS (Tire Pressure Monitoring System). These at-

tack surfaces are real, but are atypical for an ECU, i.e.,

only one ECU out of about 50 has such an feature and

attack surface. Previous publications named already

many attack spots: from tire pressure monitoring sen-

sors up to Bluetooth and music CDs (Francillon et al.,

2010; Ishtiaq Rouf et al., 2010; Koscher et al., 2010;

Checkoway et al., 2011).

Attack Surface and Vulnerability Assessment of Automotive Electronic Control Units

319

2.2 Vulnerability Prediction of the

Attack Surface

Attack surface per se is only vulnerable if there is an

exposed, security-relevant defect. If we cannot asses

the isolated attack surface by itself that is responsi-

ble for a certain attack surface, someone can still ap-

proximate by assessing the overall software of an en-

tire ECU. We can estimate a surface’s vulnerability by

looking at the ECU’s vulnerability density v, which is

the number of security relevant defects per ECU code

size, i.e.,

v =

“security relevant defects”

“code size”

. (1)

A typical code size unit is the number of statements.

Any vulnerability originates from either accident (un-

intentional software defects) or a backdoor (inten-

tional software defects). A backdoor can be either

maliciously for later exploitation or benign for later

maintenance. So the vulnerability density sums up

the number of intentional and unintentional vulnera-

bilities. For automotive applications, we assume the

density of intentional vulnerabilities (backdoors) be-

ing insigniﬁcant compared to the density of uninten-

tional defects. The neglect of intentional vulnerabil-

ities seems true even for most open source products

as vulnerability advisories are to be found often and

back-door warnings are to be rarely found. We there-

fore approximate the vulnerability density by the den-

sity of unintentional vulnerabilities.

Quantifying the vulnerability density directly

from code is hard as it is not decidable for a ma-

chine whether a control ﬂow change was intended or

not.But the vulnerability density v can be approxi-

mated by the software’s defect rate d. The vulnera-

bility density correlates strongly with the defect den-

sity as carefully designed and implemented code typ-

ically contains less vulnerabilities. The better soft-

ware quality, the less defects and the less vulnerabili-

ties. We approximate the vulnerability density v from

a software’s defect density d (or fault density) as sta-

tistical analysis in (Alhazmi et al., 2005) shows that

usually 1 % to 5 % of all defects are security relevant

defects, i.e.,

v ≈ x ∗ d with x = [0.01, 0.05]. (2)

One way to obtain defect density values straight for-

ward is deriving those from process metrics, e.g., bug

tracker statistics. A approximation can be done as-

suming x = 0.03, the middle of Alhazmi’s found se-

curity relevance rate, and d = 0.001 for mature and

secure software in the productive phase:

v ≈ 0.001 ∗ 0.03 = 0.00003. (3)

Typical indicators for an ECU’s individual defect den-

sity are mentioned below.

• The number of previously found defects and the

code size of similar ECUs are an approximation

basis for the expected defect density.

• The ASIL (Automotive Safety Integrity Level) is an

indicator for thoroughly checked code and there-

fore a lower expectation for defects.

• Safety measures avoid any defects and raise soft-

ware quality, e.g., strict type checking, assertions,

boundary checking and input sanitation.

• A conducted code audit is an indicator for a lower

defect density expectancy as a check by several

people ensures a higher code quality.

• A conducted penetration test is an indicator for a

lower defect density as such tests reveal defects

before a release and allow efﬁcient hardening.

The likelihood for the existence of a vulnerability can

be modelled with a Bernoulli process P

(X > 0) with

being a Bernoulli process distribution function, X

being the number of vulnerabilities, q being the prob-

ability of a single attack surface spot of being free

from vulnerabilities, v being the vulnerability density,

and i the number of available Attack Surface Spots,

and x the average code size of the attack surface spots:

(X > 0) = 1 − P

(X = 0) = 1 − q

= 1 − (1 − v)

(4)

Assuming an ECU would have about 200 attack sur-

face spots with an average code size of 5 lines, the

ECU’s likelihood for a vulnerability is according to a

Bernoulli process about

(X > 0) = 1 − (1 − 0.00003)

200∗5

≈ 3%. (5)

2.3 Vulnerability Finding Effort

Estimation

An attacker has to search on the attack surface for

vulnerabilities, before being able to exploit it. One

method to reveal exposed vulnerabilities is fuzz test-

ing, also called fuzzing. Fuzzing stimulates existing

attack-surface with intentionally modiﬁed payload in

order to trigger malfunction. Seeing a certain reac-

tion, the attacker can try exploiting the reaction for

malicious code execution. Another way is binary

analysis, i.e., inspecting the ﬁrmware code for iden-

tifying input channels and its data processing directly

in the code. Any method requires an initial set-up ef-

fort; A fuzzing set-up requires a functional ECU with

equipment to modify input data and a good under-

standing of used protocols. The analysis of binary

SECRYPT 2015 - International Conference on Security and Cryptography

320

code requires an extraction of the ﬁrmware. Subse-

quently, all of the attack surface needs to be checked.

We assume an attacker to only search as long for a

vulnerable attack surface until one is found. With our

above assumption of a vulnerability density v, we can

assess the success likelihood of an attacker.

We deﬁne the vulnerability ﬁnding effort f as the

sum of both the initial effort f

and the sum of all

individual attack surface probing efforts f

from with

n attack surface spots, i.e.,

f = f

i=n

∑

i=1

( f

). (6)

Alternatively, the vulnerability ﬁnding effort can also

be estimated by the expected number of vulnerability

ﬁnding tries ¯n multiplied with the average vulnerabil-

ity ﬁnding effort

, i.e.,

f = f

+ ¯n ∗

. (7)

The expected number of vulnerability ﬁnding tries ¯n

can be derived from the stochastic expected value of

a Bernoulli process P

. The special case compared to

standard Bernoulli processes is that the process ends

as soon as the ﬁrst success has occurred, i.e., ”vulner-

ability found”. The possible outcomes therefore are

in Table 1.

Table 1: Bernoulli Tries and Results.

Tries Results

0 -

1 1

2 01

3 001

... ...

n 0...01

n 0...00

The expected value ¯n for the number of tries in such a

Bernoulli process P

with success probability p, fail-

ure probability q, stochastic random variable X for the

number of successes and a maximum number of tries

k (equalling the number of attack surface spots to test

for vulnerabilities) can therefore be computed with

¯n = 0 +

i=k

∑

i=1



i ∗ q

i−1

∗ p



+ k ∗ P

(X = 0). (8)

With some simpliﬁcation and replacing the p and q

(how they are usually called in stochastic literature)

with v and (1 − v) as we use it, the expected number

¯n of tries till a vulnerability is found can be computed

with

¯n = v

i=k

∑

i=1



i(1 −v)

i−1



+ k (1 − v)

. (9)

The expected value for the ﬁnding effort

f in combi-

nation with an assumption about the average individ-

ual ﬁnding effort value

therefore is

f = f

i=k

∑

i=1



i(1 −v)

i−1



+ k (1 − v)

. (10)

2.4 Attack Surface Exploitation Effort

The exploitability of a vulnerability of given attack

surface depends on various factors such as the pro-

cessor architecture, compilers, input parser types and

exploit mitigation techniques. We also consider the

use of authenticated functions, so that additional ef-

fort is necessary to access and subsequently exploit

vulnerabilities of attack surface. The effort we try to

estimate is on ﬁnding and exploiting then unknown

(”zero day”) vulnerabilities. As soon as details of vul-

nerabilities or the assessed platform are published, the

effort drops. We systematically walk through an as-

sessment method for an ECU with the following steps

or subsections.

1. Preliminaries – An attacker proﬁle needs to be de-

ﬁned to be referenced to for a homogeneous attack

effort quantiﬁcation.

2. Access Effort – Attack surface can require effort

for overcoming software-based access or authen-

tication checks or protective hardware means.

3. Basic Exploitation Effort – Attack surface spots

require different basic techniques and thus effort.

4. Counter Exploit Mitigation Effort – Even vulnera-

ble attack surface can be inherently robust against

exploitation due to exploit mitigation techniques,

e.g., stack canaries.

2.4.1 Preliminaries – Reference Attacker Proﬁle

Deﬁnition and Quantiﬁcation Units

For estimating all attacker efforts quantitatively, we

need to deﬁne an Attacker Proﬁle as a reference.

Our Attacker Proﬁle represents a human attacker with

economic reasoning. Having a reference Attacker

Proﬁle will allow us later to easily transpose an as-

sessment onto a different Attacker Proﬁle. Capabil-

ities represent an attacker’s knowledge, techniques

and tools relevant for exploiting vulnerabilities. Each

Capability is proportionally weighted with a ﬂoating

point number x ∈ R

as a Grade. It rates an At-

tacker Proﬁle’s Capability in comparison to the cor-

responding Capability of the reference Attacker Pro-

ﬁle. The reference Attacker Proﬁle Grades therefore

Attack Surface and Vulnerability Assessment of Automotive Electronic Control Units

321

are always deﬁned as 1. The Grade deﬁnitions al-

low a directly proportional effort estimation for re-

lated Attacker Proﬁles. The Attacker Proﬁle Capabil-

ities can be arbitrarily deﬁned, yet this deﬁnition must

be constant throughout an entire security assessment

for comparability and must be precisely known to the

ones who deﬁne further Attacker Proﬁles and to the

ones who assess elementary exploit efforts. There-

fore, a reference attacker proﬁle has to be documented

and all later steps must be able to refer to the initially

deﬁned reference attacker. One exemplary inspiration

for an Attacker Proﬁle is an informatics study pro-

gram curriculum due to the familiarity and the global

standardization for a well understood Attacker Pro-

ﬁle.A formal deﬁnition of an Attacker Proﬁle can be

seen in Figure 2.

class Attacker Profile (SECRYPT)

Attacker Profile Grade

Capability

* 1

Figure 2: Attacker Proﬁle – Our Attacker Proﬁle represents

human attackers with economic reasoning. Each Capability

yields a Grade quantiﬁer, i.e., how skilled or well equipped

an attacker is.

We deﬁne the effort e as a tuple of a capabil-

ity tag t and its corresponding effort amount r, i.e.,

e ∈ E = {(t, r)|t ∈ T ∧r ∈ R}. The effort amount r ∈ R

is deﬁned here as the set of positive real numbers, i.e.,

R = R

, and represents a currency value for com-

parability reasons. Typical effort measurements are

consumed time or money. Some vehicle insurances

research institutes measure effort in amount of time

required (for a reference attacker proﬁle) and demand

cars being secure enough in terms of minimum time

effort required. Even though values can not be pre-

cise, we prefer using a currency unit as these allow

a more versatile comparison. A currency effort can

be compared with man-hour estimates with the help

of a reference Attacker Proﬁle including a well de-

ﬁned capabilities set, and a currency effort can also

be compared with labour and black market prices for

vulnerabilities. Capability tags t ∈ T can be mapped

on the capabilities of attacker proﬁles.

2.4.2 Access Effort

Attack surface differs in accessibility, i.e., different

access surface requires different effort for reaching it.

We deﬁne an attack surface’s access effort as a ∈ E.

The access effort determines how much to spend for

overcoming access restrictions.

Software security means for protecting or unlock-

ing attack surface are credential checks or ﬁrewall

rules. Authorization functions often challenge the

client with a code that has to be answered with the

correct response code. OEMs (Original Equipment

Manufacturer) put different effort in securing the au-

thentication. Depending on the used cryptographic al-

gorithms and key strengths, the access factor a varies

greatly. An ECU will always have at least some

(publicly) accessible attack surface as the authentica-

tion routine represents attack surface by itself. Soft-

ware unlocking of attack surface can occur by many

ways, e.g., snooping or brute-forcing a key or gaining

knowledge about it from social engineering. Sensitive

jobs (including the reﬂash mechanism) are secured

with a 16 bit key challenge-response authentication

and a 10 s retry blocker, as discovered by (Koscher

et al., 2010). Such an ECU can be brute forced within

15 days; Power cycling can reset the retry blocker and

speed up the brute force to reveal one key within 1.5

days.The reﬂash routine is usually strongly protected

due to its sensitivity and therefore bears a high ac-

cess effort a and differs starkly with the used crypto-

graphic algorithms and key size. The signal param-

eters are received without authentication over CAN;

The signals’ access effort is a

signals

Hardware means for protecting attack surface are,

for example, resistive covers and being installed in

hardly accessible space. If an ECU is integrated in

a hardly accessible installation space, an attacker has

to remove many parts and therefore invest much effort

into accessing the ECU eventually. Resistive Covers

help in blocking access to internal ports, especially

development or debug ports, or to parts that contain an

ECU’s ﬁrmware. Chips can have cryptographic fea-

tures for protecting inter-chip communication or cryp-

tographically check the ﬁrmware image. Hardware-

based attack surface protection can also be supported

by software means; For example, certain side-channel

attacks can be rendered ineffective by special soft-

ware obfuscation techniques.

2.4.3 Basic Exploitation Effort

Vulnerable attack surface requires at least a min-

imum effort for injecting code, which we call the

basic exploitation effort b ∈ E. The effort differs

starkly, because ECUs are designed and built with

such different fundamental hard- and software.

Some hard- and software implicitly and carefully

checks all incoming or used data, some other hard-

and software uses incoming data naively. Whilst

some ECUs are programmed with automatically

input checking programming languages like Java

(or certain ASCET compilers), many ECUs are

directly programmed in C/C++, which does not

automatically check buffer boundaries and hence

SECRYPT 2015 - International Conference on Security and Cryptography

322

is more prone to buffer overﬂows

. Depending on the

input’s data type, a vulnerability is harder or easier

to exploit for malicious code execution. Buffer over-

ﬂows typically allow a direct injection of code and

often an indirect manipulation of the CPU’s (Central

Processing Unit’s) program counter. Besides the pop-

ularity and the practicality of buffer overﬂow attacks,

any input (also primitive input) can cause code to re-

act unintentionally, albeit much harder to inject and

run code. We deﬁne four classes of input data regard-

ing the expected exploitation effort.

• Unchecked complex types are rather easy to ex-

ploit, e.g., strings/arrays or any buffered data on

C/C++. We deﬁne the basic exploitation effort for

unchecked complex types as b

• Checked complex or primitive types are rather

hard to exploit, e.g., a single int, bool and ﬂoat

in C/C++/Java or strings/arrays in Java. Checked

complex types are immune to typical buffer over-

ﬂow attacks, but can still provoke unintentional

code behaviour similar to single primitive types.

We deﬁne the basic exploitation effort for checked

complex or primitive types as b

• Unprivileged code is input that will be executed

with few permissions, e.g., apps.

• Privileged code is input that will be executed with

full permissions, e.g., ﬁrmware.

The classiﬁcation will be relevant for possible exploit

mitigation techniques.

2.4.4 Exploit Mitigation Counter Effort

A vulnerable and accessible attack surface can be

non-exploitable due to explicit and implicit exploit

mitigation techniques. Exploit mitigation techniques

do by deﬁnition never avoid the exploitation entirely,

but raise the effort for making an exploit that is able

to successfully execute injected code. Some exploit

mitigation techniques found in state of the art ECUs

are described below.

• Stack canaries: Stack canaries are extra vari-

ables on the stack that are checked before criti-

cal actions, such as loading the program counter

with the return address. A simple buffer overﬂow

would overwrite (and usually invalidate) the stack

canary, too. Certain implementations even allow

sidestepping stack canaries by manipulating the

exception handler. We deﬁne the exploit mitiga-

tion counter effort against stack canaries as c

C/C++ is still often used, e.g., for time critical deter-

ministic behaviour. Many safety veriﬁcation and certiﬁca-

tion tools and methods exist for C/C++.

• NX (No eXecute bit): Memory can be marked

as non-executable (also called “modiﬁed Harvard

Architecture”), so injected code cannot be exe-

cuted. We deﬁne an attacker’s extra exploit effort

for counteracting NX as c

• ASLR (Address Space Layout Randomization):

Memory addresses can be randomized, so attack-

ers cannot easily predict addresses and exploit

code might fail. We deﬁne the exploit mitigation

counter effort against ASLR as c

• MPU/MMU/PS (Memory Protection Unit / Mem-

ory Management Unit / Privilege Separation):

Most ECUs have processors that watch memory

accesses and have operating systems that subdi-

vide code into isolated processes, so a successful

attacker cannot access the whole ECU. Once in-

side a running process, there is a lot more of at-

tack surface to interact with. This depends not

only on the software compilation and operating

system, but also on the processor security archi-

tecture behind the application binary interface as

certain ones have a ﬁne grained permission sys-

tem. We deﬁne the effort for counteracting any

memory and privilege separation as c

• Other: New exploit mitigation techniques are

already researched on, e.g., control ﬂow graph

checking, see (Kayaalp et al., 2014).

The reﬂash routine cannot be protected by exploit mit-

igation techniques as ﬁrmware has to be per se exe-

cutable and highly privileged, i.e., c =

We deﬁne the extra exploit creation effort that

is necessary due to exploit mitigation techniques as

c. Exploits on complex and primitive input types

can be counteracted with all mentioned techniques,

i.e., c ∈ (c

∪ c

). Malicious apps can only

be counteracted with privilege separation techniques,

i.e., c ∈ c

. And injected malicious privileged code

can not be counteracted, i.e., c =

2.5 Attack Surface Summary

We conclude the method and metric with summariz-

ing the formulae above. An ECU’s vulnerability can

be modelled as seen in Section 2.2 with

(X > 0) = 1 − (1 − v)

. (11)

The expected ﬁnding effort

f can be computed as seen

in Section 2.3 with

f = f

i=k

∑

i=1



i(1 − v)

i−1



+ k (1 − v)

. (12)

A reﬂash routine can still be well protected by strong

cryptographic authentication, which implies a high access

effort a.

Attack Surface and Vulnerability Assessment of Automotive Electronic Control Units

323

The expected effort ¯g for creating a software exploit is

the sum of the expected access effort ¯a, the expected

basic effort

b and the expected countermeasure mit-

igation effort ¯c as seen in Section 2.4 and combined

¯g = ¯a +

b + ¯c. (13)

Finally, the expected overall ECU exploitation value

¯o is

¯o =

f + ¯g. (14)

3 APPLICATION IN ATTACK

GRAPH CONSTRUCTION

The presented method and metric are designed for and

integrated into our attack graph generation for vehicu-

lar on-board networks. Attack graphs are a well estab-

lished security engineering method, but the plethora

of attack combinations makes manual construction

cumbersome and likely to miss relevant attack paths.

The automatic inclusion and assessment of the attack

surface and vulnerability based on development data

raises the accuracy of constructed attack graphs and

helps keeping attack graph-based security analyses

viable. A missing attack vector might enable extra,

unseen attack paths that drastically facilitate compro-

mising a security goal. Security experts can enrich

and override automatically compiled information for

better soundness; certain factors are better judged by

humans, e.g., trending attack vectors or the level of

publicly available information on given control units

or software components. The attack graph algorithm

eventually constructs attack graphs with given and

harvested information and will show most likely at-

tack paths; see a run-time example in Figure 3.

Figure 3: Automated Attack Graph Construction – The inte-

gration of our metric and method into our graph-based secu-

rity analysis facilitates the automatic construction of attack

graphs from development data.

We have applied the method and metric of this pa-

per together with our attack tree construction algo-

rithm onto an ECU network and depicted the result-

ing, simpliﬁed, altered and anonymized attack tree in

Figure 4.

AttackerAccess

ECU B

ECU D

ECU F

ECU C

ECU E

ECU A

„Jeder kann das wofür er sich Zeit nimmt es zu verstehen“ – MarS

Figure 4: Resulting Attack Tree – The depicted attack graph

is a simpliﬁed, altered and anonymized assessment result

of a modern vehicle’s ECU network, based on this paper’s

method. The AttackerAccess is the deﬁned access point for

an attacker into the vehicle. ECU A through ECU F are

ECUs. Arrows represent potential attack surface exploita-

tions that are most likely to happen according to the assess-

ment. A1 through A6 are assets that an attacker targets.

4 RELATED WORK

Howard et al. started in 2003 identifying Windows

services and sockets as well as similar constructs as

attacker entry points and weighted them according

to their (system or user) privilege and evaluated his

method on several Windows versions, as can be seen

in (Howard et al., 2005). Manadhata and Wing for-

malized an attack surface metric for software source

code in (Manadhata and Wing, 2011). They measure

the attack surface of three classes: methods, chan-

nels and ﬁles. A typical ECU does not have TCP

(Transmission Control Protocol), SSL (Secure Sock-

ets Layer), TLS (Transport Layer Security) or UNIX

socket channels, so the channel attack surface is 0.

The ﬁle system of an ECU is typically not accessible,

SECRYPT 2015 - International Conference on Security and Cryptography

324

so the ﬁle attack surface is 0, too. Yet, their attack

surface metric is made under the premiss of having

access to source code, which we do not have unfor-

tunately. Our metric instead is designed for the outer

attack surface of an ECU, where an attacker can only

judge from available visible surface such as commu-

nication interfaces and ﬁrmware code.

Miller and Valasek assessed the attack surface of

a couple more cars from publicly available sources

by enumerating mentioned features and giving a sub-

jective rating for the criteria outer accessibility, net-

work separation and incorporated features in (Charlie

Miller and Chris Valasek, 2014).

The CVSS (Common Vulnerability Scoring Sys-

tem) quantiﬁes how severe a vulnerability is with a

base, temporal and environmental metric set. Each

criteria is value that can be selected from an array of

3 to 5 numbers according to the verbally given sever-

ity. CVSS works only for scoring already existing and

found vulnerabilities, yet it cannot assess prospective

vulnerability.

Vulnerability databases allow to directly reason

about a system’s vulnerability in case of a positive

ﬁnding. Rich research projects and results exists for

corporate IT systems, e.g., (Roschke et al., 2009)

at the HPI (Hasso-Plattner-Institut) worked on uni-

fying vulnerability information as an input for attack

graphs. They sourced the NVD (National Vulnerabil-

ity Database), parsed textual descriptions and eventu-

ally produced homogeneous, machine-readable vul-

nerability information ready for attack graph con-

struction. Many vulnerability prediction models

cover the change in security advisories, i.e., they anal-

yse the advisory output over time, e.g., (Alhazmi

et al., 2007). Yet, we cannot use those databases

or methods as automotive ECUs are custom made

and heavily modiﬁed for optimized performance. We

needed to use a method that works with black box

software.

5 FUTURE WORK

An attack surface estimation becomes more accu-

rate by considering more information. This section

describes some additional sources and methods that

could be included.

Semi-automated penetration test tools and tech-

niques could reveal further attack surface and esti-

mate its vulnerability. Many penetration test tools

specialised for embedded systems were created in re-

cent years and are actively maintained by the security

community. For example, the open source tools bin-

walk

and BAT (Binary Analysis Tool)

are ﬁrmware

software analysis tools and might reveal further attack

surface assessment data, e.g., ECU-internal software

architecture or run-time information. Collecting data

about real-word exploitation attempts may reveal new

and additional attack surface.

The method presented in this paper assumes a rea-

sonable mid-level, but ﬁxed, effort for each attack sur-

face. This means an attacker is assumed not gaining

experience, and vulnerability ﬁnding efforts are aver-

aged out evenly over the attack surface. Yet, the effort

for testing an attack surface’s vulnerability might dif-

fer greatly, and an attacker usually gains experience

with every attack surface he or she tests. A succes-

sor method could differentiate the vulnerability ﬁnd-

ing effort f for each attack surface type and create

formulae and an attacker model for growing experi-

ence.

Security is a software attribute that is hard to mea-

sure and even harder to validate. Analogously, effort

estimations need to be adjusted regularly. One valida-

tion method is consulting security experts, as (Man-

adhata and Wing, 2011) and we did for our attack sur-

face metric; Unfortunately is consulting experts rather

subjective. Validation data can be collected from sys-

tematic security assessments like penetration tests; es-

pecially from their data sets about attacker capabili-

ties and corresponding actual effort for exploiting an

ECU. A successor method could include said pene-

tration test data and the defect density predictions of

software growth models. A big enough data set about

measured actual effort and capabilities for a given

ECU would allow a regression analysis for predicting

the effort for similar ECUs. Some more data might be

generated by software growth models, which source

defect trackers and try to predict a software’s later

defect density. Yet, any data set is only valid for a

short time as advances in IT security research and de-

velopment (especially about reverse engineering) may

change the necessary actual effort starkly.

6 CONCLUSION

The method and metric that we presented in this pa-

per shows an approach to a structured evaluation of

the attack surface and the potential vulnerability of

automotive control units. We compiled and assessed

attack surface by collecting input interfaces and es-

timating vulnerability likelihoods, vulnerability ﬁnd-

ing efforts, attacker ﬁnding probabilities for revealing

binwalk: http://binwalk.org

BAT: http://binaryanalysis.org

Attack Surface and Vulnerability Assessment of Automotive Electronic Control Units

325

a vulnerability and ﬁnally an effort estimate for ex-

ploiting found vulnerabilities. We presented an attack

surface taxonomy and deﬁnition that can be applied

to the heterogeneous combination of automotive com-

munication channels; We completely abstracted an

ECU’s communication as potential attack surface that

might be susceptible to code injection. We used a vul-

nerability density (ideally for every input channel sep-

arately) for estimating the overall vulnerability likeli-

hood of an ECU. We modelled a concept of reference

attacker proﬁle and attack efforts for an extrapolation

on other, later-deﬁned attacker proﬁles. Finally, we

gave an attacker effort estimation method for over-

coming active exploit mitigation techniques and suc-

cessfully exploiting an ECU. The result of our method

and metric serves as an input for our graph-based se-

curity analysis. The integration into it was demon-

strated as a proof of concept in Section 3. We thereby

showed that our contribution is not purely academic

but has also an industrial application. The created

method, metric and software helps assessing the se-

curity of embedded controller networks.The metric

implicitly suggests certain ways of securing ECUs:

covering attack surface with ﬁrewalls or authentica-

tion checks, shrinking an ECUs attack surface by re-

moving services and inbound data and by harden-

ing attack surface with more secure software (stricter

compiler and programming languages, more defen-

sive programming and exploit mitigation techniques).

The resulting attack surface assessment facilitates a

construction of attack graphs for an overall automo-

tive system security assessment.

Table 2: Symbols Deﬁnition.

a ∈ E Access Effort

b ∈ E Basic Exploitation Effort

c ∈ E Counter Exploit-Mitigation Effort

d ∈]0, 1[ Defect Density

e ∈ E Effort E = {(t, r)|t ∈ T ∧ r ∈ R}

f ∈ E Vulnerability Finding Effort

g ∈ E Overall Exploit Creation Effort

i, j ∈ N

A Positive Natural Number

k, n ∈ N

A Positive Natural Number

o ∈ E Overall ECU Exploitation Effort

P Probability Distribution Function

q ∈ [0, 1] Probability

r ∈ R Effort Amount ∈ R

≥0

t ∈ T Capability Tag (a Label)

v ∈]0, 1[ Vulnerability Density

x ∈ R An Arbitrary Real Number

X Probability Random Variable

REFERENCES

Alhazmi, O., Malaiya, Y., and Ray, I. (2005). Security vul-

nerabilities in software systems: A quantitative per-

spective. In Data and Applications Security XIX, num-

ber 3654 in Lecture Notes in Computer Science, pages

281–294. Springer Berlin Heidelberg.

Alhazmi, O. H., Malaiya, Y. K., and Ray, I. (2007). Mea-

suring, analyzing and predicting security vulnerabil-

ities in software systems. Computers & Security,

26(3):219–228.

Charlie Miller and Chris Valasek (2014). A survey of re-

mote automotive attack surfaces.

Checkoway, S., McCoy, D., Kantor, B., Anderson, D.,

Shacham, H., Savage, S., Koscher, K., Czeskis, A.,

Roesner, F., and Kohno, T. (2011). Comprehensive

experimental analyses of automotive attack surfaces.

Proceedings of the 2011 Usenix Security.

Damm, W., Achatz, R., Beetz, K., Broy, M., Daembkes,

H., Grimm, K., and Liggesmeyer, P. (2010). Na-

tionale roadmap embedded systems. In Broy, M., ed-

itor, Cyber-Physical Systems, acatech DISKUTIERT,

pages 67–136. Springer Berlin Heidelberg.

Francillon, A., Danev, B., and Capkun, S. (2010). Relay

attacks on passive keyless entry and start systems in

modern cars. In Proceedings of NDSS.

Howard, M., Pincus, J., and Wing, J. M. (2005). Measuring

relative attack surfaces. In Computer Security in the

21st Century, pages 109–137. Springer US.

Ishtiaq Rouf, R. M., Mustafa, H., Travis Taylor, S. O., Xu,

W., Gruteser, M., Trappe, W., and Seskar, I. (2010).

Security and privacy vulnerabilities of in-car wire-

less networks: A tire pressure monitoring system case

study. In 19th USENIX Security Symposium, Wash-

ington DC, pages 11–13.

Kayaalp, M., Ozsoy, M., Ghazaleh, N., and Ponomarev,

D. (2014). Efﬁciently securing systems from code

reuse attacks. IEEE Transactions on Computers,

63(5):1144–1156.

Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno, T.,

Checkoway, S., McCoy, D., Kantor, B., Anderson, D.,

Shacham, H., and Savage, S. (2010). Experimental

security analysis of a modern automobile. In IEEE

Symposium on Security and Privacy, pages 447–462.

Manadhata, P. and Wing, J. (2011). An attack surface

metric. IEEE Transactions on Software Engineering,

37(3):371–386.

Roschke, S., Cheng, F., Schuppenies, R., and Meinel, C.

(2009). Towards unifying vulnerability information

for attack graph construction. In 12th International

Conference on Information Security, ISC 2009, pages

218–233, Berlin, Heidelberg. Springer-Verlag.

Schneier, B. (2012). The importance of security engineer-

ing. IEEE Security & Privacy, 10(5):88–88.

SECRYPT 2015 - International Conference on Security and Cryptography

326