Conference PaperPDF Available

Transport Layer Scanning for Attack Surface Detection in Vehicular Networks

Authors:

Abstract and Figures

In the beginning of every security analysis or penetration test of a system, information about the target has to be gathered. On IT-Systems a port scan is usually performed as a first step of an investigation. Since the communication protocols differ in automotive systems, generic port scanning tools can't be used for a security analysis of Control Area Networks (CANs). More complex protocols have a higher likelihood of implementation errors and bugs. On CAN networks, such payloads are transferred through International Standard Transport Protocol (ISO-TP) communication. We designed a new methodology to identify ISO-TP endpoints in automotive networks. Every of these endpoints can provide exploitable application layer protocols and therefor has to be considered during penetration testing and security analysis. We contribute a new scan approach for the automated evaluation of possible attack surfaces in automotive CAN networks which has a higher coverage and multiple advantages than state of the art approaches. CCS CONCEPTS • Networks → Transport protocols; Naming and addressing; • Security and privacy → Distributed systems security.
Content may be subject to copyright.
Transport Layer Scanning for Aack Surface Detection in
Vehicular Networks
Nils Weiss
Sebastian Renner
Jürgen Mottok
nils2.weiss@othr.de
sebastian1.renner@othr.de
juergen.mottok@othr.de
University of Applied Sciences
Regensburg, Germany
Václav Matoušek
University of West Bohemia
Pilsen, Tschechien
matousek@kiv.zcu.cz
ABSTRACT
In the beginning of every security analysis or penetration test
of a system, information about the target has to be gathered. On
IT-Systems a port scan is usually performed as a rst step of an
investigation. Since the communication protocols dier in automo-
tive systems, generic port scanning tools can’t be used for a security
analysis of Control Area Networks (CANs).
More complex protocols have a higher likelihood of implemen-
tation errors and bugs. On
CAN
networks, such payloads are trans-
ferred through International Standard Transport Protocol (
ISO-TP
)
communication. We designed a new methodology to identify ISO-
TP endpoints in automotive networks. Every of these endpoints
can provide exploitable application layer protocols and therefor has
to be considered during penetration testing and security analysis.
We contribute a new scan approach for the automated evaluation
of possible attack surfaces in automotive CAN networks which has
a higher coverage and multiple advantages than state of the art
approaches.
CCS CONCEPTS
Networks Transport protocols
;Naming and addressing;
Security and privacy Distributed systems security.
KEYWORDS
automotive networks, network scan, attack surface detection, au-
tomation
ACM Reference Format:
Nils Weiss, Sebastian Renner, Jürgen Mottok, and Václav Matoušek. 2020.
Transport Layer Scanning for Attack Surface Detection in Vehicular Net-
works. In Computer Science in Cars Symposium (CSCS ’20), December 2,
2020, Feldkirchen, Germany. ACM, New York, NY, USA, 8 pages. https:
//doi.org/10.1145/3385958.3430476
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specic permission
and/or a fee. Request permissions from permissions@acm.org.
CSCS ’20, December 2, 2020, Feldkirchen, Germany
©2020 Copyright held by the owner/author(s). Publication rights licensed to ACM.
ACM ISBN 978-1-4503-7621-1/20/06. . . $15.00
https://doi.org/10.1145/3385958.3430476
1 INTRODUCTION
Modern cars can been seen as safety-critical systems which get
connected to external networks or even in between each other to
satisfy upcoming requirements of both owners and manufacturers.
This development presents new attack surfaces that are subject of
exploitation, especially in recent years[Koscher et al
.
2010] [Check-
oway et al
.
2011] [Miller and Valasek 2015]. Since unauthorized
manipulation of safety-critical systems of a vehicle can lead to
serious danger, mechanisms for securing a car’s network against
intruders need to be implemented during the development pro-
cess already. This is also supported by upcoming standards from
recognized organizations like International Organization for Stan-
dardization (
ISO
) [ISO Central Secretary 2020] or United Nations
Economic Commission for Europe (UNECE) [for Europe [n.d.]].
Directing the development of a product towards these regula-
tions is time consuming and expensive. Often traditional companies
might not have enough experience in security engineering which
demands a high degree of automation in this process. With our
work, we target automated attack surface assessments of the car’s
network structure, focusing especially on transport protocols. By
scanning the attack surface in that domain in an automated manner,
the detection of vulnerabilities can be facilitated already within the
development process. In addition to that, automated scans allow
continuous monitoring of future attack surfaces over a vehicle’s
lifetime.
In summary, we make the following contributions:
We present a new open source tool for scanning a car’s
network on the transport layer through leveraging the trans-
port protocol stack. Our tool can detect
ISO-TP
[ISO Central
Secretary 2016a] endpoints within a CAN.
We compare the results of our scan algorithm with already
existing solutions.
We give examples on how the results of the conducted tests
help in developing further defence strategies and evaluating
the attack surface of a given automotive system in greater
detail.
This paper is structured as follows: In the next section, we dis-
cuss related work in the eld of scanning and fuzzing of automotive
systems. Section 3 introduces the protocol stack for diagnostic com-
munication in vehicles including an overview of the most relevant
protocols and layers. Section 4 gives an explanation of our scan-
ning eorts on the transport layer in detail. In section 5, we provide
CSCS ’20, December 2, 2020, Feldkirchen, Germany Weiss et al.
information on our test setup for dierent types of scans. Section 6
discusses some results we obtained from various scans on dierent
targets. Section 8 concludes our research and mentions some ideas
regarding future work in this domain.
2 RELATED WORK
In the past years, several research on automotive network security
has been published. Bayer et al. discuss stateful fuzzing of vehi-
cle systems. They present a message generator and publisher for
fuzzing diagnostic protocols. In the following, an evaluation of their
fuzzing design is carried out through performing a fuzz test of an
Electronic Control Unit (
ECU
) on Unied Diagnostic Services (
UDS
)
protocol level [Bayer and Ptok 2015]. Further details about system
states during their fuzz tests are not provided.
A notable automotive network scanning tool is Caring Caribou.
The open-source software is able to scan a car’s network on the
application layer (
UDS
and Universal Measurement and Calibration
Protocol (
XCP
)) and help in gathering information on available
services [Sandberg et al. 2018].
Kuldanaivel et al. proposed a mapping technique for automotive
networks which utilizes fault injections within the network com-
munication. Their approach can mainly be used for event-based and
periodic
CAN
trac [Kulandaivel et al
.
2019]. Diagnostic protocols
are not part of their work.
Ring et. al. transfer certain port scanning strategies to the au-
tomotive network world [Ring et al
.
2015]. We will show that our
scanning eorts provide some advantages over this previous work.
We base our scan technique on the transport layer only, which
allows us to potentially detect more ISO-TP endpoints than tools
solely focusing on the application layer.
3 DIAGNOSTIC PROTOCOL ARCHITECTURE
This section provides a general overview about diagnostic proto-
cols in vehicular networks. Since our work focuses on scanning
approaches in
CAN
networks, Ethernet or FlexRay based diagnostic
protocols are not in the scope of this paper. We introduce a clear
separation between transport and application layer, which allows
us to perform scans more deep and more general. This separation
is in contrast to previous published scan approaches for diagnostic
protocols over CAN.
Application
Transport
Network Access
UDS OBD-2 XCP GM-
LAN
ISO-TP
CAN
Figure 1: Diagnostic Protocol Architecture for CAN net-
works
Figure 1 provides an overview of relevant protocols and the
corresponding layers. The diagnostic protocol stack for automo-
tive networks follows similar layer based separations as they are
known from the
ISO
Open Systems Interconnection (
OSI
) model
[ISO Central Secretary 1989]. As dened by the
OSI
model, the ap-
plication layer protocols are independent from the transport layer.
Widely used application layer protocols in automotive systems are
UDS
[ISO Central Secretary 2012], On-board diagnostics (
OBD-2
)
[ISO Central Secretary 2016b], General Motors Local Area Net-
work (GMLAN) [GMW 2018] and XCP [XCP 2003].
The protocols
UDS
,
OBD-2
and
XCP
dene a clean separation
between application and transport layer. These protocols require
a transport layer protocol for communication. On CAN based net-
works,
ISO-TP
[ISO Central Secretary 2016a] is used for this pur-
pose. The
CAN
protocol can be treated as the network access pro-
tocol. Such a clean separation between layers allows to replace
ISO-TP
and
CAN
with Diagnostic over Internet Protocol (
DoIP
)
[ISO Central Secretary 2019] and Ethernet.
The
GMLAN
protocol combines transport and application layer
specications very similar to
ISO-TP
and
UDS
. Because of that sim-
ilarity, identical layer specic scan techniques can be applied. This
allows us to perform
ISO-TP
transport layer scans and
GMLAN
ap-
plication layer scans on
ECU
s implementing the
GMLAN
protocol
specication.
Central gateway
ECU
s play a special role in modern vehicle archi-
tectures. A diagnostic bus, exposed to the
OBD-2
connector, oers
a direct connection to the central gateway. One major function of
a central gateway is the protection of vehicle internal networks.
Therefore it acts as a rewall between the diagnostic bus and inter-
nal networks. This requires that the central gateway
ECU
routes
diagnostic related trac into the vehicles internal networks.
To overcome the bandwidth limitations of
CAN
, latest vehicle
architectures use an Ethernet based diagnostic protocol (
DoIP
) to
communicate with a central gateway
ECU
. The central gateway
ECU
routes application layer packets from an Ethernet based net-
work to a
CAN
based internal network. In general, the diagnostic
functions of all
ECU
s in a vehicle can be accessed from the
OBD-2
connector over the Unied diagnostic services on CAN implemen-
tation (
UDSonCAN
) or Unied diagnostic services on Internet Pro-
tocol implementation (UDSonIP)[ISO Central Secretary 2013].
4 TRANSPORT LAYER SCANNING
In order to identify all possible communication endpoints and their
supported application layer protocols, a transport layer scan has
to be performed rst. Through the separation into transport and
application layer, every communication endpoint, no matter which
application layer protocol it supports, can be identied. This ap-
plies even for the
GMLAN
protocol, where transport and appli-
cation layer denitions are mixed together. Sometimes, Original
Equipment Manufacturers (
OEM
s) also use
ISO-TP
endpoints to
exchange various data between
ECU
s. These endpoints use com-
pletely proprietary and unknown application layer protocols. Since
our approach only targets the transport layer, even these endpoints
can be identied on the network.
4.1 Protocol Properties
ISO-TP
is a transport protocol for addressed communication of data
packets over
CAN
networks. In modern vehicles, multiple use-cases
require more than eight bytes of payload.
ISO-TP
was designed to
Transport Layer Scanning for Aack Surface Detection in Vehicular Networks CSCS ’20, December 2, 2020, Feldkirchen, Germany
Table 1: Overview of ISO-TP addressing schemes with labels
for internal reference.
A1 Normal addressing, 11-bit CAN identier
A2 Normal xed addressing, 29-bit CAN identier
A3 Extended addressing, 11-bit CAN identier
A4 Mixed addressing with 29-bit CAN identier
A5 Mixed addressing with 11-bit CAN identier
Table 2: Summary of ow control messages in 11-bit CAN
identier (CAN Id.) frames for normal (A1), extended (A3)
and mixed addressing (A5) mode.
AE
CAN Id. (bits) Data Bytes
11 ... 0 1 2 3 4 5 ... 8
A1 AI PCI N/A
A3 AI w/o. TA TA PCI N/A
A5 AI AE PCI N/A
exchange packets with up to 4095 bytes of payload between two
ISO-TP
endpoints. In comparison to
CAN
,
ISO-TP
packets contain
a Address Information (
AI
) to identify the Source Address (
SA
) and
the Target Address (
TA
) of a packet. Common use-cases for
ISO-TP
communication are software updates or congurations of ECUs.
4.1.1 Protocol Frame Types.
ISO-TP
denes four dierent frames
to handle packet based addressed communication. These four types
can be identied through a constant part in the Protocol Control
Information (PCI) eld of each packet. The four frame types are:
Frame type 0: Single Frame (SF)
Frame type 1: First Frame (FF)
Frame type 2: Consecutive Frame (CF)
Frame type 3: Flow Control (FC)
To automatically detect
ISO-TP
endpoints, only the
FF
and the
FC
messages are relevant. To initiate the communication of a packet
with a payload size greater than seven bytes, the sender sends out
a
FF
that indicates the complete length of the packet. The receiving
endpoint has to acknowledge a
FF
with a corresponding
FC
message.
This
FC
message exchanges all relevant communication parameters
and status codes of the receiver. After the
FC
message is received
by the sender, it starts to transmit the payload, split in multiple
CF
s.
4.1.2 Addressing. The
ISO-TP
standard describes three dierent
kinds of addressing: normal, extended and mixed addressing[ISO
Central Secretary 2016a]. Dependent on the addressing mode, the
AI
is encoded in dierent elds of a
CAN
frame. Also the position
of the protocol control information eld varies, depending on the
used addressing scheme. For further references in this paper, all
addressing schemes will be identied with a label from Table 1.
Table 2 and Table 3 show the position of the
PCI
for all possible
addressing modes in ISO-TP communication.
Table 3: Summary of ow control messages in 29-bit CAN
identier frames for normal xed (A2) and mixed (A4)
addressing mode with physical and functional addressing
types.
0x18DA = Const: Normal xed addressing, physical
0x18DB = Const: Normal xed addressing, functional
0x18CE = Const: Mixed addressing, physical
0x18CD = Const: Mixed addressing, functional
CAN Id. (bits) Data Bytes
28 ... 16 15 ... 8 7 ... 0 1 2 3 4 5 ... 8
A2 0x18DA TA SA PCI N/A
A2 0x18DB TA SA PCI N/A
A4 0x18CE TA SA AE PCI N/A
A4 0x18CD TA SA AE PCI N/A
can0 603 [8] 10 64 00 00 00 00 00 00
can0 703 [8] 30 00 00 AA AA AA AA AA
Figure 2: Communication example of addressing scheme A1
captured with candump
4.2 Scanning
With the information from Table 2 and 3, a scan procedure to
identify
ISO-TP
endpoints can be implemented. This identication
can be done in an active or a passive scan approach.
4.2.1 Active Scanning. This technique is suitable to identify all ex-
isting
ISO-TP
endpoints of a vehicle network or an ECU. An active
scan will cause a high utilization on the scanned
CAN
network.
Any intrusion detection system will immediately identify an ac-
tive scan as malformed communication. Therefore an active scan
should be used with care, since the on-board communication of
a vehicle might be disturbed and even safety-critical or real-time
communication could be interrupted or delayed.
To identify all
ISO-TP
endpoints,
ISO-TP FF
s of all possible ad-
dressing schemes and with all possible address combinations are
sent on the
CAN
network. Every
ISO-TP
endpoint that receives a
correctly addressed
FF
has to answer with a
FC
message. As soon as
a corresponding
FC
is received on the
CAN
network, the commu-
nication parameters (addressing scheme,
SA
,
TA
,
AE
, padding) can
be determined from the combination of the sent
FF
and received
FC.
Figure 2 highlights all
ISO-TP
communication parameters for
addressing scheme
A1
. A
FF
(blue) message with
SA
0x603 (green)
and a packet size of 100 bytes (red) is sent on the
CAN
bus. An
ISO-TP
endpoint with
TA
0x703 (orange) acknowledges the
FF
mes-
sage with a
FC
message (blue). The
CAN
message length of 8 bytes
indicates that this
ISO-TP
endpoint uses padding (brown). The ad-
dressing scheme can be determined by the position of the frame
type identication (blue).
Another example with addressing scheme
A3
or
A5
is given in
gure 3. In real world scenarios, these two addressing schemes are
not deducible from their communication trac. On the other hand,
for the
ISO-TP
endpoint identication, it does not matter which
one is used. Source and destination
ISO-TP
endpoint addresses are
CSCS ’20, December 2, 2020, Feldkirchen, Germany Weiss et al.
can0 610 [8] 40 10 64 00 00 00 00 00
can0 640 [4] 10 30 00 00
Figure 3: Communication example of addressing scheme A3
or A5 captured with candump
Table 4: Overview of complexities per ISO-TP addressing
scheme
A1 211 2048
A2 2×28×28=217 131072
A3 211 ×28=219 524288
A4 2×28×28×28=225 33554432
A5 211 ×28=219 524288
still encoded in the
CAN
identier. Additionally, extended address
information is encoded in the rst payload byte of each
CAN
packet
(dark orange and dark green). The
ISO-TP
frame type information
is moved to byte position two of the
CAN
packet payload. This
ISO-TP
endpoint does not require padding, which can be seen from
the shorter
CAN
message length of the receivers ow control ac-
knowledge.
Table 4 shows the maximum scan complexity for every address-
ing scheme. In real world scenarios, the scan complexity is much
smaller since the range for
ISO-TP
endpoint addresses can be re-
duced to a fragment of the theoretical range.
OEM
s assign higher
CAN
identiers to
ISO-TP
endpoint addresses to reserve higher pri-
ority
CAN
identiers (lower values) for real time critical
CAN
mes-
sages. This is caused by the Carrier Sense Multiple Access/Collision
Avoidance (CSMA/CA) mechanism of
CAN
. Every
OEM
has its
favored address range, usually not greater than 256 possible ad-
dresses.
4.2.2 Passive Scanning. Passive scans have the advantage that no
additional bus load is generated during the scan. On the other hand,
it might be possible that not all existing
ISO-TP
endpoints are found,
since special
ISO-TP
endpoints might only be used during very rare
situations of a vehicle’s life cycle. No communication to this spe-
cial
ISO-TP
endpoints will show up in the vehicle’s network trac.
Another disadvantage of passive scans is that
ISO-TP
endpoints for
diagnostic protocols are only used during operations in a repair
shop or in the car factory. This makes the presence of some addi-
tional tool which triggers diagnostic communication necessary to
perform a passive
ISO-TP
scan. To conduct a passive scan, lters
on the rst and second byte of the
CAN
payload have to be applied.
As soon as a
FF
is detected by the frame type indicator (1) in byte
one or two of a
CAN
message payload, followed by another
CAN
message with a ow control frame type indicator as acknowledg-
ment, an
ISO-TP
endpoint is found. The extraction of the relevant
communication parameters is identical to the active ISO-TP scan.
4.3 Comparison to Existing Solutions
All known scan approaches, mentioned in related work, are us-
ing
UDS
messages to trigger a response of a target. This has two
downsides.
In case of a valid
ISO-TP
and
UDS
message, the target might
change its behavior through this request, sent by the endpoint
scanner. If the diagnostic service which is used for a scan is not
implemented, it might be possible that the target does not respond
at all. This makes it impossible to detect an endpoint if a wrong
service for discovery was chosen. Another scan with a dierent
service could be performed, but this would double the scan time.
The second downside is the waiving of the
ISO-TP
padding pa-
rameter. If an
ECU
uses padding for
ISO-TP
communication, this
ECU
will not respond to an
UDS
message sent over
ISO-TP
without
padding and vice versa.
Since our approach only sends an
ISO-TP FF
message on the
CAN
bus and does not complete the
ISO-TP
message, no application layer
code is triggered. The decision to use the
FF
message for stimulation
also removes the padding problem since a
FF
does not contain any,
by specication.
5 TEST SETUP
Our test setup simply consists out of two components. A computer
with a supported
CAN
interface, enough computation power to run
our scan software and a scan target. The target for a scan can be a
single ECU, a set of
ECU
s or even an entire vehicle. Figure 4 gives
an overview of the possible setups.
Figure 4: Test setup overview for single ECU and full vehicle
scans
5.1 Full Vehicle Scan
Since the
OBD-2
connector of a vehicle has to provide access to the
entire vehicle network, the
OBD-2 CAN
bus can be used to interface
our scan computer to the vehicle networks. A gateway
ECU
has to
route all diagnostic trac into the desired internal networks of the
vehicle. Further details on the abilities of the
OBD-2
connector can
be seen in the publication of Sommer et al. [Sommer et al. 2019].
Full vehicle scans can be performed without any harmful modi-
cation to a car. No wires have to be tapped and no plastics have
to be removed. Through the addressing mechanisms in
ISO-TP
, it’s
even possible to perform a scan of only one specic ECU or a range
of
ECU
s. The vehicle’s gateway routing for diagnostic protocols can
be used to access
ECU
s behind the gateway which might even be
Transport Layer Scanning for Aack Surface Detection in Vehicular Networks CSCS ’20, December 2, 2020, Feldkirchen, Germany
connected over a dierent communication technology like FlexRay
or Automotive Ethernet.
5.2 Single ECU Scan
As part of our research, we built a cheap and scalable hardware
architecture to perform automated scans on dierent
ECU
s. We
used multiple Raspberry Pi 4B Single Board Computers, equipped
with two
CAN
interfaces for communication and a relay to control
the targets power supply. Two MCP2515 ICs connected via SPI to
the Raspberry Pi SoC are used for the
CAN
communication. The
Raspberry Pis are operated with the latest Raspbian OS. All our
scans were performed from an user-land python applications which
used standard Linux Socket CAN interfaces.
This setup was used to interface with nine dierent
ECU
s from
ve dierent and independent
OEM
s. We investigated
ECU
s from
Daimler AG, Tesla Inc., Opel Automobile GmbH, Volkswagen AG
and BMW AG. We use the acronyms E1 to E9 to reference the tested
ECUs in the following sections.
Table 5: Overview of tested ECUs.
Label OEM Type
E1 BMW Gateway ECU
E2 BMW Body Domain Controller
E3 BMW Telematic Control Unit
E4 VW Body Control Module
E5 VW Dashboard ECU
E6 Opel Airbag ECU
E7 Opel Body Control Module
E8 Tesla Airbag ECU
E9 Daimler Immobilizer ECU
In comparison to full vehicle scans, we observed some diculties
with single ECU scans.
(1)
The
power supply
connector pins of an
ECU
have to be
identied. This is necessary to supply and operate the ECU.
Visual reverse engineering of the Printed Circuit Board (
PCB
)
of an
ECU
was the best method if no schematics were pro-
vided. Power traces can be identied by their size on the
PCB.
(2) CAN interfaces
need to be identied. These information
can be gathered from schematics or visual reverse engineer-
ing of the
PCB
. Usually,
CAN
transceiver ICs are easy to spot
on a PCB and traces can be followed to the according pins.
(3)
Some
ECU
s require
keep alive CAN messages
in order to
stay awake. Since a car manufacturer has to ensure that a
vehicle does not run out of battery, if the engine is turned o,
many
ECU
s go into a deep sleep mode. We observed that a
single
CAN
message, periodically sent, is enough to keep an
ECU
awake. Sometimes a Tester Present
UDS
message had
the same eects. We either tested random
CAN
messages, if
one keeps an
ECU
alive, we snied the
CAN
trac from the
real car and replayed this trac.
6 RESULTS AND DISCUSSION
This section provides all results of our automated scans for indi-
vidual
ECU
s and results for manually performed full vehicle scans.
Furthermore we discuss the impact of our results.
6.1 Single ECU Scans
We performed a full address range
ISO-TP
scan on all
ECU
s under
test. To compare our results to existing solutions, we performed a
scan with the open source tool Caring Caribou. As already men-
tioned, this tool uses
UDS
request messages to trigger a response
message on an
ECU
under test. The
ECU
s E6 and E7 are using
GMLAN
as application layer protocol. All other
ECU
s support
UDS
as application layer protocol. Multiple penetration testing projects
were performed over the last three years on the chosen set of
ECU
s.
Furthermore we studied repair shop tester tools and documen-
tation from the individual
OEM
s and performed manual reverse
engineering of the
ECU
s rmware. Therefore we know the sup-
ported ISO-TP endpoints from dierent sources and can distinguish
between correct identications and false (positive) detections.
Table 6: Total number of ISO-TP endpoints per ECU auto-
matically found by our transport layer scan algorithm (TP-
Scan). The row labeled with CC shows the results of the ex-
isting tool Caring Caribou [Sandberg et al. 2018]. The row
CCFP shows the number of false (positive) detected ISO-TP
endpoints.
E1 E2 E3 E4 E5 E6 E7 E8 E9
TP-Scan 23 1 16 1 1 1 2 1 125
CC 0 0 0 103 2 0 2 3 138
CCFP 0 0 0 102 1 0 0 2 14
On most
ECU
s we could identify one
ISO-TP
endpoint. As ex-
pected, gateway
ECU
s showed more than one
ISO-TP
endpoint.
Since our scan was performed on the diagnostic
CAN
of these
Gateway
ECU
s, all except one
ISO-TP
endpoint are used for com-
munication forwarding in vehicle subnets. Every
ISO-TP
endpoint
which is not the Gateway ECU’s diagnostic endpoint, gives access
to one dedicated ECU inside the vehicle network. Table 6 shows
the number of found
ISO-TP
endpoints per ECU.
ISO-TP
endpoints
which support proprietary application layer protocols increase the
attack surface of an ECU, as well.
Next to gateway
ECU
s, also the telematics
ECU E3
answered on
16 dierent ISO-TP endpoints. On
ECU
s with more than one ISO-TP
endpoint, we performed an additional application layer request to
identify if an
ISO-TP
endpoint answers or if this endpoint is only
forwarding trac, which would be the case for a gateway
ECU
. A
valid response reveals the correct diagnostic
ISO-TP
endpoint of
this
ECU
. All
ISO-TP
parameters for the
ECU
s under test are shown
in Table 7.
These results proof that our
ISO-TP
scan algorithm is able to de-
tect
ISO-TP
endpoints which don’t support diagnostic application
layer protocols and the algorithm is able to identify all necessary
communication parameters. Furthermore, our approach is applica-
ble to identify endpoints with every addressing schemes of
ISO-TP
CSCS ’20, December 2, 2020, Feldkirchen, Germany Weiss et al.
and independently from the supported application layer protocol.
In comparison to existing solutions, our approach did not detect
false (positive) ISO-TP endpoints.
Table 7: ISO-TP addressing scheme and communication pa-
rameters per ECU, identied by a transport layer scan.
Target Addr. Source Addr. Pad.
E1 A5 610h, AE:10h 6f4h, AE:f4h no
E2 A5 640h, AE:40h 6f4h, AE:f4h no
E3 A5 661h, AE:61h 6f4h, AE:f4h no
E4 A1 778h 70eh yes
E5 A1 714h 77eh yes
E6 A1 647h 247h no
E7 A1 641h 241h no
E8 A1 651h 641h yes
E9 A1 587h 607h yes
Table 7 indicates the previously mentioned scan range limitation
for diagnostic endpoint address spaces. In real world applications,
only a small address range is necessary to scan. This scan range
always depends on the
OEM
which manufactured the vehicle or
component under scan. The scan-complexity and therefore the
duration of a scan on real hardware is much lower as indicated in
Table 4. The
GMLAN
standard [GMW 2018, p. 25] species request
addresses to be in a
CAN
identier range from
0x241
to
0x25F
.
ECU
s which support
UDS
have their
ISO-TP
endpoint addresses in
the upper third of the possible range for standard
CAN
identiers.
6.2 Full Vehicle Scans
Compared to existing scan approaches [Ring et al
.
2015][Sandberg
et al
.
2018], our solution does not trigger any reaction on an
ECU
s.
This allows us to scan entire vehicles without modifying the state
of an
ECU
. Since the open source software Caring Caribou tries to
initiate the ProgrammingSession on an
ECU
, we did not performed
these scans on entire vehicles. Randomly sending an
ECU
to the
ProgrammingSession can cause undesired and unexpected errors or
diagnostic trouble codes on a car.
The following vehicles have been analyzed:
Table 8: Overview of tested vehicles and YOM (Year of man-
ufacture).
OEM Model YOM
Opel Astra H 2006
Opel Insignia A 2013
Skoda Superb 2019
VW Passat 2012
VW Golf Combi 2012
Nissan E-NV200 2018
Nissan Leaf 2016
BMW i3 2015
A rough estimation about an vehicles attack surface can directly
be derived from the number of ISO-TP endpoints.
Figure 6 clearly shows that more recent or higher priced cars
contain more ISO-TP endpoints. An Opel Astra, built 2006, only
has two dierent ISO-TP endpoints, whereby a Skoda Superb, built
2019, shows 26 dierent ISO-TP endpoints.
Individual scan results of each tested vehicle are shown in g-
ure 5. During our scan, we conducted a further analysis of the
supported application layer protocol of every identied ISO-TP
endpoint. ISO-TP endpoints, on which the application layer pro-
tocol couldn’t be identied, are labeled as unknown. To analyze
the application layer protocol of an identied ISO-TP endpoint, a
xed set of application layer messages were sent to an endpoint.
We used simple UDS, GMLAN and OBD-II commands, for example
TesterPresent or DiagnosticSessionControl. If an application layer
protocol is implemented on an ISO-TP endpoint, the
ECU
will send
a valid response, usually a negative response with a meaningful
negative response code. These application layer probings were done
by an automated script and the results were evaluated manually.
On vehicles from Nissan and Opel, raw
CAN
communication
on the
OBD-2
port could be observed. An analysis of the vehicle
schematics showed, that these vehicles don’t have a gateway
ECU
to separate the
OBD-2
diagnostic bus from the vehicle internal
networks.
In vehicles from BMW, the
ISO-TP
addressing scheme A5 is used,
whereby the ISO-TP source address is xed, and only the destination
address changes for each ISO-TP endpoint. This behavior can be
seen from our results in gure 5 and table 7. The
ECU
s E1, E2
and E3 have identical source addresses, which matches with our
observation on a full vehicle scan.
Most ISO-TP endpoints in vehicles from the Volkswagen Group
(VW and Skoda) show a xed dierence of 106 between the source
and the destination address of an endpoint. Vehicles manufactured
by Nissan show a dierence of 32 between source and destination
address on a majority of the identied ISO-TP endpoints. As de-
scribed in the
GMLAN
standard [GMW 2018] a xed dierence of
1024 between source and destination addresses could be observed.
These xed dierences between source and destination addresses
indicate ISO-TP endpoints for diagnostic operations, since an
OEM
internal pattern or standard might be the reason for this address
assignments. On the other hand, ISO-TP endpoints, which doesn’t
follow this strict pattern are more likely to support a proprietary
application layer protocol for vehicle internal functionalities.
On all vehicles,
OBD-2
endpoints could be identied on addresses
above 0x7df with a xed dierence between source and destination
address of 8.
7 RECOMMENDATIONS
On vehicles without a gateway
ECU
, all
ISO-TP
endpoints, even for
vehicle internal and proprietary communication, can be accessed
from the
OBD-2
port of a car. Vehicles with a gateway
ECU
grant
access only to diagnostic protocols, as for example
UDS
or
OBD-2
,
on the
OBD-2
port. Current automotive systems can contain huge
attack surfaces on a diagnostic protocol level. These protocols allow
to ash or recongure
ECU
s, which is rewarding for an attacker.
We recommend strong and state of the art authentication mecha-
nisms for all diagnostic functions an in-depth security analysis of
proprietary ISO-TP communication.
Transport Layer Scanning for Aack Surface Detection in Vehicular Networks CSCS ’20, December 2, 2020, Feldkirchen, Germany
Figure 5: TP-Scan details about all tested vehicles. Each gure shows the relation between source and destination addresses of
identied ISO-TP endpoints. Furthermore the supported application layer protocol of each ISO-TP endpoint is shown.
8 CONCLUSION & FURTHER WORK
Our paper shows the possibilities for automated security scans
in automotive networks. With our methodology and our tool, all
existing
ISO-TP
endpoints and therefore all possible attack surfaces
for diagnostic protocol attacks on automotive systems can be iden-
tied in an automated manner. Our results can be combined with
additional tools for security investigations or fuzzing of application
layer protocols.
Our tool assists penetration tester and security researchers to
gather information about possible attack surfaces in vehicular net-
works. This helps to speed up a security investigation on the one
hand and improves the investigation process and granularity on
CSCS ’20, December 2, 2020, Feldkirchen, Germany Weiss et al.
Figure 6: Year of manufacturing and number identied ISO-
TP endpoints.
the other hand. Our automated tool delivers reliable results on all
possible attack surfaces for ISO-TP based application layer protocol
communication and ensures that no possible attack surface with
ISO-TP based communication is missed.
AVAILABILITY
We provide all our tools for transport-layer-scans in automotive
networks as part of the open source software project Scapy [Weiss
2020]. Our work aims to support the automotive security commu-
nity to solve future security challenges.
ACKNOWLEDGMENTS
The present work as part of the PetS
3
project was funded by the
Bavarian Ministry of Economic Aairs, Regional Development and
Energy (Bayerisches Staatsministerium für Wirtschaft, Landesen-
twicklung und Energie) under grant number IUK-1711-0018. The
authors are responsible for the content of this publication.
We gratefully thank the maintainers of the Scapy framework for
their support during the development of our tools.
REFERENCES
2003. The Universal Measurement and Calibration Protocol Family. Standard ASAM
MCD-1 XCP. Association for Standardization of Automation and Measuring Sys-
tems, Germany, DE. https://www.asam.net/standards/detail/mcd-1- xcp/
2018. General Motors Local Area Network Enhanced Diagnostic Test Mode Specication.
Standard GMW3110. General Motors Worldwide (GMW).
Stephanie Bayer and Alexander Ptok. 2015. Do not Fuss about Fuzzing: Fuzzing
Controllers in Vehicular Networks. In 1ESCRYPT GmbH Leopoldstraße 244 80807
München.
Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham,
Stefan Savage, Karl Koscher, Alexei Czeskis, Franziska Roesner, and Tadayoshi
Kohno. 2011. Comprehensive Experimental Analyses of Automotive Attack Sur-
faces. In Proceedings of the 20th USENIX Conference on Security (San Francisco, CA)
(SEC’11). USENIX Association, USA, 6.
United Nations Economic Commission for Europe. [n.d.]. The World Forum for the
harmonization of vehicle regulations (WP.29). https://www.unece.org/trans/main/
wp29/presentation_wp29.html (accessed 2020-05-27).
ISO Central Secretary. 1989. Information processing systems – Open Systems Inter-
connection – Basic Reference Model – Part 4: Management framework. Standard
ISO/IEC 7498-4:1989. International Organization for Standardization, Geneva, CH.
https://www.iso.org/standard/14258.html
ISO Central Secretary. 2012. Road vehicles – Unied diagnostic services (UDS) – Part
3: Unied diagnostic services on CAN implementation (UDSonCAN). Standard ISO
14229-3:2012. International Organization for Standardization, Geneva, CH. https:
//www.iso.org/standard/55284.html
ISO Central Secretary. 2013. Road vehicles – Unied diagnostic services (UDS) – Part 5:
Unied diagnostic services on Internet Protocol implementation (UDSonIP). Standard
ISO 14229-5:2013. International Organization for Standardization, Geneva, CH.
https://www.iso.org/standard/55287.html
ISO Central Secretary. 2016a. Road vehicles – Diagnostic communication over Controller
Area Network (DoCAN) – Part 2: Transport protocol and network layer services.
Standard ISO 15765-2:2016. International Organization for Standardization, Geneva,
CH. https://www.iso.org/standard/66574.html
ISO Central Secretary. 2016b. Road vehicles – Diagnostic communication over Controller
Area Network (DoCAN) – Part 4: Requirements for emissions-related systems. Standard
ISO 15765-4:2016. International Organization for Standardization, Geneva, CH.
https://www.iso.org/standard/67245.html
ISO Central Secretary. 2019. Road vehicles – Diagnostic communication over Internet
Protocol (DoIP) — Part 2: Transport protocol and network layer services. Standard
ISO 13400-2:2019. International Organization for Standardization, Geneva, CH.
https://www.iso.org/standard/74785.html
ISO Central Secretary. 2020. Road vehicles – Cybersecurity engineering. Standard
ISO/SAE DIS 21434. International Organization for Standardization, Geneva, CH.
https://www.iso.org/standard/70918.html
K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway, D. McCoy, B.
Kantor, D. Anderson, H. Shacham, and S. Savage. 2010. Experimental Security
Analysis of a Modern Automobile. In 2010 IEEE Symposium on Security and Privacy.
447–462. https://doi.org/10.1109/SP.2010.34
Sekar Kulandaivel, Tushar Goyal, Arnav Kumar Agrawal, and Vyas Sekar. 2019. CAN-
vas: fast and inexpensive automotive network mapping. In 28th USENIX Security
Symposium (USENIX Security 19). 389–405.
Dr. Charlie Miller and Chris Valasek. 2015. Remote Exploitation of an Unaltered
Passenger Vehicle. DEF CON 23 Hacking Conference. Las Vegas, NV: DEF CON.
Martin Ring, Jürgen Dürrwang, Florian Sommer, and Reiner Kriesten. 2015. Survey on
vehicular attacks - building a vulnerability database. 208–212. https://doi.org/10.
1109/ICVES.2015.7396919
Christian Sandberg, Kasper Karlsson, Tobias Lans, Mattias Jidhage, Johannes Weschke,
and Filip Hesslund. 2018. Caring Caribou. https://github.com/CaringCaribou/
caringcaribou (accessed 2020-05-27).
Florian Sommer, Jürgen Dürrwang, Marius Wolf, Hendrik Juraschek, Richard Ranert,
and Reiner Kriesten. 2019. Automotive Network Protocol Detection for Supporting
Penetration Testing.
Nils Weiss. 2020. ISO-TP Scanner. https://github.com/secdev/scapy/blob/master/
scapy/tools/automotive/isotpscanner.py (accessed 2020-05-27).
Thesis
The evolution of cars from mechanical systems to rolling computers creates new requirements for safety and security engineering. Nowadays, every vehicle contains a safety-critical real-time communication network to fulfill its function. Especially, the increasing connectivity of automotive systems enlarged the attack surface for cyber-attacks. Safety engineering in this area is well understood and studied for decades, though the security engineering of these systems needs further research. This thesis introduces a black-box investigation process to analyze existing automotive systems and components and identifies security vulnerabilities in four different ECUs. Combined with a survey of published security research, vehicle-internal networks are identified as an extraordinary threat to the vehicle's safety and security. The outstanding automation capabilities of security tests for these networks are leveraged in the second part of this thesis. In order to create automated tools for automotive networks, a software foundation is necessary. As part of this thesis, a comprehensive open-source software framework for security testing in vehicular networks was developed and published. This aims to support further security research based on open and free software. Novel tools for the automated identification and exploration of attack surfaces in automotive diagnostic protocol implementations are created and evaluated. These tools allow the creation of comparable attack surface metrics through black-box scans of arbitrary ECUs. Automata learning and system state reverse-engineering techniques highly increase the exploration capabilities of the presented tools. The exploration algorithm is tested on thirteen different ECUs from independent OEMs. All gathered results are evaluated and discussed in the final part of this thesis. Finally, open issues and further research based on this contribution are discussed.
Conference Paper
Full-text available
Currently, the automotive industry aims to integrate security into the vehicle development process. In this process, a vehicle is analyzed for possible security threats in order to develop security concepts or security measures. Another important aspect in vehicle security development is security testing. Penetration testing is often used for this purpose. In penetration testing, a tester acts from the perspective of an attacker and tries to violate security properties of a vehicle through attacks (tests) in order to uncover possible vulnerabilities. Since this task is usually performed as a black box test with little knowledge about the system, penetration testing is a highly experience-based activity. Due to this, an automation of this process is hard to achieve. In this paper, we want to support the penetration testing process and its automation by introducing an extension of our automotive portscanner tool. This scanner was developed to scan vehicle networks, which are different from typical Information Technology (IT) networks, in order to extract information about the vehicle. Our tool is able to gather Electronic Control Units (ECUs) installed in a vehicle, as well as diagnostic services and subfunctions they provide. This functionality is extended by an automatic detection of transport and diagnostic protocols used in vehicles. With this knowledge, new use cases and functionalities like fuzzing or an automated generation of penetration test cases can be realized.
Conference Paper
Full-text available
Modern cars are significantly linked to the outside world because of rising number of connections in the vehicle, connections between the vehicle and the exterior environment , e.g. diagnostics and flash interfaces or the numerous amounts of bus systems for data exchange. All these connections are potential security breaches. Previous papers and this research work show that there are a lot of security vulnerabilities in modern car connections. The aim of this paper is to merge the found vulnerabilities and the available results in literature, categorise them in the same way as in Information Technology (IT) and give an outlook on how most problems can be solved. This paper also aims to introduce an example database for automotive IT vulnerabilities.
Conference Paper
Full-text available
Modern automobiles are no longer mere mechanical devices; they are pervasively monitored and controlled by dozens of digital computers coordinated via internal vehicular networks. While this transformation has driven major advancements in efficiency and safety, it has also introduced a range of new potential risks. In this paper we experimentally evaluate these issues on a modern automobile and demonstrate the fragility of the underlying system structure. We demonstrate that an attacker who is able to infiltrate virtually any Electronic Control Unit (ECU) can leverage this ability to completely circumvent a broad array of safety-critical systems. Over a range of experiments, both in the lab and in road tests, we demonstrate the ability to adversarially control a wide range of automotive functions and completely ignore driver inputdash including disabling the brakes, selectively braking individual wheels on demand, stopping the engine, and so on. We find that it is possible to bypass rudimentary network security protections within the car, such as maliciously bridging between our car's two internal subnets. We also present composite attacks that leverage individual weaknesses, including an attack that embeds malicious code in a car's telematics unit and that will completely erase any evidence of its presence after a crash. Looking forward, we discuss the complex challenges in addressing these vulnerabilities while considering the existing automotive ecosystem.
Do not Fuss about Fuzzing: Fuzzing Controllers in Vehicular Networks
  • Stephanie Bayer
  • Alexander Ptok
Stephanie Bayer and Alexander Ptok. 2015. Do not Fuss about Fuzzing: Fuzzing Controllers in Vehicular Networks. In 1ESCRYPT GmbH Leopoldstraße 244 80807 München.
Road vehicles -Diagnostic communication over Controller Area Network (DoCAN) -Part 2: Transport protocol and network layer services. Standard ISO 15765-2:2016. International Organization for Standardization
  • Iso Central
  • Secretary
ISO Central Secretary. 1989. Information processing systems -Open Systems Interconnection -Basic Reference Model -Part 4: Management framework. Standard ISO/IEC 7498-4:1989. International Organization for Standardization, Geneva, CH. https://www.iso.org/standard/14258.html ISO Central Secretary. 2012. Road vehicles -Unified diagnostic services (UDS) -Part 3: Unified diagnostic services on CAN implementation (UDSonCAN). Standard ISO 14229-3:2012. International Organization for Standardization, Geneva, CH. https: //www.iso.org/standard/55284.html ISO Central Secretary. 2013. Road vehicles -Unified diagnostic services (UDS) -Part 5: Unified diagnostic services on Internet Protocol implementation (UDSonIP). Standard ISO 14229-5:2013. International Organization for Standardization, Geneva, CH. https://www.iso.org/standard/55287.html ISO Central Secretary. 2016a. Road vehicles -Diagnostic communication over Controller Area Network (DoCAN) -Part 2: Transport protocol and network layer services. Standard ISO 15765-2:2016. International Organization for Standardization, Geneva, CH. https://www.iso.org/standard/66574.html ISO Central Secretary. 2016b. Road vehicles -Diagnostic communication over Controller Area Network (DoCAN) -Part 4: Requirements for emissions-related systems. Standard ISO 15765-4:2016. International Organization for Standardization, Geneva, CH. https://www.iso.org/standard/67245.html ISO Central Secretary. 2019. Road vehicles -Diagnostic communication over Internet Protocol (DoIP) -Part 2: Transport protocol and network layer services. Standard ISO 13400-2:2019. International Organization for Standardization, Geneva, CH. https://www.iso.org/standard/74785.html ISO Central Secretary. 2020. Road vehicles -Cybersecurity engineering. Standard ISO/SAE DIS 21434. International Organization for Standardization, Geneva, CH. https://www.iso.org/standard/70918.html
CANvas: fast and inexpensive automotive network mapping
  • Sekar Kulandaivel
  • Tushar Goyal
Sekar Kulandaivel, Tushar Goyal, Arnav Kumar Agrawal, and Vyas Sekar. 2019. CANvas: fast and inexpensive automotive network mapping. In 28th USENIX Security Symposium (USENIX Security 19). 389-405.
Remote Exploitation of an Unaltered Passenger Vehicle
  • Charlie Dr
  • Chris Miller
  • Valasek
Dr. Charlie Miller and Chris Valasek. 2015. Remote Exploitation of an Unaltered Passenger Vehicle. DEF CON 23 Hacking Conference. Las Vegas, NV: DEF CON.
  • Christian Sandberg
  • Kasper Karlsson
  • Tobias Lans
  • Mattias Jidhage
  • Johannes Weschke
  • Filip Hesslund
Christian Sandberg, Kasper Karlsson, Tobias Lans, Mattias Jidhage, Johannes Weschke, and Filip Hesslund. 2018. Caring Caribou. https://github.com/CaringCaribou/ caringcaribou (accessed 2020-05-27).
Road vehicles – Unified diagnostic services (UDS) – Part 3: Unified diagnostic services on CAN implementation (UDSonCAN)
  • Central Secretary ISO