Cybersecurity for Connected Cars
Exploring Risks in 5G, Cloud, and Other
Connected Technologies
Numaan Huq, Craig Gibson, Vladimir Kropotov, Rainer Vosseler

TREND MICRO LEGAL DISCLAIMER
The information provided herein is for general informationand educational purposes only. It is not intended andContentsshould not be construed to constitute legal advice. The
information contained herein may not be applicable to all
situations and may not reflect the most current situation.
Nothing contained herein should be relied on or acted
upon without the benefit of legal advice based on theparticular facts and circumstances presented and nothing

4
The Concept of Connected Cars

herein should be construed otherwise. Trend Microreserves the right to modify the contents of this document
at any time without prior notice.
Translations of any material into other languages areintended solely as a convenience. Translation accuracy
is not guaranteed nor implied. If any questions arise
related to the accuracy of a translation, please refer to

7
Research on Remote Vehicle
Attacks

the original language official version of the document. Any
discrepancies or differences created in the translation are
not binding and have no legal effect for compliance orenforcement purposes.
Although Trend Micro uses reasonable efforts to include
accurate and up-to-date information herein, Trend Micromakes no warranties or representations of any kind as

13
Cybersecurity Risks of Connected
Cars

to its accuracy, currency, or completeness. You agree
that access to and use of and reliance on this document
and the content thereof is at your own risk. Trend Microdisclaims all warranties of any kind, express or implied.
Neither Trend Micro nor any party involved in creating,producing, or delivering this document shall be liable
for any consequence, loss, or damage, including direct,

30
Fleet Management

indirect, special, consequential, loss of business profits,or special damages, whatsoever arising out of access to,use of, or inability to use, or in connection with the use ofthis document, or any errors or omissions in the content
thereof. Use of this information constitutes acceptance foruse in an “as is” condition.

Published byTrend Micro Research
Written by

Numaan Huq
Craig Gibson
Vladimir Kropotov
Rainer Vosseler
Stock image used under license from
Shutterstock.com

For Raimund Genes (1963-2017)45
Threat Model Connected Cars

54
Guidelines for Protecting
Connected Cars

63
Connected Car Security in Motion

The use of connected cars has become more and more common, a trend that will continue
in the foreseeable future.1 As the use of these vehicles grow, the scope and weight of risks
will continue to increase as well. Similarly, the vehicles’ link to connected technologies suchas 5G and the cloud can provide heightened speed and improved quality of services but
can also pose more risks in the form of attacks by threat actors who aim to exploit thesechannels for their own gain.
As 5G networks roll out globally, connected cars are expected to heavily utilize the lowlatency, high-bandwidth, and network slicing features of these networks. The 5G network
backbone, together with advances in artificial intelligence (AI) and machine learning (ML)applications for both on-board and in-cloud data processing, will bring fully autonomousvehicles one step closer to reality. Still, such technology is not immune to threats.
Likewise, the cloud can provide advantages for connected cars; for example, some electronic
control unit (ECU) functions can be moved to the cloud to simplify the electrical/electronics(E/E) architecture, expand processing capabilities, and reap many other benefits. However,it also poses risks like denial of service (DoS) attacks, man-in-the-middle (MitM) attacks,and hijacking of services, among others.
In line with this, this research also delves into fleet management and the risks that comewith managing vehicles as a connected unit. Now more than ever, it is important to explore
these risks in order to better prepare the proper defenses against threats and as a result,future-proof the security of connected cars. This paper aims to help car manufacturers andsecurity professionals equip connected cars with ample and proactive defenses.
This paper is an expanded version of the research paper released last year titled “Driving
Security Into Connected Cars: Threat Model and Recommendations.”2

1. The Concept of Connected Cars
Connected cars are part of the internet of things (IoT). These vehicles can access and send data, download
software updates, and connect with other connected cars or other IoT devices via the internet or WLAN
(wireless local area network) connections.3 They can provide their users with enhanced connectivity andinfotainment, and facilitate safer driving.4 It is estimated that by 2030, the number of connected cars willreach 700 million, while the number of autonomous vehicles will reach 90 million.5
Contrary to common belief, connectivity in cars is far from a new concept. In fact, today’s basic caralready comes with a wide variety of connected technologies. The following is a discussion of some of

oth

RDS

e

llit

eto

X

te
Sa

Blu

V2

e

bil

Mo

,W

i-F

i

these connected technologies.

eSIM

V2V

Back-end
cloud services

Vehicle internal network
Powertrain

Communications

Body
controlPowermanagement

ChassisSafetyEngine control
unit

Head
unit

Door
locks

Hybridpowertrain

Adaptive
suspension

CamerasystemTractioncontrol

Mobileconnection

Climatecontrol

Battery
management

Electronicstability control

Radar/LidarPowersteering

Telematics

Powerwindow

Energyrecovery

Active steering

Airbags

ACC, etc.

GPS, etc.

Sunroof, etc.

Actuators, etc.

Active bodycontrol, etc.

Tire pressure
monitoring system,
etc.

Figure 1. The technologies and functionalities that make up the internal network of a connected car
4 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

A typical new-model car runs over 100 million lines of code.6 The very basic cars have at least 30 electronic
control units (ECU), which are microprocessor-controlled devices, while luxury vehicles can have up to
100 ECUs.7 ECUs are all connected across a labyrinth of various digital buses such as CAN (Control Area
Network), Ethernet, FlexRay, LIN (Local Interconnect Network),8 and MOST (Media Oriented Systems
Transport).9 They operate at different speeds, move different types of data, and enable connections
across different parts of the car.10 ECUs control many critical functions in a car, including the powertrain,
the device and system communications body control, power management, the chassis, and vehicularsafety. Some of them can be accessed remotely via the head unit.
A modern car can already receive satellite data for connecting to radio stations and getting GPS
coordinates. In the future, cars will have cellular-satellite connectivity for data, which is especially usefulwhen driving through regions with poor cellular coverage.11 With companies like Amazon, OneWeb, andSpaceX racing to launch megaconstellations of internet-beaming satellites into low Earth orbit, cellularsatellite connectivity is expected to become mainstream within a few short years.12
Most new car models sold in the market have built-in embedded-SIMs (eSIMs), although some of them
are not activated. Built-in eSIMs are used to transmit telematics data, communicate with back-end cloudservers, create Wi-Fi hotspots, and get real-time traffic information, among other functions. Examples ofcloud-based back-end server applications include smart apps that can remotely start, stop, lock, andunlock a car, and apps that can automatically send current road conditions data to the cloud and transmit
to other vehicles subscribed to the same service.
RDS (Radio Data System) is used to embed small amounts of digital information in FM broadcasts.
Typically, the name of the radio station, the title of the song, and the time and date of airing are transmitted.
Using RDS-TMC (Radio Data System – Traffic Message Channel), a car can also receive real-time traffic
alerts, which are then displayed in the head unit.
Bluetooth and Wi-Fi are common in cars nowadays. Users’ mobile phones connect via Bluetooth to thehead unit of a car to perform activities such as playing music, making phone calls, and accessing address
books. Some cars, such as those made by Tesla, can connect to home Wi-Fi networks and download
over-the-air (OTA) software update packages for the cars.13 Many cars can create Wi-Fi hotspots for users
to connect to in order to access the internet via the cars’ eSIMs.
With the introduction of popular automotive telematics standards, mobile phone connectivity in cars has
shifted from simply making phone calls and accessing address books to allowing users to gain accessto apps, maps, messages, and music. Even basic cars now have support for standards such as Apple
CarPlay and Android Auto, thus making in-car apps available to the masses.
Vehicle-to-everything (V2X) communication is the driving future that the industry is headed toward. Vehicles
will be heavily relying on V2X to safely navigate roads. The two major V2X technologies being actively
developed are 802.11p, a WLAN-based system,14 and C-V2X (cellular vehicle-to-everything), a cellular5 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

based system that includes 5G.15 New cars are being equipped with either of these two technologies, but
a full rollout of V2X in every new car is still several years away, especially since the 802.11p and C-V2X
camps are competing for market share. Legacy vehicles, or vehicles that are not equipped with V2X
technology, will continue to be on the road for decades, and V2X vehicles will have to share the road withthem. V2X technology will amalgamate information from multiple network drop points — eSIM, mobile
network, RDS-TMC, Wi-Fi, and 802.11p or C-V2X — to build complete road situational awareness.

1.1 Automation and connected cars

0

1

2

3

4

5

No
Automation

DriverAssistancePartialAutomation

Conditional
AutomationHigh
Automation

Full
Automation

Zero autonomy; the driver
performs all driving task.

Vehicle is controlled by thedriver but some driving
assist features may be
included in the vehicle
design.

Vehicle has combined
automated functions, likeacceleration and steering,but the driver must remain
engaged with the driving
task and monitor theenvironment at all times.

Driver is necessity, but is not
required to monitor theenvironment. The driver
must be ready to takecontrol of the vehicle at all
times with notice.

The vehicle is capable ofperforming all driving
functions under certain
conditions. The driver may
have the option to control
the vehicle.

The vehicle is capable ofperforming all driving
functions under all
conditions. The driver may
have the option to control
the vehicle.

Figure 2. Society of Automotive Engineers (SAE) automation levels
Image Credit: National Traffic Highway Safety Administration16

The Society of Automotive Engineers has defined six automation levels: L0 to L5, with L0 meaning noautomation and L5 meaning full automation. Many “self-driving” cars on the road today like Mercedes
Drive Pilot, Tesla Autopilot, and Cadillac Super Cruise, among others, are classified as L2 because thedriver must remain engaged with the driving task and monitor the environment at all times. Tesla sells abeta-stage, full self-driving package that it claims can navigate highway merges and exits, lane changes,
and interchanges, automatically park, and be summoned from a parked position to where the driveris waiting, not to mention obey traffic lights and stop signs, and autosteer on city roads.17 All of thismaneuvering is done using only the GPS, cameras, radar, and ultrasonic sensors, with no lidar,18 no V2X,
and no cooperative driving. This places Tesla’s self-driving package somewhere between L3 and L4
when it exits the beta-stage, but that might take some more time as driver safety concerns19 need to beaddressed first.
One major roadblock for autonomous vehicles is that related legislation needs to be discussed to allow
for greater driving automation, after which more L3 and L4 capable vehicles will be seen on the road. As
a prerequisite for such legislation, V2X needs to be widely implemented using either C-V2X or 802.11p.
New car models will need to implement V2X modules and road infrastructure needs to be upgraded tocommunicate via V2X. This begs the question: which standard should be followed, C-V2X, 802.11p,
or both? And how can the bill for the enormous cost of upgrading road infrastructure to support V2X
standard(s) be paid? In a nutshell, future vehicles need to be always online and able to communicate
quickly and efficiently with the ecosystem to make L4+ autonomous driving an everyday reality.
6 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

2. Research on Remote Vehicle
Attacks
In 2017, we released a research paper that studied cyberattacks on intelligent transportation systems(ITSs).20 This current research is a follow-up of that earlier research. Now, we study the cybersecurity risks
posed by connected cars interacting with other vehicles, cloud services, and road infrastructures.
In this paper, to better understand the cybersecurity risks that connected cars face, we studied past carhacking attempts. There are a lot of published research papers on hacking cars, but we focused only on
attacks carried out remotely that successfully compromised at least one ECU inside a car. This gave us agood understanding of the tools, techniques, and procedures (TTP) used to compromise connected cars.
Once we understood the TTPs that are successfully used to remotely attack connected cars, we theorized
on possible cyberthreats against the connected car ecosystem, including the challenges of deploying
traditional malware against cars, attacking cloud-based services inside cars, visualized traditional IT
attacks on connected cars using the MITRE ATT&CK Matrix21 future connected car architecture in the eraof 5G, and theories on how cybercriminals might attempt to monetize attacks against connected cars,among other cybersecurity risks and threats.
Connected cars are “phones with wheels” that combine the risks of cars, telecommunications, andIT while centralizing these risks in connected car fleet management. Notably, phones are some of themost powerful surveillance devices ever made, and thus they expose cars to risks that are related tosurveillance, privacy, and fraud.
In our ITS research paper, we did DREAD threat modeling of the entire ITS ecosystem. In this research, weapply DREAD to both the connected car and its ecosystem to determine which areas pose the greatest
threats — this is a more focused and in-depth analysis compared to our general ITS threat modeling.
In addition to the monetization analysis, based on our expertise in cybercrime investigations,22 we also
theorized which threat actors would pose the greatest threats to the connected car ecosystem andexplored other motivations besides money.

7 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Connected cars primarily communicate wirelessly, but there are exceptions. An example is when an
electric vehicle is connected to the power supply and communicates with the power grid or anotherback-end infrastructure over the power line. This is not covered in this research. Instead, this research
focuses on wireless attacks as the main attack vector. Hacking via Bluetooth is considered a wirelessattack, but the limited range of Bluetooth radio and the need to be within the immediate vicinity of thevictim vehicle make it ineffective in compromising a fleet of vehicles. There are many published research
papers and articles on hacking cars, but only a small subset explores remotely executed attacks that havesuccessfully compromised at least one ECU inside a car. It is important to study these connected car
hacking cases to better understand the cybersecurity risks that connected cars face, and to gain a betterawareness of the TTPs used by hackers, which we then apply to our threat modeling analysis.
Finally, the connected car research would not be complete without some suggestions with regard toprotective measures for these cars and their ecosystem.

2.1 Connected Car Network Architectures
Modern connected cars have internal network architectures that are as diverse as the cars themselves.
The components communicate using standardized network protocols, but no two network architectures
are the same. The network architecture can even change between different makes and models from thesame manufacturer because the features of the cars will vary based on their prices. Figures 3, 4, and 5
illustrate three examples of car network architectures.

Figure 3. The Jeep Cherokee network architecture that the researchers Charlie Miller and Chris Valasekcompromised in 2015
Image credit: Charlie Miller and Chris Valasek23
8 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Figure 4. The Lexus network architecture that Tencent Keen Security Lab compromised in 2020
Image credit: Tencent Keen Security Lab24

Figure 5. The Tesla network architecture that the researchers Kevin Mahaffey and Marc Rogers explored in 2015
Image credit: Lookout25

We observed that while the manufacturers in these examples implement their networks differently, allthree architectures have common components such as the gateway, CAN bus, USB, Wi-Fi, and ECUs
that perform similar functions and interact in similar ways. To explore the functions and the interactionsof these components, we created a generic car network architecture. This is not a network architecturefrom a production vehicle but rather a theoretical visualization of the network topology and the major
components in a connected car’s network.
9 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Cloud services

Telematics
Head uniteSIM
OBD-II

Main
board
ECU

ECU 1

ECU 3

Body control CAN

RDS/Satellite

ECU 4
Ethernet
gateway

ECU 2

ECU 5

ECU 6

Chassis CAN

Gateway
ECU

Powertrain CAN

Bluetooth

ECU 7

ECU 8

ECU 9

Other CAN buses

Cellular via
mobile

MOST

Wi-Fi

FlexRay
LIN

OBD

3G/LTE/4G/5G

Ethernet

BUS communications

USB or Ethernet

SPI or UART

Direct connection(no protocols speciﬁed)

Figure 6. A theoretical visualization of a generic network architecture for a modern-day connected car

The following discusses the major components and their respective interactions in our generic car networkarchitecture:•

The telematics unit includes the eSIM that allows the car to communicate with 3G, LTE, 4G, and (inthe future) 5G networks. It can transmit telematics data, receive real-time data, communicate withback-end cloud servers, and allow access to the internet.

•

The RDS/satellite unit receives digital information from FM and satellite broadcasts. Using RDSTMC,
a car can receive real-time traffic alerts that are then displayed in the head unit. In the future, thesatellite component will enable cellular-satellite connectivity for transmitting data as an alternative to
3G, LTE, 4G, and 5G.26•

Bluetooth and Wi-Fi connectivity is common in modern cars. Users can use Bluetooth to connect
their mobile phones to a car’s head unit in order to play music, make phone calls, and access address
books. Some cars can create a Wi-Fi hotspot to provide internet connectivity to users and to connect
to home Wi-Fi networks to download OTA software updates. Mobile phones connected to Bluetooth
and/or Wi-Fi can tether to give a car access to the internet via 3G, LTE, and 4G networks.

•

On-board diagnostics (OBD-II) provides a vehicle’s self-diagnostics and reporting capabilities. The
OBD-II port can communicate with the head unit. It can talk directly to the CAN bus and send andreceive CAN messages and commands.

•

The ECUs in a car communicate via their connected bus and handle functions such as engine control,
traction control, door locks, climate control, battery management, hybrid powertrain, airbags, andradar functionalities.

10 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•The gateway ECU handles all communications with the different buses: CAN, LIN, MOST, and
FlexRay. Other bus protocols exist, but we used these four in our research since they are found in
most car models. The gateway ECU ensures that no application can directly communicate with thebuses, and it correctly switches messages to the target bus. It also performs validation procedures tomake sure that the messages conform to standards.

•

The main board ECU is the central processor for the head unit. It handles functions such as navigation,
display, radio playing, network connection management, and climate control. In our architecture,
the main board ECU communicates with the gateway ECU via the SPI (Serial Peripheral Interface)communication protocol27 or the universal asynchronous receiver-transmitter (UART)28 to send andreceive CAN messages and commands.

•

The Ethernet gateway handles all of the data switching between the radio frequency (RF) modules
and the head unit. In some car network architectures, the Ethernet gateway can directly communicate
with the gateway ECU. In our generic architecture, the Ethernet gateway communicates via the headunit.

2.2 Generalized Remote Hacking Techniques
for Connected Cars
We looked at four remote car hacking case studies: Jeep Hack 2015, Tesla Hack 2016 and 2017, andBMW Hack 2018 (These case studies are discussed in detail in Appendix A). From these case studies, wefound an emerging attack pattern that is repeated across all four attacks to compromise the connectedcars and send malicious CAN messages to the ECUs. We illustrate this pattern in the following diagram:
Outside connection

In-vehicle component connecting to outside

Initiate an MitM
Wi-Fi connection.

Access thehead unit.

Exploit a vulnerability
in WebKit or othersoftware.

Conﬁguration issues inmobile networks

Reprogram the CAN
bus gateway.

Circumvent checks
and upload modiﬁed
ﬁrmware.

Mobile network attacks

MitM with fakebase station

Target ECU unlocking
not required

Reprogram and/or
unlock other ECUs.

If necessary, exploit anoperating systemvulnerability for root
privilege escalation.
Gateway
mods required

Access the CAN bus
gateway.

No gateway mods required

Send arbitrary CAN
messages to ECUs.

In 100% of cases, attackers needto create complex exploit chains
to ﬁnally get access to the ECUs
and then send arbitrary CAN
messages remotely.

In-vehicle internal network

Figure 7. A generalized remote hacking attack chain based on the featured remote attack case studies

11 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Examining this attack pattern, we observed that:•

The initial attack vector is either via a mobile network or via a Wi-Fi network. In all four case studies,
the hackers attempted some type of a man-in-the-middle (MitM) attack29 using either the mobile
network or the Wi-Fi network.

•

The attackers always targeted the head unit, which is the infotainment hub of the vehicle. Head units
are found in all modern cars, with different degrees of functionality depending on whether the car is abasic one or a luxury vehicle. All new head units can talk to the gateway ECU, which makes them the
go-to entry point into the vehicle’s bus network.

•

Head units with an LCD screen run a browser agent such as WebKit. The hackers exploited a new orpreviously existing vulnerability for that browser to get a browser shell.

•

The browser shell typically has low privilege. Privilege escalation is required to get root access to theunderlying operating system of the head unit, which is commonly Linux.

•

The main board ECU talks to the gateway ECU, which then talks to the bus network. To send arbitrary
CAN messages to the bus network, the hackers needed to reflash the gateway ECU with their custom
firmware. Depending on an ECU’s function, it may not require firmware overwriting. If firmware
overwriting is not needed, the hackers could immediately start sending CAN messages to the bus
network and the connected ECUs.

•

Flashing the gateway ECU needs circumventing firmware integrity checks and flashing and restarting
the ECU in a reliable manner. Any mistakes in this step risks “bricking” the gateway ECU, requiring an
awkward visit to the car dealer to get it fixed by reflashing.

•After they gained control over the gateway ECU, the hackers could send arbitrary CAN messages
to the bus-connected ECUs. Some ECUs, however, needed to be reprogrammed and/or unlocked
to execute the hackers’ CAN messages. Unlocking ECUs might also allow the hackers to put such
ECUs in diagnostic mode, so that the malicious CAN messages would not be overwritten with valid
CAN messages.

•

The gateway ECU handles the routing of the arbitrary CAN messages to their target ECUs based on
the target ID of the CAN message frame, which greatly simplifies the attack execution.

12 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

3. Cybersecurity Risks ofConnected Cars
A modern car has an incredible number of connected technologies such as satellite, cellular, Wi-Fi,
Bluetooth, RDS, eSIM-based telematics, and others. The car uses these connected technologies forsending and receiving data that supports user applications, driving applications, autonomous driving,safety features, and many more. All these network-centric applications have created brand new attack
surfaces in connected cars. In this section, we apply our expertise in IT cybersecurity to explore potential
new network attacks on connected cars.

3.1 Connected Cars and 5G
A connected car comprises of two main components: the connectivity and the car itself. The connectivity
portion is based in part on what the connected vehicle will be doing, which determines where they might
be expected to go. If a connected vehicle is expected to travel on private property only (such as in an
open mineral mine or inside a warehouse), it might be connected with best-effort radio technology like
Wi-Fi. If a vehicle is intended to travel at potentially dangerous speeds through areas with a lot of people(such as on a highway) it might use 4G cellular; but since like Wi-Fi, 4G is also a “best effort” technology
with unreliable data quality, a human might still be required to drive the vehicle at all times.
In 5G, the data is both high-speed and high-quality. 5G data has a feature called quality of service (orQoS) that allows connected vehicles to travel at high speeds. 5G is an example of a piece of technologythat would enable connected vehicles to operate in spaces that are congested and potentially dangerous,
such as highways, parking lots, and in the case of autonomous drones, even the air. 4G and other radio
technologies are also managed in individual monolithic ways with interactions that are complex to handle.
These complex interactions often require continuous maintenance and tuning, making them unscalable tothe demands of 5G. In 5G, each of these technologies is automated, and automated in their relationships
with each other.

13 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

4G

Global Roaming

Mostlyofﬂinenetwork
intelligence

Machine Learning Cloud

ISP

Legacy Telecom Cloud

IT Cloud

IoT IT Cloud

Legacy Telecom

IP LTE

IoT Core

Data Cloud
Information Technology Cloud(Telecom)

Wireless Telecom Cloud
2G Core3G Core4G CoreIoT Core
Wireline Telecom Cloud

2G Radio

3G RadioIoT Radio

IoT Radio

2G Device

3G Device

4G Device

IoT Device

5G
Rely onreal-time
network
intelligenceRadio Cloud
Sensor Cloud

Figure 8. A side-by-side comparison of 4G and 5G networks for connected cars

As “phones with wheels,” connected cars have a specific set of phone-like features. In 5G networks,
common service-level features are gathered in 5G network “slices.” These slices allow a 5G network to
be operated more cheaply and effectively, and to reduce the chance of different kinds of devices receiving
the wrong data (aka information that provokes automated actions in the cars).

Slices and Slicing
A slice is a virtual network. A slice meets the safety and security requirements of specific regions, laws,
and vehicle types. This network slicing is performed at each level of the network and allows cars tofunction with more service stability.

Mobilebroadband

Communicationentertainment internet

Massive
IoT

Retail, manufacturing
shipping

5G network

Life critical
functions

Automotive medical
infrastructure

Figure 9. Example of 5G network slices
Image Credit: VanilaPlus news magazine30

14 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

In a connected car’s 5G network, these slicing rulesets are present at each level of the network. The
network remains dynamic as a whole but becomes both less expensive and more reliable for cars using
the slice.

Datacentric
5G is a datacentric network where specific telemetry values/data provokes network changes at theapplication network and hardware levels. This is the real strength of 5G: What was once unscalable
and manual in 4G is capable of being end-to-end automated in 5G. This common infrastructure thatruns customized services leads to a service mesh. Not only does every element in the mesh have its
vulnerabilities and patching needs, but every element also has its own concerns that involve access
control with topics like Oauth231 token sprawl (equivalent to losing control of passwords in an unloggedway) and logging structures that defeat normal detection rules that would trigger a security response (thesection on fleet management has more details about this).

C-V2X
Connected vehicles can also link to or at least gather information from the devices around them. Cellular
Vehicle to Everything or C-V2X is intended to thoroughly make a 5G car a part of the environment aroundit, making it capable of reacting to events. While C-V2X does function for 4G-connected vehicles, its
primary purpose in this setup is to provide convenience for the driver by giving traffic alerts and othersimilar functions.
In 5G, C-V2X comes into maturity. C-V2X has a large, stable, and innovative supply chain of integrated
technologies. The ability of the vehicle to behave both autonomously and cooperatively based on what
it senses from the environment is a step forward from traditional cars such as those in the 4G and pre4G eras. In 4G, C-V2X is primarily managed near the roadway. In 5G, C-V2X is managed primarily in the
network back end for the sake of centralization and reduced cost.
There are several subsets of C-V2X, some of which are discussed here:•

Vehicle to cellular network (V2N)•

Vehicle to device (V2D)•

Vehicle to vehicle (V2V)

Vehicle to Network (V2N)
The V2N approach connects vehicles with the back-end mobile carrier infrastructure. There are several
benefits to this approach. These include SIM card subscription management, the ability to receive firmware
updates over-the-air, management of the vehicle’s digital assets such as subscriptions, enhanced features(such as autonomous driving), anti-theft measures, and fleet management.

15 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

V2N technology also provides cooperative coordination to traffic; emergency vehicles can be given
priority to drive through at life-saving speeds. Large-scale analytics can be performed, including trafficengineering for smart cities, remotely deployed improvements to vehicle functions like improved braking,and responses to events such as high-traffic conditions, changes in weather, and public safety events
such as flooding. Organizational improvements to traffic such as assembling platoons or convoys of threeor more vehicles also rely on the 5G cellular mobile network.

Vehicle to Device (V2D)For V2D, the granular coordination of 5G can relay the location of pedestrians carrying personal devices
or cellphones to vehicles, reducing the likelihood of vehicle-pedestrian collisions. But the relationshipbetween vehicles and personal devices is not limited to pedestrian collision avoidance. The vehicle
receives navigation information from V2N based on V2D inputs. Passengers can use the vehicle’s onboard
C-V2N connectivity to receive data inside the vehicle, which the vehicle obtains from the local cell tower.
Additionally, V2D provides information that drives activities such as billing and onboard advertising.
Information gathered inside the car can also be leveraged by the fleet manager for additional enrichment
analytics such as advertising outside of the vehicle.

Vehicle to Vehicle (V2V)
V2V promotes collision avoidance as it enables securely navigating intersections. As vehicles approachan intersection, they communicate by exchanging certificates directly through public key infrastructure(PKI). Since V2V helps avoid collisions, this might lower insurance costs and make pay-as-you-drive
insurance a more affordable and suitable option. It also determines which vehicle will take a competing
resource such as a parking spot or lane change opportunity. This cooperative driving capability not only
improves safety and traffic efficiency but also increases the number of vehicles that can use a stretch of
roadway through better organization.

3.2 Cloud-Based Car E/E Architecture
The advent of 5G will play a big part in the connected car ecosystem, so it is expected that the (E/E)
architecture of connected cars will evolve to take advantage of the next-generation network. The key 5G
technologies that will be important to connected cars include the following:•

Software-defined networking (SDN)•

Beamforming for fast communications•

Network slicing to separate applications and QoS•

5G ML and AI applications•

Multiuser multiple input multiple output (MU-MIMO)

16 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•High availability (99.999%) and low latency (1 millisecond)•

Support for high density of connected devices and ultra-high speed•

Low power consumption

Connected cars will need ultra-low latency more than high bandwidth. Network slicing and SDN can help
separate high data rate applications in the car from ultra-low latency applications.
To illustrate the importance of ultra-low latency, here is an example of a car that relies on a cloud-based
decision service to shift gears: A car driving at 100 km/h on the freeway travels at 2.77 cm/ms. A supercar
like a Ferrari or Lamborghini can automatically shift gears every 50 ms. In between gear shifts, the car will
have traveled 138.5 cm or 4.54 feet. To intervene, the network needs to respond in less than 50 ms as
the 100 to 0 km/h braking distance is roughly 100 feet or 1.1 seconds. This illustrates that reaction time iscritical. On the other hand, the cloud-command to shift gears is probably a few packets long, comprising
the command and verification checksum, so it does not need a lot of bandwidth.
With 5G this sort of processing is possible, so why not move some ECU functions to the cloud? Gear
shifting and transmission are critical processes in a car, so arguments can be made that transmission andgear-shifting decisions should be processed on-board the car. For example, Luxury car manufacturer Rolls
Royce has a production car (Wraith model) that uses GPS data to determine gear shifts according to what
the road looks like ahead.32 Future connected cars could use a hybrid cloud and on-board processing
model for the transmission that ensures optimum gear selection either for performance, fuel efficiency, or
cruising, depending on what mode the driver selects.

Head unit/
Central controller

Head unit

CloudGroup 1

Group 2

Group 3... Group N

Group 1

Group 2... Group N

Group Cloud

ECU1

ECU1

ECU1

ECU1

ECU1

ECU1

ECU1

ECU1

ECU2

ECU

ECU2

ECU2

ECU2

ECU2

ECU2

ECU2

ECU3

ECU3

ECU3

ECU3

ECU3

ECU3

ECUN

ECU3

... ECUX... ECUY... ECUA... ECUB... ECUX... ECUY... ECUZ... ECUN

Figures 10. Car E/E architecture today (left) versus cloud-based car E/E architecture (right)

17 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

In a cloud-based E/E architecture, which ECUs can we move to the cloud and why? Based on ourbrainstorming we came up with the following discussion points:•

Move data- or processor-intensive ECUs. A low-latency, high-availability network is needed to makethis possible.

•

Move ECUs to the cloud, because cross-referenced and processed data in the cloud can increase
vehicle fuel efficiency and road capacity. For example, when using current road loads plus GPS dataplus traffic prediction, the car can select the optimal gear and speed to improve fuel efficiency andreduce emissions. This decision is made in the cloud and sent back to the car. In electric vehicles,
speed is adjusted, which in turn affects the battery levels. This is a centralized adaptive algorithmbased powertrain, chassis and also power management system powered by cloud computing andbig data.

•

Processor-intensive and overly complex tasks such as image processing and road conditionassessment should also be moved to the cloud. Of course, there must be localized processes tohandle these tasks as a fail-safe in case the network is disconnected, but the heavy lifting can bedone by cloud-based servers. Moore’s Law33 predicts that the processors that will be locally installedin the cars will be several magnitudes faster than what is available today. Similarly, available memory
for processing tasks will also scale up to keep up with processor capabilities. We can have cloudcomputing models where only images that the car fails to interpret locally can be sent to the cloudfor further processing, or all processing is done in the cloud except when network connectivity falls
below a certain threshold, or local-versus-cloud processing is split 50/50.

•

Safety systems should be left in the car, but a cloud backup is possible. The in-car safety systems
will always be first priority when making judgment calls on the road. If the cloud judges with 100%
accuracy that the safety system is making a mistake because it lacks road situational awareness,
it can override the safety system up to a permissible limit. Ideally, the car should have full roadsituational awareness. Still, the cloud sees all traffic at all times, something that the car does not havethe capacity or means to process.

So why move ECUs to the cloud?
•It will simplify the E/E architecture, leaving fewer ECUs to manage in the car itself.

•

It will massively expand processing capabilities using cloud computing.

•

It will enhance road situational awareness, from local to around 500 m radius.

•

It gives the ability to add new and innovative applications flexibly using incremental OTA updates.

•

It will improve fuel/battery/emissions/operational efficiency.

•

It will expand and flexibly control road load capacity from an ITS point of view.

•

It will allow easy integration with third-party service providers, for example, by easily subscribing torevenue-generation services like Uber which operates the car in autonomous mode.

18 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

Distributed cloud servers and a full-coverage, low-latency network will result in attackable surfacesthat are more resistant to malicious attacks.

Overall, cloud-based ECUs create exciting possibilities but also new challenges. Therefore, what are theimmediate risks with regard to having a cloud-based car E/E architecture? Some of the mainstream cloudattacks that OEMs, suppliers, and drivers need to worry about include:•

Denial of Service (DoS). This happens when attackers overwhelm a resource, making it unavailable forusers. Imagine the havoc on roadways if the whole cloud infrastructure that runs the E/E architecture
becomes unavailable. Depending on whether there is a local processor inside the car that can run
the entire car’s E/E architecture in the absence of the cloud, cars could get stalled, and crashes andfatalities would become unavoidable.

•

MitM attack. This occurs when an entity intercepts all network communications between thecloud and the car. This attack can modify, drop, delay the transfer of, or steal data, causing criticalmalfunction in the car.

•

Hijacking of services. This takes place when some of the services that are used by the cloud-based
E/E architecture are hijacked by an entity, modifying data. This kind of hijacking, because of its small
scale, is not easily noticeable and potentially introduces intermittent errors into the car’s operating
environment.

•

Latency issues. If the network latency continuously fluctuates (because of network issues or an
attack) the car will continuously context-switch between cloud and local processors, which may
introduce errors in operations. A sound cloud-based E/E architecture should also require on-board
processors that can act as a backup in cases where the network connectivity falls below a certain
threshold.

•

Data privacy. Any cloud architecture is bound to store critical and private data such as driver profiles,
car maintenance data, destination data, and financial information, among other pieces of sensitive
information. Loss or alteration of this data becomes a contentious issue in the event of a data breach.

•

Authentication and management issues. This is best described using an example: In 2020, Tesla’s
global network outage disabled the mobile app for their cars, which left Tesla owners unable tocontrol their vehicles via the app for functions such as changing the temperature and unlocking
their vehicles.34 This demonstrates that, an authentication or cloud management issue can severely
disrupt operations for cars with cloud-based E/E architecture, as critical services that they rely on
could become unavailable in the middle of an operation, such as because of an ongoing DDos attack
against the cloud servers.

•

Incorrect data. In this case, a car receives incorrect critical real-time data. This could stall the caror lead to an accident and potential fatalities. This could be caused by incorrect processing by thecloud-based server, or it could also be the result of an MitM attack.

19 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

Misconfiguration issues. This is a common and recurring issue with cloud-based servers and assuch is not unique to connected cars. Misconfigurations lead to malware infection, data theft, loss ofcontrol, hijacking, and others. Trend Micro Research has recently published a comprehensive paperthat explores more of these cloud security issues.35•

Cloud supply chain issues. The cloud is an “API economy.”36 One example is the data flow whenturning on an internet-connected smart lightbulb via the Google Home app. Clicking “on” in the
Google Home app sends a request to Google Cloud, which then forwards the request to the smart
bulb manufacturer’s cloud, which then sends the turn-on command to the smart bulb. These are allaccomplished using APIs. Hence, it is not unrealistic to expect that a connected car’s cloud could
make API calls to a Tier 1 (T1) supplier’s cloud, which in turn could make API calls to a Tier 2 (T2)
supplier’s cloud, and so on. Any break in this cloud supply chain could adversely affect the connectedcar.

3.3 Cloud Services Attacks on Connected Cars
At the Black Hat USA 2020 conference, 360’s Sky-Go team presented their security research on hacking
Mercedes-Benz cars.37, 38 They succeeded in hacking the Mercedes E-Class in multiple ways and found
19 different vulnerabilities that they reported to Mercedes. What stands out as the most interesting
attack vector is that the researchers were able to use the car’s eSIM to connect to Mercedes-Benz backend servers. They found a server-side request forgery (SSRF) flaw in the back-end surface of the car’s
infotainment system, in a plug-in application that allows users to add their social media accounts to thesystem.3939 What makes this interesting is that a flaw in a third-party-developed application installed in
the car was exploited to compromise the system. In this section, we discuss what we think connected car
cloud services will look like, as well as the new attack surfaces that will be introduced. The research from
Sky-Go is early proof that this type of attack can be successful and potentially dangerous.
In inspecting the interiors of the Tesla Model 340 and the 2021 Mercedes-Benz S-Class,41 it becomes
evident that luxury automobile manufacturers are doing away with physical buttons and switching to fully
digital cockpits. In addition to running applications for regular car features such as climate control, radio,hazard lights, these digital cockpits can also run third-party applications like those for maps, internet radio,
web browser, streaming video, social media, and messaging. The modern connected car is becoming a
giant smartphone-on-wheels where third-party cloud-connected applications play an important part in
the experiences of both drivers and passengers.

20 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

3rd party cloudOEM cloudTelecommunications box (TCB)eSIM
Cellular
3G/4G/5G
Head unit

Bus switch

Application

Middleware

Gateway ECU

CAN

ECU1

ECU1

... ECUA

CAN

ECU1

ECU1

... ECUB

LIN

ECU1

ECU1

... ECUX

MOST

ECU1

ECU1

... ECUY

EthernetswitchFigure 11. A cloud-connected ecosystem

The diagram in Figure 11 shows what we envision this cloud-connected ecosystem will look like. The head
unit will support running applications: There will be a middleware layer that abstracts the E/E details of the
car and makes it easier for developers to build car-based applications. The middleware can speak withthe gateway ECU and will give API access to applications that need to send messages to the ECUs. The
bus switch will route the packets to the target ECUs. The apps talk either to the OEM cloud (manufacturer
cloud) or to third-party clouds (like those of video-streaming apps) via a tethered cellular connection fromthe mobile phone or the built-in eSIM. Depending on the E/E architecture of the car, the gateway ECU canalso directly communicate with cloud services. As cars get better connected and smarter, car-specificapps will be developed and T1, T2, and OEM versions of app developers will emerge. OEM apps willprobably not need an intermediary to access the gateway ECU, or might even be able to talk to the bus
switch directly.
Middleware APIs will create a rich ecosystem for cars with digital cockpits, but they will also present newopportunities for cybercriminals by giving them easy API access to the vehicle’s E/E architecture andECUs. This could give rise to a whole host of architecture-agnostic malware such as phishing attacks
on cars that install an architecture-agnostic remote access tool (RAT), ransomware, and botnet, among
others. Another plausible vector is using jailbroken phones that are connected to the car, which can be

21 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

used as a pivot point to install architecture-agnostic malware in the car. In a later section, we discuss how
we think criminals will go about monetizing cyberattacks on connected cars. On the flipside, attacks on
the car cloud itself will disable functions in the car, cause loss of personally identifiable information (PII),
loss of control on the road, and loss of revenue. Cloud APIs can also potentially be used to locate, unlock,
start, and steal the car or valuables inside.
Cloud-specific attacks and middleware APIs in connected cars (when they are made available) will
become the weapon of choice for cybercriminals, and cars will be easier to compromise using a varietyof tried-and-tested malware and attack vectors.

3.4 Challenges of Deploying Malware in Cars
There is this common misconception that just because modern cars share many of the same hardware
and software components with everyday IT systems, infecting a car with malware is a straightforwardtask. This is far from the truth. Here, we discuss the limitations that hackers attempting to infect cars will
have to contend with.
•

One cannot just walk up to a car, plug in a USB drive, run AutoRun, and install malware. Different
car OEMs have vastly different system architecture and software environments that need to be
meticulously reverse-engineered for an individual or group to learn how to access systems andexecute a random binary.

•Some manufacturers run Linux or even QEMU. A hacker needs to extract the firmware and reverseengineer the image thoroughly to understand the software internals.

•

The cost of development for vehicle malware is high. The malware is also not easily portable, as
vehicle hardware, software, and network architectures vary between models and manufacturers. Thisfurther increases development costs. Also, the attack vector that the malware uses will determine
how effective the attack will be (such as whether it is single-use or can be deployed against a fleet).

•

A highly skilled and resourceful hacker who has an understanding of a car’s hardware, software, andnetwork architecture is needed to facilitate such attacks. In-depth knowledge of telecommunication
technology is also required if a hacker wants to compromise a whole fleet of vehicles.

•

Mistakes can be fatal for the driver and passengers, and with malware, such mistakes or fatalities
are bound to happen. These will quickly draw the attention of law enforcement and government
regulatory bodies, which the cybercriminals would want to avoid.

Even with these shortcomings, it is not impossible to create malware for cars, although such malware
would be technically extremely difficult. Supposing that there was a successful ransomware infection for
car brand X, for instance, the following points of contention must still be addressed:

22 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

The attackers would need to ensure that the ransomware does not cause fatality as that will attract
too much attention.

•

The infection can be cleared just by reflashing the ECU(s) at the dealer.

•Ransomware payment cannot guarantee that the car will return to its normal operation; instead of
paying, reflashing might be better.

•

Ransomware is a best-effort malware versus a targeted attack, so it is logical to expect that noransomware author will spend a huge amount of time and money developing complex malware that
only works with a single car model in specific circumstances.

In the four case studies that we analyzed (detailed in Appendix A), all the attacks ended up using complex
chains of exploits and misconfigurations to successfully access the vehicle’s internal network.
How can cybercriminals infect connected cars? Back in 2016, Trend Micro Research investigated malware
attacks against ATMs.42 The goal of these attacks was to infect ATMs with malware and instruct them todispense all their stored cash. ATMs from different manufacturers have different hardware and software
components, and it would have been impossible for the hackers to take apart every ATM and build
custom malware for each brand. Rather, they relied on interacting via APIs with a middleware layer called
XFS that runs in most ATMs and that handles all the hardware-specific calls that the malware needs toperform. The same will be true for connected cars where attacks will be made on a middleware layer thatruns apps, or on in-car, cloud-based services; these attacks will be architecture-agnostic, similar to how
hackers targeted the XFS middleware in ATMs.
In a nutshell, it is not impossible to install malware in cars — just extremely difficult. The only reasonable
mitigation for this problem is if the malware becomes architecture-agnostic using middleware APIs, or if it
uses an infection-and-spread vector that abstracts the car E/E architecture.

3.5 Traditional IT Attacks on Connected Cars
MITRE ATT&CK® is a “globally-accessible knowledge base of adversary tactics and techniques based onreal-world observations. The ATT&CK knowledge base is used as a foundation for the development ofspecific threat models and methodologies in the private sector, government, and cybersecurity productand service community.”43 MITRE is a commonly used compliance metric used for different ranges ofIT security products that are sold in the market today. Standardization makes it easy to identify andassess different classes of cyberattacks and apply the necessary containment and remediation actions
to neutralize the threats.

23 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Each of the four remote car-hacking case studies that we analyzed (full details of which can be found in
Appendix A) provides technical details of how different parts of their attack chain were executed. Still,none of them provides the full A-to-Z steps of their attack chains, so as not to risk giving cybercriminals
an easy-to-follow-guide on how to compromise connected cars. Using our reverse-engineering andprogramming experience, we attempted to fill many of the gaps to get a near-complete picture of the fullattack chains. Given the importance of MITRE to the IT security industry, we thought it would be helpful
to plot the attack chains from each of the four case studies into the MITRE ATT&CK matrix. This makes
it easy to observe attackers’ TTPs, compare attack patterns, and predict how future attacks will takeplace. It is also a good opportunity to map IT industry security practices to automobiles. As a disclaimer,
it should be noted that the ATT&CK matrix plots only serve as approximations of the attack chain basedon published information and our analysis.
Jeep Hack 2015
Initial Access

Execution

Persistence

Filters

Previlege Escalation

Defense Evasion

Exploit Public-Facing Application

Command-Line Interface

Create Account

Exploitation for Privilege
Escalation

Supply Chain Compromise

Exploitation for Client Execution

Hidden Files and DIrectories

Process Injection

Process Injection

Valid Accounts

Scripting

Valid Accounts

Valid Accounts

Scriptingstages: act
platforms: Linux

Credential Access

Hidden Files and Directories

Brute Force
Network Snifﬁng

Valid Accounts

Discovery

Lateral Movement

File and Directory Discovery

Exploitation of Remote Services

Network Service Scanning

Remote File Copy

Collection
Automated Collection

Command and Control

Exﬁltration

ImpactCommonly Used Port

Automated Exﬁltration

Endpoit Denial of Service

Custom Command and Control
ProtocolExﬁltration Over Alternative
ProtocolRuntime Data Manipulation

Network Snifﬁng

System Shutdown/Reboot

Process Discovery

Transmitted Data Manipulation

Remote System Discovery
Software Discovery
System Information Discovery
System Network Conﬁguration
Discovery
System Network Connections
Discovery

Figure 12. The Jeep Hack 2015 MITRE ATT&CK matrix

24 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Tesla Hack 2016
Initial Access

Execution

Persistence

Drive-by CompromiseCommand-Line Interface

Supply Chain Compromise

Exploitation for Client Execution

Valid Accounts

Scripting

Discovery

Valid Accounts

Lateral Movement

Filters

Previlege Escalation

Defense Evasion

stages: act
platforms: Linux

Credential Access

Exploitation for Privilege
Escalation

Disabling Security Tools

Exploitation for Credential
AccessValid Accounts

Scripting

Network Snifﬁng

Valid Accounts

Private Keys

Collection

Command and Control

ImpactFile and Directory Discovery

Application Deployment
SoftwareAutomated Collection

Commonly Used Port

Endpoint Denial of Service

Network Service Scanning

Exploitation of Remote Services

Data from Removable Media

Custom Command and Control
ProtocolRuntime Data Manipulation

Uncommonly Used Port

System Shutdown/Reboot

Network Snifﬁng
Process Discovery

Transmitted Data Manipulation

System Information Discovery

Figure 13. The Tesla Hack 2016 MITRE ATT&CK matrix

Tesla Hack 2017
Initial Access

Execution

Persistence

Drive-by CompromiseCommand-Line Interface

Valid Accounts

Supply Chain Compromise

Exploitation for Client Execution

Valid Accounts

Scripting

Filters

Previlege Escalation

Defense Evasion

Credential Access

Exploitation for Privilege
Escalation

Disabling Security Tools

Exploitation for Credential
AccessValid Accounts

Exploitation for Defense Evasion

Network Snifﬁng

Scripting
Valid Accounts

Discovery
File and Directory Discovery
Network Service Scanning
Network Snifﬁng

Lateral Movement
Application Deployment
Softwarestages: act
platforms: Linux

Collection

Command and Control

ImpactAutomated Collection

Commonly Used Port

Endpoint Denial of Service

Data from Removable Media

Custom Command and Control
ProtocolRuntime Data Manipulation

Uncommonly Used PortStored Data Manipulation

Process Discovery
System Information Discovery

Figure 14. The Tesla Hack 2017 MITRE ATT&CK matrix

25 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

BMW Hack 2018
Initial Access

Execution

PersistenceHardware Additions

Command-Line Interface

Supply Chain Compromise

Exploitation for Client Execution

Valid Accounts

Scripting

Discovery
File and Directory Discovery

Valid Accounts

Lateral Movement
Exploitation of Remote Services

Filters

Previlege Escalation

Defense Evasion

Exploitation for Privilege
Escalation

Scripting

Valid Accounts

Valid Accounts

Collection

Credential AccessNetwork Snifﬁng

Command and Control

ImpactAutomated Collection

Commonly Used Port

Endpoint Denial of Service

Data from Local System

Communication ThroughRemovable Media

Runtime Data Manipulation

Network Snifﬁng

Custom Command and Control
ProtocolSystem Shutdown/Reboot

Process Discovery

Data Encoding

System Information Discovery

Standard Non-Application Layer
ProtocolNetwork Service Scanningstages: act
platforms: Linux

System Network Conﬁguration
Discovery
System Network Connections
Discovery

Figure 15. The BMW Hack 2018 MITRE ATT&CK matrix

The matrices were generated using ATT&CK v6.3 in Navigator v2.3.2.44, 45 Detailed descriptions of attack
entries can be found at https://attack.mitre.org/versions/v6/. We made the following observations fromthis plotting exercise:•All four car platforms were running UN*X (aka *nix) operating systems, which is why we used the Linux
layer only.

•

Our analysis is only for the act stages because we do not have enough information to plot the prepare
stages.

•The Navigator prepopulates entries across multiple verticals when one is selected. For example, Valid
Accounts was automatically applied to Persistence, Privilege Escalation, and Defense Evasion after
we selected it in Initial Access.

•For the BMW attack plot, we also included techniques from the local attack for completeness.

•

All four attacks use “supply chain compromise” for initial access. This attack category includes
manipulation of software update/distribution mechanisms, which is what all four attack chains used.

•

All four attacks exploited vulnerabilities for initial access to the head unit and then escalation privilege
to Root.

•Three of the four attack chains did some form of defense evasion (for example, the Tesla attacks
disabled AppArmor).

26 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

There were many Discovery activities in all four attacks. This is expected as the researchers needed
to learn the systems.

•

Data collected in these attacks was mostly for learning about the systems and figuring out new attack
vectors.

•

The command-and-control (C&C) goal for these attacks was to send malicious CAN messages to thedifferent ECUs and get an execution.

•

The degree of impact varied between each attack. All of them achieved ECU DoS and manipulated
runtime data.

•

We used these learnings to predict cloud services and middleware attacks. The findings werediscussed in previous sections.

Connected vehicles share hardware, software, and communication protocols with the IT world. This hashelped reduce development costs (that is, no need for custom-built hardware and software) and provided
access to the rich development environment that already exists in the IT world. Thus, it is not surprisingthat when we abstract the vehicle attack chains using the MITRE ATT&CK matrix, they look uncannily likeeveryday IT cyberattacks.

3.6 Monetizing Cyberattacks onConnected Cars
When we think of cybercrime, the primary motivation is almost always direct or indirect financial gain,
and this is not any different for cybercriminals who will start attacking connected cars. Other motivation
factors for attacking connected cars and the most likely perpetrators who will carry out those attacks will
be discussed in a separate section.
Monetization is an interesting topic to explore since, as of writing, as there is not a lot of news aboutcybercriminals who exploit connected cars to make money. Most car-hacking stories come from security
researchers who have discovered and responsibly disclosed ways in which connected cars can behacked. It is therefore worth pondering how cybercriminals will monetize hacking connected cars. To
explore this inquiry, first we looked into underground marketplaces to see what cybercriminals wereactively discussing about cars. We found forum threads by people selling stolen accounts from carsharing and taxi apps, asking about OBD2 hacking, ECU tuning, and resources to learn about the CAN
bus. We also found threads by people selling key fob duplicators and antennas to sniff transmissions fromcar keys. Overall, the results of our search were limited, and this is a good thing because it shows thatcybercriminals have not yet focused their efforts on monetizing connected cars. Still, as the number ofconnected cars on the road multiplies, we cannot expect criminals to ignore this lucrative domain.

27 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

To monetize something, there has to be something valuable that has a direct or indirect resale value.
So what is valuable in a connected car that would entice cybercriminals to hack it? We drew up a list ofvaluable data and goods in a connected car:•

User PII. The driver’s mobile phone connects to the car and can share call history, address book,installed apps, and text messages, among other pieces of information. The car also knows exactly
where the driver has driven to, as well as the routes that they used. Overall, the modern connected
car collects a lot of user-centric PII that can be sold in underground marketplaces.

•

User data (non-PII). Modern connected cars let apps run either natively in the head unit or via Apple
CarPlay or Android Auto. These apps access cloud services and can be linked to different apps.46
Cars like the Tesla with Sentry Mode47 record the car’s surroundings when they are activated. Hence,a lot of user data is collected and stored in the car, and this data can prove to be a lucrative thefttarget.

•

The car itself. Obviously, the physical car has value, and if someone can remotely unlock, start, andsteal the car,48 then that attack could be repeatable across the same car model, or could even be
extendable to other models.

•

Goods inside the car. These are a favorite for thieves, and with hacking, unlocking the car andstealing things inside will be simplified. If an autonomous car were used to transport goods, then thatshipment would be another lucrative target.

•

Driving services. This will become a valuable commodity when autonomous vehicle services
become a reality. Hacking and using cars’ services for moving contraband items, committing crimes,
performing anonymous movements, and other illegal acts will make criminals difficult to trace for law
enforcement.

•

Stored energy. The world is rapidly moving toward green electric cars. Car batteries have evolved
over the years and now have capacities of up to 100 kilowatt-hours, which is a lot of stored energy.
Some countries are experimenting with using stored energy in cars to supplement the power grid.49
In the future, this stored battery energy in cars could potentially become a valuable commodity thatis worth stealing.

•

Network and processor resources. This includes a wide range of things such as free internet,50
network data usage, access to cloud services, access to V2G networks, access to V2V networks,
processor time, and others. Cybercriminals could install a botnet in a connected car and use network
and CPU resources while the car is idle at home for the night, or they could use the car as an initialaccess point to hack the power grid.

28 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

These are only a few financial possible motivations, and some of them assume future developments forconnected cars. Nonetheless, they help us define what is and will be valuable in connected cars. Basedon our analysis, we can classify three major categories of valuable goods and services that can potentiallybe monetized by cybercriminals:
1. Data collected, generated, stored, and shared by the cars
2. Physical access to the cars, including driving services
3. Network and processor resources of the cars
We fully expect these three categories to expand as more exploitable use cases are found. For example,
in the case of the third category, network and processor resources, when there is a middleware layer
in the car to support third-party application development and those apps are not strictly controlled by
the OEM, then different types of malware that can execute by API calls will be created. We will then see
middleware worms, ransomware, wiper malware, bots, trojans, RATs, and many more. In sum, the wholemalware monetization machine will be adapted to the connected car’s ecosystem to generate revenue forthe cybercriminals.

29 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

4. Fleet Management
For vehicle management to be cost-effective, the vehicles must be managed as one unit (also known asa “fleet”). A fleet can be composed of two or more similar vehicles that are managed in whole or part bya remote system. Vehicles might be similar in that they are members of a fleet of taxi cars, dump trucks,
garbage trucks, ridesharing vehicles, military vehicles such as tanks, or even autonomous vehicles suchas delivery drones.
There are many cost-saving opportunities when using fleets of connected vehicles that using unconnectedvehicles does not offer, such as identifying what cars have the highest total cost of ownership (TCO),
which ones are least used or least useful, which models are the most likely to be stolen or broken into,
and which ones have the most cybersecurity risks. Armed with this knowledge, the combination of fleet
vehicles with the highest return on investment (ROI) can be selected and improved on as the lowest-ROI
vehicles depreciate out of the fleet.
To maximize the ROI of a fleet by reducing its TCO, various factors have to be taken into account. Someof these are tracking the availability of parts, the distance traveled by specific vehicles when driven by
specific drivers, the increased cost of repair and maintenance when specific drivers use vehicles or when
specific activities are performed, and finally, the maintenance of the “connected” part of the connectedvehicle fleet. This final maintenance point includes networking (and breakdowns in networking) such as
information security breach or fraud.
One example of lost integrity is the outage of Tesla fleets.51 On September 23, 2020, a global outage left
all Tesla cars separated from their service provider and all Tesla-provided features. Notably, this is not thefirst time this has happened; in 2017, an API outage left most services unavailable.52
Fleet management security is not a topic that can be summed up as a simple dashboard application. It isa collection of company-wide fleet business rules that are enforced by security systems. Different fleets
will have different versions of what they consider a security issue, and different risk tolerances promote
different security actions. We expound on the 5G telecom network, as well as its risks and security, in ourpaper “Securing 5G Through Cyber-Telecom Identity Federation.”53
In summary, a connected car can be managed as part of a fleet to reduce both operating cost andexpense. Fleets and their cars depend on many sources of radio data as they travel, not all of which aretrustworthy. It is also difficult for a car or a fleet management function to tell which radio data source is
30 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

untrustworthy and which is not, since fleet management functions have neither visibility into a global
database of trustworthy radio data sources, nor the ability to authenticate them.
One approach to addressing this fractured security landscape is a Zero-Trust Cyber-Telecom Federation,a kind of logging that is harmonized across many sources to allow common security alerting.
Requirements (including fleet management systems’ security requirements) for this are laid out in the
United Nations document “Proposal for a new UN Regulation on uniform provisions concerning theapproval of vehicles with regard to cyber security and of their cybersecurity management systems.”54

4.1 Fleet Management Security Risks Today
The following are several examples of fleet management safety and security issues, organized by fleet
vehicle type.

4.1.1 Underground Taxicab Fraud
Fraud against fleets and their vehicles is already underway. On hacker underground forums, criminalplans and exploits on how to exploit connected vehicles are shared. A criminal exploit of connected cars
includes a means for fleet fraud using fake taxicabs.

Figure 16. An underground taxi fraud service

The Taxi Simulator falsifies the activity of a legitimate taxi, presenting fake activity. When this software isused in connected taxi vehicles, it can falsify the driving and pickup history of the taxicab to make moremoney.

31 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Figure 17. A post in the underground showing a forum on taxi fraud

The false history made by the simulator is also useful to criminals in performing a variety of frauds against
the company managing the fleet. This false history may also function as an alibi, a statement of false effort
by an employee who is home asleep, or a means of hiding the fact that fleet vehicles are being used for
non-work purposes. It even includes the ability to falsify drop-off points, the reputation of the driver, andwhat the customer sees. This can include changing the driver’s photo to contain a mark designating thedriver as having fake “Gold” status. When these are combined, it is not hard to imagine that they can bechained in sequence to facilitate untraceable kidnapping, or reversed to hide activities such as knowingly
driving criminals or contraband items through town to untracked pickups/drop-offs.

Figure 18. A post in the underground showing a sale of a fraud app

The driver in one case uses an app pulled from the underground and uses it just as a ridesharing or
taxi app would be used, with the exception of having much deeper control over what the company andcustomer see.

32 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Figure 19. The user interface of a taxi fraud app

4.1.2 Sale and Purchase of Used Connected andAutonomous Vehicles
Connected vehicles often rely on a SIM card subscription to a mobile internet service provider (MISP)
or a cellular internet company to remain connected when away from the fleet garage, which likely uses
cheaper Wi-Fi. As even connected cars depreciate out of their fleets, they will have to eventually be sold,normally at city auctions). Connected cars have two value elements, however: the “connected” and the“car.” When the “car” is sold, the “connection” (the mobile internet subscription) is not sold with it. Whena connected car manufacturer who is reselling the MISP subscription learns that the car has been sold by
its original owner, the subscription will be cancelled, making the connected fleet of used cars no longer“connected.” The new owner might happen to learn of this when the subscription has not been paid by
the former owner. For autonomous connected vehicles, this is especially an issue since they will no longer
have their autonomous features and will no longer be able to navigate. Arguments have already been
made that selling a car as a connected car (when in fact it is no longer connected) meets the conditionsof fraud. Finally, cars that are no longer connected might strand drivers on the side of the road, engage
other onboard security mechanisms such as lockout or Lojack for connected cars,55 and at a minimum,
lose their cost-saving benefits to fleet management ROI.
Autonomous vehicles that lose connectivity will seek a safe place to pull over. Without connectivity, thefleet management entity will only know their last position, which might be far from where the autonomousvehicle decides is a safe place to stop. If the autonomous vehicle is on the highway when this happens,
it might have to travel several kilometers as it looks for a spot, making it hard to find while driving
around visually searching for each of these vehicles within a circle that is kilometers wide. While a fleet’s

33 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

subscriptions could be transferred in some cases, the emergence of mobility-as-a-service (MaaS)56
lengthens the supply chain and might add expensive hours to the time needed to recover the service.

4.1.3 Fleet DDoS, MiTM, Intercept, and Fraud
The means for revoking connected car connectivity also open the door to several types of connected car
fleet management attacks. Since the fleet runs on cellular connectivity when driving around on streets andhighways, a range of SIM cards within the vehicles are used to identify and authenticate the vehicles. By
extension, these SIMs authenticate the fleet.
This range of SIMs that represents the fleet is managed by the provider of the SIM connectivity throughits sales and service organization.57 The first line for engaging this organization (that is Tesla sales andservice for a Tesla fleet or Daimler for a Daimler fleet) is their customer call center. If a person with the right
identifiers gets in touch with the call center, they can request for modifications to their account, with theeffect of modifying some or all the SIMs and therefore the connectivity of the fleet. This is a connected
car fleet management version of SIM-jacking.58 When modified, SIM-jacking can provide the attacker withthe ability to perform multimillion-dollar telecom fraud,59 intercept traffic by replacing security models, anddowngrade the security of the fleet for future attacks. To add, this can all be done OTA.60
Since these crimes are high-impact and scalable, even a single instance of fleet-level crime could wipeout all of a fleet’s intended ROI. Fleet management security must include adequate methods of preventingsocial engineering of fleet management accounts, including self-provisioning accounts and online fleet
management accounts.

4.1.4 Customer Impacts of Poor Fleet Business Architecture
For fleets that are customer-visible services, customer experience is a critical part of fleet management.
Fleet management decisions could have an impact on customers that, if negative, bears an impact on
the brand as well. Since the point of fleet management is to manage the fleet, bad security architectureand security design decisions can have a sudden and widespread brand impact. This could be traceable
to technical issues such as a system update, or an executive-level interpretation of business logic that is
exploitable.
A real-world example of this kind of impact is the aggressive interpretation (and consequent brand impact)of overbroad security definitions. In the case of Kari Paul,61 a fleet management condition of “no cellcoverage” was determined to indicate the car had been taken outside it’s allowed area (two slightly
different things). Ms. Paul, a The Guardian journalist who rented the car, had unknowingly moved outside
an unpublished zone (a geofence62) in which the car could travel. Connected car anti-theft functions
engaged, and the car refused to be driven. Ms. Paul (who rented the car for a drive through the country)
was stranded on a side road in a forest. On calling the rental company to ask for help, Ms. Paul was told

34 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

she would have to wait up to 24 hours to drive the car again (for a reset to take effect). The customer
service representative told her and her partner to sleep in the car and wait for the reset to take effect.
This is a brand impacting design error of both fleet management security and its effect on customer safety.
The source was an overbroad security condition (authorized driver leaving an area) and an aggressive
response to that overbroad definition (24-hour lockout/reset). These are standard IT security design
philosophies that do not work as intended in a vehicle or telecom environment.

4.1.5 Autonomous Vehicle Computer Vision Effects of Fleets
and Traffic
Self-driving is a defining feature of connected cars and autonomous vehicles.63 When vehicles are driving,
they use their computer vision and other navigation systems to avoid accidents and obey traffic laws.64
This represents a vulnerability.65 When traffic signs, road lane lines, and laws such as speed limit ordirection are modified for mischief or malice, the car will obey the “legal” markings. If the markings aretraffic lane lines drawn with a solid circle inside a dashed circle, it will be legal for the car to drive into thecircle but illegal to drive out — this becomes a trap for autonomous vehicles. Vehicles could be trapped
this way even if the trap is less obvious, such as a circle of “detour right” signs. Since impatient humans
who encounter this will simply apply their judgment and “break the law” to escape, eventually, the trap willcollect all the autonomous vehicles in the area, if such a trap is large enough and placed in an effective
spot.
Similarly, if a marker or piece of electrical tape is added to a traffic speed sign,66 the vehicle will read thesign and accelerate to unsafe speeds. If delivery vehicles and trucks67 are involved, they will receive traffic
tickets every time that they are clocked speeding, as well as driving at a speed that has been determined
to be unsafe.

4.1.6 Effects of False Telemetry on Connected andUnconnected Vehicles
In 2019, the artist Simon Weckert68 performed an original think piece that consisted of placing 99 activatedphones in a small red wagon and walking them across a bridge in Germany. His experiment, a video69
which he uploaded on Youtube, showed that Google Maps interpreted the wagon full of phones as many
vehicles driving slowly. The ML models of Google Maps interpreted this as a high-traffic condition andrerouted real-world vehicles away from Mr. Weckert’s wagon. This incidentally caused increased realworld traffic on the other bridge nearby.
This concept also illustrates real-world abuse. Through the use of several of these wagons involving
hundreds of phones, the traffic of an entire road could be arbitrarily redirected to or from different streets.
One long-standing trope in movies (as seen in “The Italian Job”70) involves a hacker modifying streetlights

35 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

from red to green (thus enabling escape) or from green to red (thereby hindering police response). The
following screenshot from an underground platform illustrates the demand for this service.

Figure 20. Forums in the underground on hacking traffic lights

The trivial complexity of the red wagon approach used by Weckert shows that a hacker does not need toknow anything about the network, but it will redirect traffic at their whim. Several red wagons would pushtraffic in a smaller range of chosen paths, allowing an attacker greater control. Certainly, this attack could
also be performed from the back seat of a car or through any approach with more stealth.
A deeper evolution of this exists as a concept. Mass malicious ridesharing, which involves using manyridesharing apps, emulated phones, and stolen credit cards to swamp an area with rideshare vehicles,
can have an extreme effect. If these vehicles are autonomous as well, portions of a fleet could be delayedfor some time as they contribute to gridlock.71
A conclusion we can draw from these examples and others like them is that business rules must be
reviewed with the same or greater level of diligence than that normally reserved for firewall rules, intrusion
detection rules, and similar. When managing autonomous and connected vehicles with power over theactions of humans in real-world circumstances, more attention is needed to the negative consequencesof planning. The application of a “hacker mindset” to business rules before implementation in technology
should be performed so obvious malicious abuses can be detected early when remediation is still lesscostly and implementation has not yet begun.

36 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

4.1.7 Connected Car Self-Provisioning
A means for reducing the manufacturer cost needed to set up connected car connectivity is the use of aself-provisioning portal. A website like this allows customers to manage their accounts and mobile device
SIM cards, thus also letting them add or remove vehicles. For fleets, this would be the management of theconnectivity (SIM cards) of many vehicles at once.
As a website, it is potentially vulnerable to all the security issues that websites face, such as cross-site
scripting, buffer overflow, and others. As an effect of such vulnerabilities, access could be granted to theaccounts that are managed by the website: in this case, the fleets of connected vehicles. In the case of
SIM-jacking,72 one of the ways that an attacker can gain control of SIMs is to control exactly this kind of
portal. By exploiting the functions of the portal’s account management, SIMs and their phone numbers
can be reassigned (for controlling the fleet), redirected (for surveillance or malware infection invisible to
network-based security), or used to initiate calls to expensive foreign attacker-controlled phone number
destinations such as 1-900 numbers. Detailed features such as car heating or others can be activated ordeactivated remotely as well.73
It can be speculated that a feature that might be abused through this method includes police car
coronavirus decontamination,74 providing false assurances of safety, or even “cooking” detainees throughheat exhaustion.
Depending on the features of the fleet management application, it can also be used to designate a car (orall cars) as stolen, or to disable or impair them.

4.2 Fleet Management Security States forConnected Cars
For the fleet to be capable of moving freely, fleet management of connected vehicles must work easily
across many types of cell towers and phone companies. This easy and secure fleet management must
work even when the car moves from one cell tower to another (having mobility75), and from cellular to WiFi (being nomadic76).
There are two general categories of fleet management. The first is the ridesharing sort whose examples
include ridesharing companies such as Uber and Lyft, as well as self-controlled fleets of police cars,transport trucks, delivery vehicles, self-driving warehouse vehicles, and other similar vehicles. These areserver-based IT services that lay over-the-top77 (OTT) telecom while having little visibility into telecom
infrastructure. They tend to have mobile phone apps or something similar on the consumer end, and a
network of IT servers on the backend. They are very dependent on the security of the telecom network
both for the app and the connectivity of the vehicles in the fleet. Security is performed through certificates
and the like.
37 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

The second general category of fleet management is the virtual phone company of Tesla, ZOOX,78 or
Daimler. These are vertically integrated and have both the ridesharing OTT infrastructure as well as thecomplex telecommunications supporting it. While the initial investment is much higher, this approachprovides both deep visibility and cost savings for the entire fleet through increased data accuracy andautomation. Automated control is much deeper for this model as well and is necessary for autonomousroad vehicles.79 This approach also provides additional control and security for the OTT layer by controlling
the telecommunications layer beneath it. Security is performed through a combination of SIM card telecom
network security and OTT traditional IT methods. The telecommunications name for this type of approachis virtual mobile virtual network operator (aka virtual MVNO80).
For the OTT approach, typical IT risks such as hacking, DDoS, DNS hijacking,81 malware, and other similar
traditional attacks are most likely. The OTT approach to fleet management is also vulnerable to MVNO
attacks; however, it can only mostly detect the simplest (and arguably clumsiest) attacks. These clumsy
attacks will typically all look like lost mobile connectivity of the kind that are caused by mobile network
coverage gaps. For the MVNO approach, traditional telecom risks such as SIM-jacking, long-distancefraud,82, wiretap,83 and redirection of OTT traffic (that is, for industrial espionage or tracking of individuals)
are most likely. OTT attacks such as traditional IT attacks also work against the MVNO method of fleet
management.
Both the OTT and MVNO methods identify security events by performing analytics on logging and canfollow a course of action similar to this equation: When A + B = C, then do D. To illustrate, when known
profiles (A), such as malicious patterns of behavior (B), are found (C), the security system can take asecurity action (D). In a mobility environment such as that used by a connected car, these behaviors (A)might be spread across multiple phone companies, IP addresses, phone numbers, and other identifiers.
When these malicious behaviors (B) are spread around across multiple versions of A, they do not tell arecognizable story (C) that traditional security systems can identify as malicious. In a complex mobile
network including the behaviors of a moving connected car, A, B, and C are often not calculated, so D
might never occur as a result.
An example can be illustrated by following the activities of a connected car through a typical day in which
there are multiple sources of information and therefore multiple versions each of A and B indicating manydifferent use cases that would have to be diligently assembled (that is, federated) to allow the detection ofmalicious behavior (C). A connected car’s day is described in the following diagram, using as an example
just one vehicle that might be a member of a fleet. The fleet management system is therefore responsible
for addressing the security of all the different potential combinations of these values of A and B so that
C can be calculated. These combinations of A and B can be arrived at through a type of tightly unified
logging called Cyber-Telecom (CyTel) Identity Federation. More information on this CyTel Federation will
be discussed in the section on solutions.

38 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

A Day in the Travels of
a Connected Car

Driver gets into his car.

6:00 a.m.

1

7:00 a.m.

Bluetooth, Wi-Fi, and cellular 4G/5G are some of theconnectivity types that are provided to a cellphone inside a carby the car itself. When a car provides these, malware or othermalicious behaviors to or from an onboard phone can bemasked by the car’s identiﬁers.

2, 3, 4

7:30 a.m.

5
Driver and car enter a tunnel and lose
connectivity.

6

7:50 a.m.

7

Driver and car move from one cell
tower carrier to another.

Each phone company will have its own risks and telemetry,and only some of these are shared between carriers ascommon information. An attack might cycle through multiple
spoofed phone numbers, protocols, identiﬁers, and behaviors
every time a network is transitioned.

8:00 a.m.

When a car travels from a public cellular network to a private
one, an attacker posing as an expected campus network willprompt a connected car to attempt a hazardous connection.
This will grant partial control to an attacker who can thenescalate their control over the car. to simple)

8
10:08 a.m.

9

A smart city’s private cellularmanaged by civic government.

Driver and car leave home.

A traveling car will connect to the public cellular network. The
home cellular network will be vulnerable to many telecom
attacks. A non-home network is considered “roaming.”
Roaming attacks hide their telemetry behind another phonecompany, and are especially difﬁcult to detect.

7:45 a.m.

Loss of connectivity opens the door to a wide range of attacks
and interceptions. It should be taken account in the ﬂeet
security model that spontaneous and unexplained loss ofconnectivity with the car is not only allowed but to be
expected.

Driver and car move from public
cellular networks to private cellular
networks.

Driver awakens at home.

A cellphone that is connected to the home Wi-Fi is vulnerable
to risks, such as those that affect laptops and other devices
used at home. This can include malware delivered by visiting a
website. The phone is nomadic, and moves from one immobile(or ﬁxed) Wi-Fi access point by disconnecting, moving, andreconnecting to another.

Spontaneous satellite connectivity.

5G satellite connectivity poses unusual risks. The fact that asatellite crossing overhead performs activities such as
supplying OTA updates to connected cars means that even aparked car out in a farmer’s ﬁeld can become part of a new
network with its own security behaviors.

3:00 p.m.

A smart city is a campus trafﬁc management network.
Malicious attacks include manipulation of city trafﬁc using
techniques such as mass malicious ridesharing and otherscalable attacks on autonomous trafﬁc logic.

10
OTT Fleet Management.

11

The most convenient but least powerful of the two major typesof ﬂeet management is OTT IT. In this model, the IT level of aconnected car connects to a ﬂeet management server on theinternet. This is typical of ridesharing apps, including thedriver’s summoning of their car from a parking lot.

MVNO Fleet Management.
The complex but powerful ﬂeet management type called
MVNO ﬂeet management spans both OTT IT and a proprietaryversion of a mobile telecom network. This version has visibility
into both telecom and IT telemetry types. This could allow a
driver of an autonomous vehicle to make it available during
the day for autonomous taxi services, recovering the cost of
the vehicle.

12

Figure 21. A day in the travels of a connected car
39 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

The above use cases can be visualized in the following table:
Cellular

Cellular(Public)(Non-Public)

Yes

No

No

Yes

Yes

No

No

No

Yes

Yes

No

No

Yes

No

Yes

No

No

Yes

Car – public
cellular

Yes

Yes

No

No

Yes

No

Security
State 6Tunnel – noconnectivity

Yes

Maybe,
dependingon the tower
at the tunnel
exit

Yes, upon
exiting thetunnelMaybe,
dependingon the tower
at the tunnel
exit

Maybe,
dependingon the tower
at the tunnel
exit

Maybe,
dependingon the tower
at the tunnel
exit

Security
State 7

Car – public
cellularYes,
telemetry
unique to
the new
carrier

Yes

No

No

Yes,
telemetry
unique to
the new
carrierNo

Security
State 8Car –campuscellular

Yes

Yes

Yes

Yes

Yes

Yes

Security
State 9Satellite
connectivity

Yes

Yes

Yes

Yes

Yes

Yes

Security
State 10

Car – Smartcity trafficengineering

Yes

Yes

Yes

Yes

Yes

Yes

Security
State 11

OTT fleetmanagement

Yes

Yes

Yes

Yes

Yes

Yes

Security
State 12MVNO fleet
management

Yes

Yes

Yes

Yes

Yes

Yes

Use Case

Mobility

Roaming

Nomadic

OTT IT

Security
State 1

Phone –
home Wi-FI

No

No

Yes

Security
State 2

Phone – incar Wi-Fi

No

No

Security
State 3

Phone – incar BluetoothNo

Security
State 4

Phone – incar 4G/5G

Security
State 5

Table 1. Telemetry states affecting fleet management security

40 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

4.3 Breakdown of Connected Car States andRisks
The following are the security implications of each of the mentioned states.

Security State 1 – Phone – Home Wi-Fi
A cellphone connected to a home Wi-Fi is vulnerable to risks like those that affect laptops and otherdevices used at home. These risks can include malware delivered by visiting a website (B.1). The phone
is nomadic and moves from one immobile or fixed WI-FI access point by disconnecting, moving, andreconnecting to another. The telemetry generated by the phone is of one kind only, and the IP address isstable. Logs generated from this connection will have a single type of telemetry. Detection of malicious
activity is likely since IT security products are often successful in this detection.
Connected cars are improved after the sale using updates, like how cellphones are updated. Some ofthese updates are huge and would therefore be expensive to load via 4G/5G SIM connectivity. Whena car is at its owner’s home or the fleet’s garage, it can install these updates via the owner’s Wi-Fi,
like how phones can be updated today. Attacks leveraging home Wi-Fi for malicious updates and carspecific malware are often hidden from connected car fleet management security. To be effective, fleet
management security must see this traffic as well, federating it along with cellular traffic from multiple
sources including public and campus cellular, mobile and nomadic OTT, and opportunistic attacks fromthe various networks that the vehicle and its passengers might encounter.
Like home Wi-Fi, homes in some regions can obtain a device called “femtocell,” a small cell tower used
to provide improved and reduced cost cellular coverage at home. When a connected car is at an owner’shome, it can be configured to connect to this immobile (fixed) cellular instead of to the Wi-Fi. When this istrue, both the car and the femtocell can be attacked by true telecom attacks, but the vehicle’s telemetry
will be masked by the femtocell’s metadata. Federated logging will need visibility to both IT telemetry,such as IP addresses and telecom telemetry, such as phone numbers.

Security State 2 – Phone – In-Car Wi-Fi
A cellphone connected to a car’s onboard Wi-Fi will be masked from upstream systems and provide two
sets of telemetry for traditional IT malicious activity. One set will be for the car’s Wi-Fi connectivity (B.2),
and the other set behind it will be for the cellphone. Security systems attempting to identify malicious
activity must be able to identify which is which and create a unified story to identify if malice is present.
This requires identity federation84 (SSO85 like harmonized logging) between the nomadic phone and the
car’s nomadic connectivity to the home Wi-Fi. All three (including the home Wi-Fi) must be federated
to create a single identifiable set of behaviors for malicious activity. When these three are federated,
malicious behavior becomes visible to security systems and capable of triggering a security response. As
nomadic devices, telemetry from all three devices will be consistent and stable.
41 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Security State 3 – Phone – In-Car Bluetooth
Malware capable of spreading via Bluetooth (B.3) is another type of telemetry that security systems must
federate for logging activities for these systems to be able to detect its behaviors. Bluetooth is also
capable of interacting with the SIM cards of mobile devices.86 This is a way of hijacking SIM-enabled
devices such as connected cars and phones.

Security State 4 – Phone – In-Car 4G/5G
Some cars have 4G/5G connections coming from a device that acts as a small cell tower inside thevehicle itself.87 When a driver enters a car of this type, their preconfigured phone will connect to the car’s
internal cellular connection, which sits behind the car’s outward-facing 4G/5G cellular connection. From
this point, the phone is vulnerable to true telecom attacks, including those that spoof a car’s cellularconnection and allow attacks on the phone, as well as attacks from the phone on the car. Since the carpasses the phone’s connectivity out to the telecom domain and from there to the internet, federated
fleet management logging between telecom telemetry and IT telemetry is necessary to see malicious
behaviors spread across these multiple networks and protocols.88

Security State 5 – Car – Public Cellular
As a connected car travels away from home, it will connect to a public cellular network. If this is the same
network that provides connectivity to the connected car’s SIM card, the car will be on its non-roaming home
cellular network and will then be vulnerable to many telecom attacks. If the network that the car connects
to is not a home cellular, and the car’s connectivity is provided by another phone company, this is calledroaming. By their nature, roaming attacks hide their telemetry behind another phone company. Roaming
attacks are especially difficult to detect.89 Federating telecom telemetry across multiple phone companies
is logistically complex. This information is held in part by the telecom carrier trade association called
the GSM Association (originally known as Groupe Spécial Mobile).90 Federating with GSM Association
roaming abuse data supplies valuable insight into other abuses including long-distance fraud performed
from within the car, the presence of some kinds of SIM-jacking, and various other telecom-level redirects
invisible to OTT IT fleet management security.

Security State 6 – Tunnel – No Connectivity
This use case is a critical distinction. The total loss of connectivity opens the door to a wide range of attacks
and interceptions. In nomadic devices, connectivity is lost when the device is purposely disconnectedfrom a fixed network. In mobility, it is lost when the device is unintentionally disconnected from a mobile
network. It should be taken into account in the fleet security model that spontaneous and unexplained
loss of connectivity in the car is not only allowed but to be expected. This is a source of risk, however,since telecom attacks redirecting connectivity to a malicious telecom OTT network will blind traditional
OTT IT security. The traditional OTT IT security will see only that an allowed or expected event occurred42 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

(lost connectivity). In the meantime, telecom attacks can modify the security profile of a car and restore
connectivity with normal security none the wiser.

Security State 7 – Car – Public Cellular
While public cellular represents a class of telemetry and risk, each phone company will have its own risks
and telemetry, and only some of these are shared between carriers as common information. When a car
is traveling down a highway, for example, fleet management security that federates telecom and OTT
IT logging must recognize and unify malicious telecom activity. This unity must happen across multiple
telecom instances representing parts of a single multicarrier session, across which malicious activity
might change its telemetry behaviors and identifiers even when continuing the same malicious behavior.
One example would be car-originated mobile spam,91 in which the malicious source code might cycle
through multiple spoofed phone numbers each time a network is transitioned.

Security State 8 – Car – Campus Cellular (Non-Public Network)
When a car travels from a public cellular network managed by a cellphone company to a non-public
network (an NPN92 or campus network), the fleet management security model must tolerate yet anotherhazardous condition. The transition between the public network and the NPN campus network is typicallynot federated; this means that posing as an expected campus network will prompt a connected car
to attempt a connection. This will of course grant partial control to an attacker who can then escalate
their control over the car.93 Campus networks combine the risks of nomadic, mobile, OTT, roaming, andnon-public and public networks. NPN campus cellular networks are typically the size of a university or
industrial campus but can be as large as a smart city.

Security State 9 – Car – Satellite Connectivity (Campus Cellular From Space)
Satellite connectivity of the sort proposed by Jeff Bezos’ Blue Origin94 and SpaceX’s Starlink95 pose
unusual risks. The risk profile is like that of a campus network. The fact that a satellite crossing overhead
can perform activities such as supplying OTA updates to connected cars means that even a car parked
outside in a farmer’s field can become part of a new network. This state means that the operating modelof connected cars must always be ready to suddenly receive information from a new network, even if thelocal cell towers are already connected. This opens the connected car fleet management model to evenspace-based risks96 as well as risks that pose as originating from space. As a type of campus network,
satellite-based traffic management networks combine the risks of nomadic, mobile, OTT, roaming, andnon-public and public networks.

43 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Security State 10 – Car – Smart City Traffic Engineering (Campus Cellular at
City Scale)A smart city is a campus network that provides traffic management input for connected vehicles based on
known, predicted, and planned vehicle-traffic-impacting activities.97 These can include the manipulationof city traffic using techniques such as mass malicious ridesharing.98 As a type of campus network, smart
city traffic management networks combine the risks of nomadic, mobile, OTT, roaming, and non-public
and public networks.

Security State 11 - Fleet Management – OTT (Information Technology)
One of the two major types of fleet management is OTT IT. In this model, the IT level of a connected carconnects to a fleet management server on the internet. This model is typical of ridesharing apps and theirinfrastructure. The security of this model is often standards-based according to ISO 21434. More details
on this ISO standard and Trend Micro’s insights and recommendations can be found in our paper, “ISO/SAE 21434: Setting the Standard for Connected Cars’ Cybersecurity.”99

Security State 12 – Fleet Management – MVNO (Information Technology and
Telecom)
The second of the two major types of fleet management security is derived from a common set of security
rules that spans both OTT IT and a proprietary version of a telecom network. This version has visibility into
both telecom and IT telemetry types. This is a collection of risks called Cyber Telecom (CyTel).100 Examples
include long-distance fraud, wiretapping, and interception of navigation and tracking information thatwould allow hijacking of a vehicle.

44 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

5. Threat Model Connected Cars
Based on the different remote attacks on connected cars, it is evident that there is a need to provide
guidance that will help protect connected cars against remote hacks. To that end, we created a threat
model for connected cars.
With our threat model, developers and car manufacturers can better assess, identify, classify, and quantify
the risks that come with each threat in the threat model.101 It aims to help them create more secureconnected cars from the very early stages of the software development life cycle. By shedding light onconnected car attack vectors, their risk levels, and the important security observations based on them,
we hope to help keep connected cars running smoothly and securely.

5.1 Connected Car Attack Vectors
The connected car ecosystem is extremely complex, with potentially millions of endpoints and end users.
The complexity of this ecosystem, with its immense size and many functions, makes for large and attimes unpredictable attack surfaces. Although they primarily communicate wirelessly, connected carsheavily depend on the networked ITS infrastructure for communications. In our threat modeling exercise,
we focused on attacks that could be launched remotely against and/or from the victim vehicles. The
following, in no particular order, are the connected car attacks that we identified:•

Spoofing V2X messages being broadcast to the ecosystem•

Passively sniffing V2X messages being broadcast to the ecosystem•

Sending incorrect or improper commands to back-end ITSs•

Sending MitM communications and false data to back-end ITSs•

Sniffing network traffic between a connected car and back-end ITSs•

Remotely transmitting and installing malicious firmware and/or apps•

Electronically jamming wireless transmissions to disrupt operations•

Performing an MitM attack with wireless transmission to intercept and modify car data•

Exploiting vulnerabilities in software, hardware, operating systems, and protocols

45 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

Using RF modules to access the head unit via complex exploit chains•

Remotely hijacking vehicles via compromised CAN bus•

Dumping firmware to recover credentials and configurations•

Installing malicious third-party apps in a connected car’s infotainment system•

Deleting local files in a compromised connected car’s file system•

Attacking via a malicious app installed on a connected mobile phone•

Electronically jamming a connected car’s safety systems, such as radar and lidar•

Attacking the camera system’s image processing with specially crafted visuals•

Installing malware or spyware in a connected car•

Identifying and abusing device misconfigurations•

Discovering and abusing vulnerable remote systems using Shodan, a search engine for internetconnected devices102•

Conducting social engineering attacks such as creating fake RDS-TMC messages, phishing, andmap poisoning•

Launching distributed denial-of-service (DDoS) attacks using a compromised ITS infrastructure•

Launching DDoS attacks on an ITS infrastructure so that it fails to respond to requests•

Credential brute-forcing and abusing weak authentication methods•

Injecting malicious scripts via malvertising•

Performing traditional attacks such as SQL (Structured Query Language) injection,103 cross-site
scripting (XSS),104 session hijacking,105 and DNS (Domain Name System) spoofing106•

Pivoting a connected car as a trusted entry point to the V2X network•

Compromising a third-party software supply chain to push malicious updates•

Scanning the V2X network from a connected car to discover the topology and nodes

There are overlaps between some of these attacks. An example is the overlap between spoofing V2X
messages to the ecosystem and sending incorrect or improper commands to back-end ITSs. In reality,
they are different because not all spoofed messages are malicious, but both types of messages mightultimately achieve malicious results.

46 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

5.2 The DREAD Threat Model
One of the many benefits of threat modeling is that it allows organizations to look at security in a structured
way, enabling them to analyze each possible threat and effectively identify which threats to prioritize interms of mitigation.107 The DREAD threat model can be used to perform a qualitative risk analysis,108 which
is opinion-based in that it uses rating values to evaluate the risk level of a threat. We arrived at the risk
rating for a given threat by asking the following questions:•

Damage potential: How great is the damage to the assets?

•

Reproducibility: How easy is it to reproduce the attack?

•Exploitability: How easy is it to launch an attack?

•Affected users: As a rough percentage, how many users are affected?

•

Discoverability: How easy is it to find an exploitable weakness?

We used the threat rating table shown in Table 2 for our connected car risk analysis.

RatingD

R

Damagepotential

Reproducibility

E

Exploitability

A

Affected users

D

Discoverability

High (3)Medium (2)Low (1)

The attacker subverts thesystem and can inflict
serious damage.

The attacker subverts thesystem and can inflictmoderate damage.

The attacker subverts thesystem and can inflictminor damage.

The attack can be
reproduced every time.

The attack can be
reproduced, but only
within set limitations.

The attack is very difficult
to reproduce, even withfull knowledge of the
security hole.

The attack requires little
or no knowledge of thesystem in order to exploitit.

The attack requires askilled operator with
fundamental knowledgeof the system in order toexploit it.

The attack requires
an extremely skilled
operator with in-depth
knowledge of the system
in order to exploit it.

The majority of everyday
users will be affected by
the attack.

A good-sized portion of
everyday users will beaffected by the attack.

A very small percentageof everyday users will beaffected by the attack.

Published information
readily explains the attack.
Vulnerabilities are found in
the most commonly usedapplications and systems.

Vulnerabilities are notcommon and are foundonly in certain applications
and systems. The attack
requires skills to discover
exploitable weaknesses.

Vulnerabilities are difficult
to find and, if found, arevery difficult to weaponize.
It is extremely difficult to
attack applications andsystems.

Table 2. The DREAD threat model

47 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

The risk rating is calculated by adding the rating values based on the answers to the DREAD questions
for a given threat. The overall risk is rated as:•High if the score is between 12 and 15.

•

Medium if the score is between 8 and 11.

•

Low if the score is between 5 and 7.

5.3 Measuring the Risks of Attacks onConnected Cars
For each of the connected car attack vectors we have identified, we assigned scores for realistic extreme
scenarios and calculated the risk rating using the DREAD threat model, as shown in Table 2.
Attack vector

D

R

E

A

D

RatingRemarks

Remotely transmitting and installing
malicious firmware and/or apps

3

1

1

1

1

Low

Can the attackers remotely download
and flash the ECU firmware after they getaccess to the head unit?

Using RF modules to access the head
unit via complex exploit chains

3

1

1

1

1

Low

RF units are Bluetooth, Wi-Fi, and eSIM.

Remotely hijacking vehicles via
compromised CAN bus

3

1

1

1

1

Low

This assumes that the attackers are
already inside the vehicle. Can they
compromise an ECU?

Deleting local files in a compromised
connected car’s file system

1

1

1

1

1

Low

The firmware is in nonvolatile memory.
Some dynamically created user files canbe deleted.

Installing malware or spyware in aconnected car

2

2

1

1

1

Low

This is difficult to execute because
different car models have different networkarchitectures.

Spoofing V2X messages being
broadcast to the ecosystem

2

2

2

2

2

MediumSpoofing is the act of falsifying the identityof the sender in order to gain an illicit
advantage.

Passively sniffing V2X messages being
broadcast to the ecosystem

1

3

2

1

3

MediumData traffic broadcast to or from other cars
and the ITS road infrastructure is sniffed.

Sending incorrect or impropercommands to back-end ITSs

3

1

2

2

2

Medium

A back-end ITS system is where aconnected car sends commands, e.g., atraffic light controller.

Sending MitM communications andfalse data to back-end ITSs

3

1

2

2

2

MediumThis is when the connected car isreporting roadway or car data to the ITS
back-end system.

Sniffing network traffic between aconnected car and back-end ITSs

1

3

2

1

3

MediumIngress or egress network traffic between
the connected car and the back-end ITS
system is sniffed.

Performing an MitM attack withwireless transmission to intercept andmodify car data

3

1

2

1

2

Medium

A GSM base station or a cloud source iswhere the connected car receives datafrom external sources.

48 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Attack vector

D

R

E

A

D

RatingRemarks

Dumping firmware to recovercredentials and configurations

2

2

2

1

2

MediumThe firmware package typically contains
updates for multiple ECUs.

Installing malicious third-party apps ina connected car’s infotainment system

1

2

2

1

2

MediumApps are installed via a mobile network or
the TCB (from the OEM).

Attacking via a malicious app installed
on a connected mobile phone

2

3

3

1

2

MediumThis assumes that the malicious app is on
the mobile phone that is connected via
Bluetooth or Wi-Fi to the head unit.

Exploiting vulnerabilities in software,
hardware, operating systems, andprotocols

3

1

1

2

3

MediumThe head unit typically runs a custom
Linux kernel and other common tools suchas the WebKit browser.

Attacking the camera system’s image
processing with specially craftedvisuals

2

2

1

1

3

MediumThe firmware is reverse-engineered to findflaws in the image processing logic, or trial
and error is used.

Identifying and abusing device
misconfigurations

3

2

2

2

2

MediumThe provisioning files for OTA software
updates are captured to figure out therunning services.

Conducting social engineering
attacks such as creating fake RDSTMC messages, phishing, and map
poisoning

1

2

2

1

2

MediumRDS-TMC could display fake roadwayalerts in the head unit and confuse thedriver.

Credential brute-forcing and abusing
weak authentication methods

2

3

2

1

3

MediumThis could be used to compromise
vehicle Wi-Fi or privileged accounts in theoperating system.

Injecting malicious scripts via
malvertising

1

2

3

2

3

MediumThis could happen via an installed app or
via a webpage loaded in the head unit’s
browser.

Performing traditional attacks suchas SQL (Structured Query Language)
injection, cross-site scripting (XSS),
session hijacking, and DNS (Domain
Name System) spoofing

2

1

2

1

2

MediumThis primarily targets the head unit or
middleware that runs in the car.

Pivoting a connected car as a trusted
entry point to the V2X network

1

2

2

1

2

MediumThe connected car is a trusted endpointthat could be abused to get into the ITS
infrastructure.

Compromising a third-party software
supply chain to push malicious
updates

2

1

2

2

2

MediumThis targets third-party apps installedin the head unit or are running on top of
middleware.

Scanning the V2X network from aconnected car to discover topology
and nodes

1

3

3

1

3

MediumThis is an extension of passive scanning.
The goal here is to discover ITS
infrastructure topology.

Electronically jamming a connected
car’s safety systems, such as radarand lidar

3

3

3

1

3

High

Lidar is a detection system based on theprinciple of radar, but uses light from alaser.

Electronically jamming wirelesstransmissions to disrupt operations

3

3

3

1

3

High

2G, 3G, LTE, 4G, 5G, Wi-Fi (802.11p),
RDS-TMC, or cellular-satellite connectivity
is jammed.

Discovering and abusing vulnerable
remote systems using Shodan, asearch engine for internet-connected
devices

3

3

3

2

3

High

This technique could be used to findexposed ITS infrastructures that could
then be compromised.

49 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Attack vector

D

R

E

A

D

RatingRemarks

Launching distributed denial-of-service(DDoS) attacks using a compromised
ITS infrastructure

2

2

2

3

3

High

The goal is to overwhelm the connected
car with excess data from the ITS
infrastructure.

Launching DDoS attacks on an ITS
infrastructure so that it fails to respondto requests

3

3

3

3

3

High

The goal is to knock the ITS infrastructure
offline so that the connected car cannot
send or receive messages.

Table 3. Connected car threat modeling using the DREAD threat model

Based on the results of our connected cars threat modeling exercise, we make the following observations:•Of the 29 identified attacks on connected cars, about 66% are medium-risk, about 17% are low-risk,
and another approximate 17% are high-risk.

•

The attacks classified as low-risk are the ones that require a high level of technical skills and an indepth knowledge of the connected car platform.

•

The low-risk attacks, given their specialized nature, would realistically affect only a small percentageof everyday connected cars since the attacks are difficult, albeit not impossible, to execute on a
massive scale.

•

Surprisingly, malware attacks on connected cars are rated low-risk. This is probably because an
attacker needs to understand the low-level electrical/electronic (E/E) architecture of a targeted car
prior to launching an attack. It is also not easy to port malware from one car architecture to anotheras their implementations will be vastly different.

•

The high-risk attacks are attacks that require only a limited understanding of the inner workings of aconnected car and can be pulled off by a low-skilled attacker, such as the electronic jamming of RF
modules.

•

The high-risk attacks also include DDoS attacks and the discovery of exposed services and servers
using network-scanning services such as Shodan. Even though the 2015 Jeep hack research found the
D-Bus daemon running on the exposed port 6667 in Sprint’s vehicle network, it still took a high degreeof technical prowess to go from finding the D-Bus daemon to compromising the ECUs. Launchinga DDoS attack on an exposed ITS infrastructure is comparatively easier and could have devastatingconsequences especially if connected cars rely on the ITS infrastructure for driving decisions.

•Sensational attacks such as installing malicious firmware over the air, remotely hijacking vehicle
controls, sending incorrect or improper commands to the ITS back end, and sending spoofed V2X
messages are rated medium- or low-risk. These attacks are difficult to execute because the devices
and the systems are not readily accessible for attacking, and expert skills and knowledge are required
to successfully compromise connected car platforms.

50 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

Exploiting connected cars as an entry point to the ITS back-end network is, also surprisingly, rated
medium-risk. This might be because this attack requires highly skilled attackers who know how tocompromise traditional multilayered IT defenses.

Overall, the risk level of successful attacks on connected cars and V2X-connected ITS infrastructures is
medium. We think that this is because these hypothesized attacks are assessed using the TTPs used byattackers today. When middleware that obfuscates the internal E/E car architecture is made available tothird-party vendors to provide software as a service (SaaS), we expect to see the emergence of new TTPs
that will be of a significantly higher risk level. Also, when attackers create viable monetization methods forconnected cars and ITS infrastructures, another evolution in their TTPs that will lead to higher-risk attacks.

5.4 Objectives and Profiteering Models for
Attacking Connected Cars
The key motivator for the vast majority of cyberattacks that we see daily is financial gain. But not every
perpetrator who attacks a car will be motivated by money. Cars are highly visible and attacks on them will
be high-impact, which itself is a key motivator for many of the perpetrators. We have identified five broad
objectives and profiteering models that motivate perpetrators to attack the connected car ecosystem.

Objectives andprofiteering models

Impacts

Ransom

In the future, it is expected that perpetrators will devise methods of sending
malware to connected cars and disable the car’s functions until the owner pays
the demanded ransom. An OTA ransomware attack that happens while theconnected car is traveling on the road will severely impact the safety of the vehicle’s
passenger(s) and other vehicles on the road.

Data theft

Perpetrators can steal proprietary data, intellectual property, business operations
data, PII, financial data, sales data, customer information, shipment data,
vehicle tracking information, other similar information, and monetize the stolen
data in various ways. The stolen data can be used for identity theft, privacy
violation, financial fraud, industrial espionage, blackmail, people and/or vehicle
reconnaissance, and such.

51 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Objectives andprofiteering models
Information warfare

System gaming andtheft

Revenge and terrorism

Impacts
This is a broad topic that encompasses everything from hacktivism to data pollution
for financial gains. Some of the information attacks that we identified/theorized are:•

DDoS of ITS infrastructure to crash systems and cause roadway chaos.

•

Hacking of OEM apps/websites to post political, protest, or prank messages.
Another agenda could be to hurt the OEM’s reputation and cause them financial
losses.

•Transmitting fake V2V messages to create traffic chaos (when cooperativeautonomous vehicles become roadway reality).

•

V2V information poisoning will become a service where unscrupulous businesses
will pay criminals to poison V2V channels and forcibly reroute autonomousvehicles to their business locations.

•

Map-hacking (done via compromising road-based location transmitters, hacking
on-board GPS receivers or GPS signal spoofing) will cause autonomous vehicles
to veer off course and cause an accident.

One of the most attractive profiteering models for perpetrators will be the theft ofthe vehicles themselves or the goods/valuables inside the vehicles. We identified/theorized the following attacks:•

Hacking and rerouting autonomous trucks to some remote location like an empty
parking lot outside town, where the criminals can break into the trucks and steal
the cargo.

•

Using hacked autonomous vehicles to anonymously deliver contraband items
such as drugs and weapons.

•

Hacking autonomous passenger vehicles and instructing them to reroute andstop at some obscure location. The criminal’s goal is to steal the passengers’
valuables or even abduct someone.

•

Hacking, rerouting, and stopping autonomous vehicles to steal vehicle parts or
the vehicles themselves.

•

Unscrupulous fleet operators (like some autonomous taxi and delivery
service providers) attempting to subvert competition by hacking competitors’autonomous vehicles to make them unavailable.

•

Illegally assigning higher priority to an autonomous vehicle on a dedicatedroadway so that other autonomous vehicles move aside.

•

Making fake orders of autonomous vehicle rideshares to charge unsuspecting
customers.

If the driving functions of autonomous vehicles can be compromised, then there is
every possibility that the vehicles will be used as weapons in terror attacks. Terror
attacks primarily target people, but we surmise that hijacked vehicles can also be
used for attacking critical infrastructures. The terrorists will launch these attacks
remotely, which makes tracking the attackers extremely difficult, if not impossible.

Table 4. Objectives and profiteering models and corresponding impacts for attacking connected cars

52 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

From a cybersecurity perspective, one glaringly obvious reason for hacking connected cars is to use themas an entry point into the greater ITS ecosystem. If an attacker can successfully exploit the car to gain
access into the corporate network, then they can penetrate deep inside the network with minimal effort
because the car is considered a trusted node. Once inside the network, the perpetrators can launch anyof the attacks that we just described.

5.5 Perpetrators Launching Attacks onConnected Cars
Where there are opportunities, there are also perpetrators who attack, leverage, steal, game, and abuse
the system for a wide variety of reasons such as money, revenge, and protest, among others. We havealready examined some of the motivators driving perpetrators to attack connected cars, and in thissection, we discuss the different perpetrators who pose threats to the connected car ecosystem:•

Nation states. Both developed and developing countries gather intelligence using software espionage
tools and customized malware. The primary goal for state-sponsored cyberattacks, based on ourobservation of current attacks, is to steal intellectual property or to gain a competitive advantage. But
in certain instances, for example during a war, these attacks can be used to sabotage another nation’s
infrastructure. State-sponsored attacks follow one of two modi operandi: either The state directly
controls the hacking teams and their resources, or the state outsources the hacking activities to third
parties such as criminal gangs to maintain plausible deniability.

•

Criminal hacking groups. These are composed of highly skilled hacking teams who are funded
and controlled by organized criminal gangs. They target victims using different schemes such as
ransomware, phishing, and other threats to generate illicit revenue. There are also criminal hacking
groups that are contracted by national governments for various political cyberattacks, including
cyberespionage and subterfuge.
1. Hacktivists. Hacktivists are internet activists who attack cyber assets to draw attention to theirpolitical causes. They tend to choose high-visibility, high-profile targets. Often, their targets andtheir stated causes do not match.
2. Cyberterrorists. Their goal is to launch cyberattacks to cause destruction of property, loss of life,
and the spread of terror.

•

Insiders: They are people who act against organizations that they are or were part of. Insiders canbe motivated by money, ideology, coercion, ego, revenge, and politics; often, more than one of thesemotives are at play.

•

Unscrupulous operators. As primary users of vehicles, it is not inconceivable to imagine scenarios
where some drivers and commercial operators try to hack and game the system to save on fines andfees, get ahead in traffic, and stifle competition, among others.

53 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

6. Guidelines for Protecting
Connected Cars
Connected cars are one component of the ITS network, which is a massive, complex, interconnectedecosystem with millions of endpoints and end users. Because of its vastness and the sophistication of its
functions, this ecosystem paves the way for large and at times unpredictable attack surfaces. Protecting
connected cars from remote attacks is not just about securing the car itself. It is also imperative that theend-to-end data supply chain used by connected cars while on the road be secured.
Cyberattack and data breach prevention strategies should be considered as an integral part of daily
business operations for all organizations. Ultimately, no defense is impregnable to determined adversaries— in a nutshell, cyberattacks and data breaches are inevitable. Having effective and active containment
and mitigation processes is critical. The key principle of defense is to assume compromise and to takeadequate countermeasures:109•

Quickly identify and respond to ongoing security breaches.

•

Contain the security breach and stop the loss of sensitive data.

•

Prevent attacks by securing all exploitable avenues.

•

Apply lessons learned to further strengthen defenses and prevent repeat incidents.

54 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Outside vehicle
Network security

Back-end security

VSOC

Connectivity

ServiceBusiness

Mobile (virtual)
network operator

Back end

Management

Figure 22. The connected car architecture outside a vehicle

ECU

Gateway

TCU/IVI

LTE/5G

Telematic
servers

Inside vehicle

OTA
servers

Applications

Outside vehicle

Back end

Carrier
network

VehicleFigure 23. The combined connected car architecture from inside and outside a vehicle

55 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

We have identified four critical areas that are needed in the end-to-end data supply chain for connectedcars:•

The E/E network of the car. This includes the telematics communication box (TCU), the main board
ECU or the in-vehicle infotainment (IVI) system in the head unit, the bus gateway, the buses (suchas CAN, Ethernet, FlexRay, LIN, and MOST), and the different ECUs. The E/E network also includes
external network modules such as the eSIM (which connects to 3G, LTE, 4G, and 5G networks), USB,
Bluetooth, Wi-Fi, RDS, and satellite.

•

The network infrastructures. These handle the millions of connection setup/teardowns and datatransmission which includes telecom infrastructure, home network, and mobiles providing network
connectivity to the cars.

•

The back-end servers. These run the applications, services, and databases that a connected car
directly and indirectly accesses. Examples include ITS servers, app stores, OTA servers, and more.

•

The VSOC. This understands context by correlating notifications from the other three critical areas.

Connected car security needs to be designed with an integrated view of these four critical areas to secure
the end-to-end data supply chain. Now, a point of contention when considering securing the end-to-end
data supply chain for connected cars is: which party will be responsible for data security? Will it be thedrivers of the vehicles? Will it be the manufacturers of the vehicles? Will it be the Tier 1 or 2 supplier? Will
it be the fleet management operator? (Sub-question, what will be the ownership structure for connectedcars?) Will it be a Security-as-a-Service model sold by a third-party security vendor? Will it be a large
corporation like Google or Amazon that is entering the connected car space? Will it be the Telco that is
managing the data pipelines and builds cybersecurity into the cost of the data? Will it be a government
department that implements Security-as-a-Service, similar to national defense, but for connected carsand ITS infrastructure? As is with IT security, the answer is all of the above. The end-to-end data supply
chain has many owners who all need to participate in providing holistic security solutions that work toprotect the connected car ecosystem.
Our insights and recommendations on ISO/SAE 21434 — cybersecurity engineering guidelines for allprocesses across different phases of a vehicle’s life cycle — are available for reference in our research
paper titled “ISO/SAE 21434: Setting the Standard for Connected Cars’ Cybersecurity.”110

6.1 Automotive Defenses Technology
Discussion
Currently, the connected car defenses solution space is slightly unknown since the problems and dangers
associated with it remain quite unfamiliar. Many companies are working on defense solutions that they
think will prevent many of the future threats that connected cars will face. The reality is that many of the

56 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

automotive defense solutions in the market have not thoroughly been tested to their limits simply because
there are not enough connected cars on the road with them, defensive solutions adoption has been slow,
and because cybercriminals have not truly found a business case to attack fleets of connected cars. We
predict that these will change over the next couple of years, and we best be prepared now to prevent any
cyber onslaught against cars.
While thinking about automotive defensive technologies, we decided to start with the different types ofattacks (both demonstrated and theoretical ones) that we discussed in this paper. Here is a quick recapof some of the attack vectors discussed (in no specific order):•Malicious CAN messages transmitted•

SMS used to trigger the telematics unit•

Exploitation of operating systems’ vulnerabilities to compromise systems•

Abuse of default system configurations•

Abuse of exposed IT and ITS infrastructure•

Extract firmware from hardware modules•

Upload of modified/malicious firmware and reflash ECUs•

Exploitation of mobile apps and their back-end servers•

Exploitation of third-party apps installed in the head unit•

Use of middleware APIs to create architecture-agnostic malware•

Use of cloud APIs to compromise car (both third-party and OEM clouds)•

MitM wireless data transmissions•

Electronically jamming radio transmissions

So how do we protect connected cars? In this section, we compiled a list of technologies that we
think will be important in protecting connected cars and for mitigating and lessening the likelihood ofcyberattacks. A solutions technology discussion for securing the connected car ecosystem will yield
different requirements for different stakeholders. This is because the needs of the car owner are different
from the needs of the fleet management operator or the mobile (virtual) network operator that handles
data transmission. Thus, instead of making a case for each stakeholder, we discuss some of the key
defensive technologies that will need to be implemented to ensure connected car security:111•

Vulnerability scanner. This comprises automated tools that scan endpoints, servers, networks, andapplications for security vulnerabilities that an attacker can exploit. This can be used to make sure thehead unit’s operating system doesn’t have any unpatched exploitable vulnerabilities. If there is a zeroday that the vulnerability scanner misses, then that will need to be mitigated with an OTA software
patch.

57 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

Code signing. This is a method of putting a digital signature on a file, software update, or executable
so its authenticity and integrity can be verified by an end party.112 Code signing is a good way ofverifying OTA software updates and firmware integrity.

•

Application security. Security measures at the application level that prevent data or code within theapp from getting stolen or hijacked.113 Application security suites secure against code vulnerabilities,
data exfiltration on the server, and other common vulnerability attacks at the application level.114 Car
apps that can be used to lock/unlock, start/stop the car should have strict security enabled to prevent
exploit.

•Threat intelligence. This is a collection of a wide variety of security data (for example, open-source
intelligence, social media intelligence, deep/dark web intelligence, technical intelligence, user endpoint
feedback, indicators of compromise, vulnerability data, malware data, and others) that is combinedwith the expert analysis of a security researcher with the goal of detecting more hidden threats andachieving fast response times against cyberattacks. Threat intelligence drives many of the security
solutions used in the car.

•

IDS for CAN. These are network security systems that examine traffic flow to detect and prevent
network attacks. IDS are passive systems that generate a report when a known bad event is identified.
IDS for CAN monitors the car’s E/E network for suspicious CAN messages by doing deep packet
inspection.

•

Antivirus scanner for the head unit. The head unit run *nix or Windows Embedded. They run
applications (both OEM and third-party) and can communicate with the gateway ECU which talks tothe car’s ECUs. In this critical environment it makes good sense to have an active antivirus scanner
running as a service. The main challenge will be to find a reliable method for the head unit antivirus
scanner to receive regular OTA updates.

•

Device control. Systems that regulate access to external storage devices and network resources
connected to a computer.115 Device control is normally used to prevent data loss and leakage, but incars it can prevent loading and running malicious executables from external storage devices.

•

Firewall. Firewalls are network security systems that control incoming and outgoing traffic basedon an applied rule set. Firewalls monitor ingress/egress traffic from unknown and bad domains andidentifies applications or endpoints that generate or request bad traffic. This will be mandatory for V2X
traffic policing on the ITS side of the house; it could also be installed on the car side to stop DDoS
attacks on the vehicle.

•

Encryption. In some of the case studies the researchers sniffed and collected CAN messages andthen reverse engineered out what the commands were doing by analyzing the collected data. If there
is a mechanism to encrypt packets in the E/E network with minimal processing overhead, the sniffing
packet data problem would get mitigated.

58 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

Third-party app review. Review and test third party apps to verify they are reliable, safe, notmalicious, doesn’t access ECUs, doesn’t break privacy rules, no broken links, doesn’t crash or havebug, among others. before allowing them to be downloaded and installed by the user in the car. By
strictly controlling the app ecosystem, like Apple does with their iOS devices, the OEMs can prevent
third-party apps from introducing new attack surfaces in the car.

•Read/write protect storage devices. These are storage devices that download OTA firmware updates
and other critical data should be encrypted and have read/write protection enabled to prevent data
dumping.

•

Blockchain. As blockchain solutions for verification become mainstream, it Is possible to have aledger in the E/E network that records and verifies the status of every ECU in the car. If an ECU istampered with, then the faulting ECU can be quickly identified, the driver warned, and corrective
actions taken.

•

EDR (Extended detection and response). This collects and correlates deep activity data acrossmultiple points in data supply chain — vehicle, network, and backend servers — enabling a level ofdetection and investigation. With a view of a combined context, events that seem benign on theirown potentially become meaningful indicators of compromise. This quickly contains the impact andminimizes the severity and scope.

6.2 Solution: Cyber-Telecom Federation and
Zero-Trust
The use of a cyber-telecom federation allows existing IT security investment to be reused, even when
the devices (in this case, cars) being managed are actually from the telecom domain. By managing thisharmonized and federated set of cyber-telecom logs using zero-trust architecture, the fractured security
landscape can reunited. Attacks that are undetected due to disharmonized logging and multiple sourcesof radio data can now be seen and alerted as malicious activity.
To manage a fleet of phones-with-wheels at scale, the systems must have visibility into telecom phonedata (phone numbers and SIM cards, for example) and cyber IT data (IP addresses and certificates).
This cyber-telecom data must also be tied together in a specific way (federation) with the same care andattention that the bolts and other parts of a car are assembled. This cyber-telecom federation allows
existing investment in IT security to apply rules to telecom security events that would otherwise beinvisible to IT security.
Cyber-telecom federation security should also have privileges and conditions that are realistic for theneeds of connected vehicles. As a type of life-critical IoT device, security rules should have recognition for
the impact of over-aggressive security responses. Security architects of these privileges should recognize

59 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

that their rules could result in greater impact on the safety of vehicle passengers. Such impact could
include leaving passengers abandoned in a dead car on the side of the road during winter simply because
malware was detected and aggressive rules were enforced.
When this data is assembled into a cyber-telecom federation, traditional IT assets can perform security
detection on even the telecom (phone numbers and SIM cards) portions of the connected car security
model. This is important since telecom threat actors can control the IT security of mobile devices (which
is dependent on telecom security) from within the telecom security domain through the use of roaming
and home network attacks. The federation can also be used to federate different kinds of IT and telecom
telemetry, and even non-cellular types of V2X traffic.
Cyber-telecom federation grants visibility into mobile device issues such as the ability to respond tochanges in jurisdiction. Different countries could have security laws on wiretapping, money laundering,and data sovereignty, resulting in business requirements that change as a vehicle drives across country
borders. This requires security privileges that will change based on telecom metadata such as location,
implying the need for continuous authentication — a technology that is part of the zero trust architecture(ZTA)116. These technologies are also part of the build path of 6G.
ZTA is present when all information assets are authenticated and there are no trust zones where
authentication does not occur. A version of ZTA is already being used in the telecom domain in systems
that touch SIM cards when roaming.
The relationship between cyber-telecom telemetry and ZTA117 can be used to create unified visibility forconnected car fleet management across its various networks and telemetry layers. ZTA guidance has
recently been released by the National Institute of Standards and Technology (NIST).118
Telecom telemetry and traditional IT telemetry can be brought together harmoniously through the useof a federation. When this cyber-telecom federation is used with ZTA, the method of access control andauthorization can be expanded to include telecom infrastructure security events as well.

60 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Cyber threat
intelligence

Telecom threat
intelligence“Cyberthreat intelligence” refers to typical IT security
metadata (such as IP addresses, among others ).
“Telecom threat intelligence” refers to typical telecom
security metadata, phone numbers, and others.

Policy engine
Data accesspolicyIdentity accessmanagement

Policy decision
point

Policyenforcement point

Public key
encryption
infrastructure“Data access policy” refers to information controls
and what privileges are needed for access.
“Policy engine and policy decision point” refers tosystems responsible for deciding which policies
apply to a particular IAM context.

Vehicle
SIEM“Vehicle SIEM” refers to security information event
management system handling realistic vehicle“Identity and access management (IAM)” refers to
privileges assigned to access data.

Car“Car” refers to any vehicle managed as a member ofa ﬂeet, including cars, drones, or others.

Figure 24. Cyber-Telecom federation

When both ZTA and cyber-telecom federation are used, both telecom crimes and cybercrimes can bemade visible to each other’s systems, allowing IT security products to secure telecom and telecom
security products to secure IT.
A CyTel-federated ZTA can also apply telecom alerting (such as location or jurisdiction) to data sovereignty
compliance or other issues such as telecom fraud, SIM-jacking, and other attacks. This can then provide
very customized responses that recognize the special considerations needed when managing the securityof life-critical mobile devices such as cars.
In this way, a vehicle security operations center (VSOC) can leverage SIEM, SIM card authentication,
traditional cyberthreat intelligence, GSMA information, and other sources interchangeably. An enterprise
can therefore re-use its investment security investment across multiple infrastructures without having to
reinvent the wheel for each.

6.3 Recommended Approach for Connected
Car Security
To limit the possibility of a successful remote hack on a connected car, we prescribe a comprehensive
cybersecurity strategy that takes the entire connected car ecosystem into account: vehicle, network, backend, and VSOC.

61 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

For the Vehicle
The Trend MicroTM IoT Security for Automotive solution119 monitors and protects critical devices
connecting the in-vehicle and outside networks, such as telematic control units (TCUs) and IVI systems,
while CAN Bus Anomaly Detection monitors traffic in the CAN bus and reports the status to the VSOC.
By linking to Trend Micro’s threat intelligence system, they can quickly detect security risks and protect
connected cars — along with their systems, applications, and CAN bus — from ever-growing threats.

For the Network
Trend Micro Mobile Network Security (MNS)120 can be used to keep the network that connects the vehicle,
the back-end cloud, and the data center secure. It comprises two key components: First, building on
the ETSI NFV framework, it applies appropriate network security protocols to monitor, detect, and takecountermeasures against threats. Second, it provides comprehensive endpoint security for IoT devices in
two form factors — a physical SIM card and a software Java applet.

For the Back End
Among the various connected technologies used by connected cars are applications and systems hostedon the cloud. And many more of these applications and systems are bound to be built as the adoption ofconnected cars continues to grow. The Trend Micro™ Cloud One™ security services platform121 can beused to secure back-end cloud and data center environments without affecting performance. Throughthe Trend Micro™ Zero Day Initiative™ program, it can detect and disclose vulnerabilities to keep cloudenvironments secure, especially since it is common for new and evolving technologies to have known
and unknown vulnerabilities. The platform also continuously analyzes and identifies new malware,ransomware, and IOCs that could be used in attacks. In addition to ITS back-end systems, ITS endpoints
need to be secured. The Trend Micro IoT Security™ solution122 can be used for this purpose. It uses threat
intelligence from the Trend Micro™ Smart Protection Network™ infrastructure to provide risk/anomaly
detection and in-system protection for a wide range of IoT devices, including traffic lights and surveillancecameras.

For the VSOC
To ensure that the VSOC is able to correlate events quickly and effectively, the Trend Micro™ XDR®
service can be used. It passes analyzed, correlated, and visualized events from the endpoint, the network,and the back end, with individual notifications for each.123 It provides a comprehensive look at events
alongside vital contextual data, thereby helping organizations identify and thwart threats.** As of February 2021, Trend Micro XDR is limited to certain Trend Micro products.

62 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

7. Connected Car Security in
MotionMore than 125 million passenger cars with embedded connectivity are forecasted to ship worldwide
between 2018 and 2022,124 and the annual production of semi- and fully autonomous vehicles are
expected to reach more than 14 million by 2025.125 The sheer volume of network-connected cars willboth create and increase new attack surfaces for the ITS ecosystem. In this paper, our goal is to explore
potential new cyberattacks against connected cars. By analyzing the technology used in cars today andin the connected car future roadmap, we derived a host of interesting attacks that are not being actively
discussed.
Connected cars will be connected via either 5G or dedicated short-range communication (DSRC) to V2X
and will probably become one of the heaviest users of cloud infrastructure. Future cars will have part oftheir E/E architecture transferred to the cloud and communicating back to the vehicle via high-speed, lowlatency networks. The connected cars with their all-digital cockpits will support a rich ecosystem of thirdparty apps that will provide a host of functionalities to the drivers and passengers. This opens up many
interesting attack scenarios on connected cars via cloud infrastructure attacks or through architectureagnostic middleware and/or cloud APIs. These threats do not stop at individual cars, but can also be
extended to attack fleets of vehicles potentially hijacking fleet control and causing havoc on the roadways.
The remote attacks on connected cars that we see today use complex chains of vulnerabilities tocompromise the vehicles. As the connected car technology stack evolves, we fully expect IT attacks andthe everyday malware monetization machine to quickly adapt to a connected car’s ecosystem to generate
new revenue streams for cybercriminal enterprises.
Finally, by plotting and measuring the risks in connected cars using the DREAD threat model, we determinedthat the simplest attacks, such as electronic jamming, exploitation of device misconfigurations, DDoS, andothers are far more damaging than seemingly sensational attacks such as installing malicious firmware
OTA, and remote hijacking of the CAN Bus, among others. In a nutshell, we conclude that cloud andmiddleware or cloud-APIs will not only be a connected car’s greatest assets but also its weakest links.

63 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Given the high level of expectations from connected cars and their potential vulnerabilities, it is important
to ensure that automotive cybersecurity technologies stay ahead of adversary TTPs; this is the Red
Queen hypothesis126 where security researchers are in a never-ending arms race with cybercriminals.
There is no doubt that there will be a duplication of defensive technologies across the many owners of
the end-to-end data supply chain for connected cars. This is a good thing for two reasons: First, data
owners will purchase security products from multiple vendors, and multiple vendors of similar products
will increase the likelihood of catching malicious activity. Second, multilayered defenses will makeit increasingly difficult for attackers to succeed. Ultimately though, almost no defense is impregnableagainst determined adversaries, but the multilayered approach increases the time, cost, and resources
needed by an adversary to mount a successful attack. By making the ROI low compared with the cost of
hacking, connected car OEMs and operators can successfully deter most attackers.
This research paper was meant to be a thought paper that aimed to realistically predict what threatsagainst connected cars and their ecosystem will look like. Many of the attacks that we have describedhave not occurred yet or have only been demonstrated by security researchers as proofs of concept. Our
predictions and insights into future threats against connected cars have a two-fold goal: First, we wanted
to inform the OEMs, T1 and T2 suppliers, and the general public about the threats and challenges they aregoing to face on the roadways in the next couple of years; and second, by identifying and addressing the
cybersecurity risks faced by connected cars in the early developments stages, we have the opportunity to
influence both legislative and technological developments in this domain. Developers and manufacturers
must include security as a basic design element in the various technologies that go into connected cars.
This will give them better visibility into the connected car ecosystem and enable them to quickly identify,
isolate, and mitigate any incoming threats and keep cars running safely on the roadways.

64 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Appendix
Appendix A: Case Studies of Remote Attacks
In this section, we look at four case studies on remote attacks on connected cars where at least one
ECU in the target car was successfully compromised, allowing attackers to tamper with vehicle functions.
Our goal is to explore the TTPs used by the attackers to remotely compromise their target vehicle ECUs.
These TTPs indicate the limitations of what can or cannot be hacked, and the level of difficulty in hacking
today’s connected cars. These findings, combined with our expertise in cybersecurity, helped us createa threat model for connected cars that original equipment manufacturers (OEMs), their Tier 1 (direct) andTier 2 (indirect) suppliers, government agencies, and everyday drivers will need to contend with.

The Jeep Hack 2015
“Remote Exploitation of an Unaltered Passenger Vehicle,”127 a 2015 paper by Charlie Miller and Chris
Valasek on car hacking involving Chrysler’s Jeep, was a seminal car hacking research that ultimately led to
the recall of 1.4 million Chrysler vehicles.128 The researchers found the Class A address space used by the
US telecommunications company Sprint for connected vehicles and discovered that a D-Bus message
daemon was running on the exposed port 6667 in the car, which was open to receiving unauthenticatedcommands via Telnet. The researchers sent commands using remote procedure call (RPC) methods
supported by the D-Bus daemon and successfully rooted the head unit of the target Jeep vehicle.

Wi-Fi

USB

BluetoothSprint 3G(port 6667)

Head unit = UConnect
Arm Cortex A8 + QNXProgram the V850
gateway chip using
the OMAP chip.

Be able to already control
radio, HVAC, GPS location,
display, etc., and perform
non-CAN attacks by hacking
the OMAP chip.

OMAP
DM3730

SPI

Reverse-engineer theV850 ﬁrmware to
ﬁgure out what
functions to modify to
be able to talk to the
CAN bus.

Flash the V850 ﬁrmware via the
OMAP over 3G to make it a true
wireless attack. The V850
ﬁmrware is NOT signed and the
updated image is not validated
or veriﬁed.

V850 ES/FJ3
Renesas(CAN gateway)

CAN-IHS
CAN-C

Send CAN
messages via
SPI from the OMAP
to the modiﬁed
V850.

An automated reboot of thesystem is needed for the
new ﬁrmware to be active.
This could brick the head
unit if done incorrectly.

Figure 25. The attack chain of the Jeep Cherokee remote hack of 2015

65 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

The following are some of the interesting findings from their paper:•

The researchers selected the Jeep Cherokee 2014 because it offered the best opportunity for a
successful hack.129•

The head unit can speak with both CAN-IHS (CAN Interior High Speed) and CAN-C (CAN Critical)
networks. Critical systems are not on separate buses physically within the Jeep network architecture;
the Jeep network architecture is essentially a flat network with no domain segregation.

•

The vehicle’s head unit, Jeep® UConnect,130 was found to be “jailbreakable” using the USB, but thatmethod was ultimately not needed in the successful hacking of the car.

•Access via Wi-Fi, while possible, is not ideal, since an attacker needs to be within a specific distancefrom the vehicle. The researchers cracked the Wi-Fi password by reverse-engineering the password
generation algorithm, but this method was found to be tedious.

•

Access via cellular (3G) network is best, since an attacker can be outside of visual range and will
still be able to control the vehicle. It was found that access via a femtocell,131 a small and low-range
cellular base, is limited to 30 meters, and that it was better to use Sprint’s nationwide cellular network.

•

The D-Bus message daemon running on the open port 6667 can receive unauthenticated commands
via Telnet. The researchers sent commands via command-line injection via RPC methods supportedby the D-Bus.

•

The researchers found that Sprint’s network allows any Sprint device to talk to another Sprint device
over any distance as long as both are connected to Sprint’s network. No device blocking was
found to be active; it was as though the devices were on a national-scale WAN (wide area network).
Theoretically, the researchers could create a network worm that could traverse and infect all Sprintconnected cars via the D-Bus daemon running on the exposed port 6667.

•

The researchers downloaded the firmware for the Renesas V850 microprocessor and the OMAP(Open Multimedia Applications Platform) processor from Chrysler. They reverse-engineered andmodified the V850 firmware. The OMAP is able to update the V850 firmware, and that was how they
uploaded the modified firmware.

•

The researchers rewrote parts of the SPI in the V850 firmware and inserted their shellcode. This wouldinterpret the SPI messages as CAN messages and broadcast them to all CAN bus-connected ECUs.

•

The researchers reverse-engineered the wiTECH mechanics toolkit,132 a technology that allows
technicians to diagnose and fix vehicles remotely, to find out how to unlock ECUs and sniff vendorspecific CAN messages.

•

The researchers reverse-engineered the algorithm to checksum CAN messages so that they looked
legitimate to the vehicle ECUs. A checksum is used to ensure the authenticity of and check for errors
in a message.133

66 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies•The researchers reverse-engineered the algorithm to unlock an ECU for reprogramming. It turned outthat their target ECU — the parking assist module, which reads CAN messages for manipulating thesteering function — was also a V850 chip. Because the researchers were familiar with this architecture,
the algorithm reverse engineering was relatively easier.

•

The researchers figured out the CAN messages that kill the engine, disable the brakes, and turn thesteering wheel. They then figured out how to rewrite CAN messages from the real ECUs or deactivate
these ECUs so that their malicious CAN messages got executed instead.

The Tesla Hack 2016
A Tesla vehicle is a computer on wheels. It packs technologies for powertrain, battery, user interface, andconnectivity that are years ahead of the competition.134 But even a sophisticated, well-designed computer
network has its shortcomings — and that is what a team of researchers at Tencent Keen Security Lab
proved with their successful exploitation of a Tesla Model S in 2016.135 They used a complex chainof vulnerabilities to compromise the components inside the car and ultimately succeeded in injecting
malicious CAN messages into the CAN bus.

Set up a fake Tesla Guest
SSID and force the car toconnect to the custom
domain.

Trigger two vulnerabilities in
WebKit to achieve arbitrarycode execution (custom
shellcode).

Exploit an old Linux kernel
vulnerability to gain accountprivilege escalation and thendisable AppArmor.

Modify the gateway ﬁrmware,change the CRC values to
bypass integrity veriﬁcation,and force an update bysending messages on the
diagnostic port 3500.

Physically disassemble the
CID to ﬁnd the unprotected
SD card that stores OTA
ﬁrmware updates.

Gain root access to the CID
and access the IC, the Parrot
module, and the CAN bus
gateway.

SSH

IC

Send fake CAN messages
via UDP over ports 20100
and 20101 using thediagtask function.

Block car speed CAN
messages from being
broadcast by modifying the
ECU target ID.

Disable the ESP, the ABS, andthe power-assisted systems in
the chassis by injecting UDS
data frames through thegateway, and disable ECUs at
low speeds.

TelnetParrot(Bluetooth, Wi-Fi)

Backdoor

CAN busgateway

Flash the IC ECU with custom
ﬁrmware that captures CAN
messages and allows
extraction of ECU unlocking
seeds, enabling privileged
operations directly by address.

Send the ECUs into a special
diagnostic mode that stops
them from sending CAN
messages and responding torequests.

Figure 26. The attack chain of the Tesla Model S remote hack of 201667 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

The following summarizes the attack chain that the researchers used to compromise the Tesla Model S:136•

All Tesla vehicles are configured to automatically connect to SSID Tesla Guest, a Wi-Fi hotspot
provided by Tesla body shops and superchargers. The researchers set up a fake Tesla Guest hotspot
and forced the car to connect to their custom authentication domain.

•

The user agent of the Tesla vehicle uses the web browser engine WebKit.137 The researchers triggered
two vulnerabilities in WebKit to achieve arbitrary code execution by adding a custom shellcode to thescript and get a remote shell.

•

The researchers exploited an old, unpatched Linux kernel vulnerability, CVE-2013-6282,138 to gain ahigher privilege than the one granted to the browser. The researchers then disabled the kernel security
module AppArmor.139•

Privilege escalation grants root access to the central information display (CID). Pivoting from theCID, the researchers gained access to the instrument cluster (IC) via SSH (Secure Shell),140 the Parrot
module (Bluetooth and Wi-Fi) via Telnet, and the CAN bus gateway via a custom backdoor.

•

The researchers physically disassembled the CID and found a 4 gigabyte (GB) SD card inside it
without any read/write protection. This SD card stores the OTA firmware updates sent by Tesla to theTesla Model S.

•

The researchers isolated and modified the gateway firmware in the OTA firmware package, changed
the cyclic redundancy check (CRC)141 values to bypass integrity verification, and forced a firmware
upgrade by sending messages to the diagnostic port 3500.

•

The gateway sends CAN messages over ports 20100 and 20101. The researchers used their modified
gateway firmware to send malicious CAN messages via UDP (User Datagram Protocol)142 on these
ports using the diagtask function.

•

As a safety precaution, the Tesla Model S ignores certain CAN bus messages when the vehicle speed
is above a set limit. The researchers blocked the vehicle speed CAN messages from being broadcast
by modifying the ECU target ID.

•

The researchers flashed the IC ECU with custom firmware that captured CAN messages and allowed
them to extract the ECU unlocking seeds. ECU unlocking enabled them to perform privileged
operations, such as read/write memory, directly by address.

•

At this point, the researchers were now able to send the ECUs into a special diagnostic mode thatstops the ECUs from sending CAN messages and responding to requests.

•

The researchers disabled the electronic stability program (ESP), the antilock braking system (ABS),143
and the power-assisted systems in the chassis by injecting UDS (Unified Diagnostic Services)144 data
frames through the gateway, and disabled ECUs at low speeds.

68 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

Tesla Hack 2017
Keen Security Lab did a follow-up investigation in 2017 to see whether the Model S issues had been
resolved after Tesla fixed the reported vulnerabilities. Not surprisingly, they managed to once again
compromise the S Model. The truth of the matter is that any complex system, no matter how wellengineered, can have design flaws that an enterprising and dedicated hacker can discover and exploit.

Set up a fake Tesla Guest
SSID and force the car toconnect to the custom
domain.

Trigger a vulnerability in
WebKit to achieve arbitrarycode execution (custom
shellcode).

Exploit a new Linux kernel
vulnerability to gain accountprivilege escalation and thendisable AppArmor.

Exploit the default
implementation of FatFS r0.09
to upload modiﬁed ﬁrmwarethat bypasses Tesla’s
code-signing protection.

Physically disassemble the
CID to ﬁnd the unprotected
SD card that stores OTA
ﬁrmware updates.

Gain root access to
the CID.

Reprogram two ECUs andmodify the trigger conditions of
Tesla’s Easter egg program tomake the car sing and dance.
Figure 27. The attack chain of the Tesla Model S remote hack of 2017

The following summarizes the attack chain that Keen Security Lab used to compromise the Tesla Model
S and the Tesla Model X:145•

The researchers again used the same initial attack vector. They set up a fake Tesla Guest hotspot toforce the car to connect to their custom authentication domain.

•

The researchers reused another attack vector via WebKit. This time, though, they needed to exploit asingle vulnerability in WebKit, instead of two, to achieve arbitrary code execution by using a custom
shellcode and get a remote shell.

•

Tesla had upgraded the Linux kernel, so using known vulnerabilities would not work. However, theresearchers found a new Linux kernel vulnerability to gain account privilege escalation. They werethen able to disable AppArmor.

•

Privilege escalation also granted the researchers root access to the CID. They physically disassembled
the CID again to gain access to the 4 GB SD card. They found that it still did not have any read/write
protection.

•

Tesla implements code-signing protection to prevent its firmware from getting overwritten. By
exploiting the default implementation of FatFS146 r0.09, the researchers uploaded modified firmwarethat bypassed or defeated Tesla’s code-signing protection.

69 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•Tesla cars have software and hardware Easter eggs that include holiday, video game, and movie
themes.147 The researchers reprogrammed a holiday-themed Easter egg to demonstrate thesuccessful hack. They reverse-engineered and reprogrammed two ECUs and modified the Easteregg trigger conditions to make the Tesla vehicle sing and dance (with the gullwing doors on the ModelX). Hacking the Easter egg demonstrated that it is possible to reprogram multiple body control ECUs.

•

In addition to reprogramming the Tesla Easter egg, the researchers compromised Tesla’s AutoPilot
ECU (APE).148 They wrote and released a separate research paper on it,149 but it is not covered in our
research.

BMW Hack 2018
After hacking Tesla vehicles for two consecutive years, Keen Security Lab shifted their focus to hacking
BMW vehicles.150, 151 They created three attack chains: one for a local attack via the USB/OBD-II152 port
and one each for two remote attacks. Because our research is on connected cars, we focused on the tworemote attack chains.
USB

Bluetooth

NBT head unit

TCB
Rex RTOS
Qualcomm MDM6200

HU-Intel QNX OS(Intel x86)

USB

Qnet

Multimedia andConnectedDrive

UART

Handles CAN bus
communications
Ethernet

Autosar OS
FreeScale 9S12X

HU-Jacinto(TI Dra44x ARM9262J)

K-CAN4

Central gateway
K-CAN4
Dedicated CAN bus
for infotainment

OBD-II

Figure 28. The attack chain of the BMW remote hack of 2018

The first remote attack chain achieved remote code execution (RCE) in BMW ConnectedDrive153 via HTTP
traffic intercept. It worked as follows:•

BMW’s ConnectedDrive service in the HU-Intel service periodically polls BMW’s back-end servers via
2G or 3G connection of the TCB154 over HTTP. The researchers set up a fake GSM155 base station tointercept all GPRS traffic from the vehicle.

70 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies•The researchers captured a provisioning file that the vehicle downloads and found the online news
URL that ConnectedDrive loads. By forcing the car to connect via their fake GSM base station, they
served a custom provisioning file with the online news URL modified with their custom domain.

•

The online news functionality was processed by the in-car browser, which ran an older version of
WebKit. Exploiting a vulnerability in WebKit resulted in a browser shell. By exploiting a time-of-checkto-time-of-use (TOCTOU)156 race condition vulnerability, the researchers achieved privilege escalation.

•

The researchers gained root access to the firmware via the HU-Jacinto chip, which handles all of the
CAN bus communications. They managed to do this by logging in to it from the HU-Intel network
through Qnet, a protocol for distributed networking,157 without any authentication.

•

Finally, the researchers dynamically hooked the function CanTransmit_15E2F0 to send arbitrary CAN
messages to the ECUs

The second remote attack chain is more interesting and complicated. It exploits the TCB via unsecured
SMS as follows:•

BMW’s NGTP (Next-Generation Telematics Protocol)158 allows the back-end server to wake up thecar, trigger remote services, and trigger a provisioning update. NGTP messages are encapsulated
either in HTTPS or in SMS.

•

Using the previously set up fake GSM base station, the researchers sent two SMS messages
encapsulating NGTP messages. There was no need to know the TCB’s phone number since the car
was connected to the hacker-controlled base station. The first SMS message woke up the car’s TCB,
and the second triggered the provisioning update over HTTP.

•

The provisioning file was an XML file that had a signature stored in hex format and was “un-hexified”
during signature verification. The researchers crafted a special signature that caused a buffer overflow
and allowed them RCE in the TCB’s REX Operating System, a real-time operating system (RTOS).159•

In the TCB, the Last State Call (LSC) task gathers vehicle status messages via UDS messages stored
in a global buffer. Because they could perform RCE, the researchers could overwrite this global buffer
with malicious UDS messages. After the LSC task was triggered, they were able to send malicious
UDS messages via the TCB to the central gateway.

•

The BMW has multiple CAN buses in the network architecture for domain isolation, with the central
gateway handling all of the message-switching tasks for the targeted ECUs. The central gateway canforward UDS messages to do remote diagnostics by embedding a UDS message in a CAN message.
By changing the target ID of the UDS message, the researchers were able to use the central gateway
to send malicious UDS messages to any ECU.

71 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies•The researchers were able to reset any ECU of their choosing via the malicious UDS messages whilethe vehicle was in motion because there are no speed checks for UDS. They could also change thedriver’s seating position remotely.

Appendix B: V2X Attacks
While most of our discussions have revolved around 5G and C-V2X, there is a competing standard for
V2X – IEEE 802.11.p.

Big Data

Other road users

Infrastructure

4G
LTE

Cellular
802.11p
4G
LTE

4G
LTE

Figure 29. A side-by-side comparison of IEEE 802.11p and cellular connectivity for connected cars160
Image credit: Siemens

DSRC based on 802.11p is ready for V2X deployment and addresses most V2X use cases. That meansthat the cost of deployment is low versus waiting for years to deploy 5G solutions. V2V with cellular would
require the car to communicate to the backend to talk to the car in front, whereas DSRC will allow directcommunications. We think a hybrid system where the system-on-a-chip supports both C-V2X and DSRC
will be the preferred solution. The main drawback for the Wi-Fi system is QoS guarantees and latency
requirements might not get fulfilled as they do in 5G based C-V2X solution.

72 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

B.1 Use Cases for V2X
Assuming that C-V2X and DSRC (802.11p) are both viable V2X solutions and they are implemented on an
SoC and become a standard for connected cars, then the next big question is, what are V2X use cases?
Dr. Yunpeng Zang presented five V2X use cases161 at the ninth European Telecommunications Standards
Institute (ETSI) ITS Workshop in March 2018. Michael Gundlach of Nokia also shared insights at the 10thETSI ITS Workshop.162 These findings are summarized here:•

Cooperative maneuvering. This is the coordination of maneuvers, including intentions and planned
trajectories. An example of this would be how vehicles coordinate during the merging of lanes at
highway entrances or exits.

Figure 30. Cooperative maneuvering163
Image credit: 5GCAR•

Cooperative perception: This is the sharing of data amongst vehicles and/or infrastructure. The data
is gathered from various sources like radar, lidar, and on-board cameras, among others, and is shared
via wireless connections such as 5G or 802.11p.

Figure 31. Cooperative perception164
Image credit: 5GCAR

73 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

Cooperative safety. This pertains to the cooperative sharing of data on the presence of pedestrians
on the road. Data is gathered through sensors, cameras, radars, lidar, and other sources. Upon
detecting the presence of pedestrians on the street, the drivers can be informed through messages.

Figure 32. Cooperative safety165
Image credit: 5GCAR•

Autonomous navigation. This involves building a real-time intelligent HD map through the datacollected by vehicles. This data contains specific and detailed information such as road structuresand landmarks, among others.

Figure 33. Autonomous navigation166
Image credit: 5GCAR

74 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

Remote driving. This involves receiving data from vehicle sensors, maps, and infrastructure
information. Wireless communication also enables the control of some components of the car, likethe steering wheel, from outside the vehicle through wireless communications. Tesla already does
something similar with their Smart Summon.167, 168

Figure 34. Remote driving169
Image credit: 5GCAR

B.2 Attacks on Vehicular Ad Hoc Networks
Connected cars — and in the future, autonomous vehicles — will become the primary roadway users. Oneof the key technologies connected vehicles will use is vehicular ad hoc networks (VANETs). VANETs arecomprised of smart vehicles and roadside units (RSUs), which communicate through unreliable wirelessmedia. Because of their ad hoc nature, VANETs are susceptible to attacks that can jeopardize roadway
safety, especially when vehicles depend on VANET data for making critical driving decisions. In thissection are the summarized VANET attack vectors described by Fatih Sakiz and Sevil Sen in their paper
titled “A Survey of Attacks and Detection Mechanisms on Intelligent Transportation Systems: VANETs and
IoV.”170 VANET attacks are primarily network attacks with the connected cars acting as dynamic nodes in
the network.

75 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

Sybil attack. This is characterized by a node (vehicle) that assumes more than one identity. Due tothis, other vehicles in the network cannot verify if the received data originates from one or multiple
vehicles. Sybil attacks are difficult to detect.

Attacker pretending
to be Car A, B, C whentalking to Car X

Attacker pretending
to be Car A, B, C, D
when talking to Car Y
Car Y

Car X

Attacker

Figure 35. A Sybil attack•

DDoS attack. This overwhelms a system with more requests than it is designed to handle. This
causes the system to crash or become unavailable. In VANETs, attackers can interrupt vehicles and
RSUs.

Figure 36. A DDoS attack

76 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•Blackhole attack. This attack takes place in an ad hoc co-operative network. The attacker node
manipulates other nodes into routing their data packets through the attacker. The attacker thenintentionally discards the data packets, resulting in communication loss in the network. Another result
is that other vehicles do not receive crucial roadway information.

These cars do notreceive current roadcondition information

Attacker

Force routing
via attacker

Figure 37. A blackhole attack171
Image credit: Fatih Sakiz and Sevil Sen•

Wormhole attack. This occurs when two or more compromised nodes involve themselves in manyrouting requests. They then communicate the false information that they know through the shortest
way to a given point. This is designed to alter the topology or arrangement of the network and route
all routing requests through themselves to gather and/or control network traffic.

Figure 38. Wormhole attack
Image credit: Fatih Sakiz and Sevil Sen172

77 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

•

False information attack. This happens in VANET vehicles that use data generated or forwarded byother vehicles or RSUs. The received or forwarded data might not be true; an attacker vehicle cangenerate false data and send it to the VANET. Common false information attacks include:ºFake location information, where vehicles can broadcast fake location data. This is a serious
problem because safety-related applications or systems that rely on accurate vehicle location
data will respond incorrectly. Also, false location information will result in data packet loss, as
packets will be forwarded to phantom vehicles. The vehicles could also broadcast spoofed, fakeGPS data with a strong signal that overrides the actual GPS signal, thus causing navigation units
to get confused and falter.

º

Sensor deception, where by simulating false driving conditions, attackers can deceive in-vehicle
sensors. For example, by braking repeatedly over a short distance, the attacker can simulate a
traffic jam on the road, causing a car to incorrectly broadcast a traffic jam message.

•

Replay attack. Here, messages can be stored to be broadcasted later, when the message is nolonger valid. This is meant to mislead or deceive other nodes in the network. The attack aims torecreate and exploit the conditions at the time the original message was sent by rebroadcasting thestored message.

Attacker broadcasts
the collision message
at another time

Attacker

Attacker

Sending the collision incident
message at a different time
will change the behaviourof the trafﬁc incorrectly

Figure 39. A replay attack173
Image credit: Fatih Sakiz and Sevil Sen•

Passive eavesdropping attack. This refers to monitoring the network to track vehicle movement orcommunications. The attacker node simply intercepts and analyzes the messages that pass throughthe network. The attacker’s goal is to gather information about vehicles and their communication
patterns for future use.

78 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

References
1

Phil LeBeau. (July 30, 2019). CNBC. “Relax, experts say it’s at least a decade before you can buy a self-driving vehicle.”
Accessed on June 23, 2020, at https://www.cnbc.com/2019/07/29/experts-say-its-at-least-a-decade-before-you-can-buy-aself-driving-car.html.

2

Numaan Huq, Craig Gibson, Rainer Vosseler. (n.d.). Trend Micro. “Driving Security in Connected Cars.” Accessed on Jan. 11,
2021, at https://documents.trendmicro.com/assets/white_papers/wp-driving-security-into-connected-cars.pdf.

3

Kaya Ismail. (Nov. 14, 2018). CMSWire. “Connected Car Experiences in 2019: Exploring the Possibilities.” Accessed on July 8,
2020, at https://www.cmswire.com/digital-experience/connected-car-experiences-in-2019-exploring-the-possibilities/.

4

Anshul Axena. (Aug. 17, 2018). eInfochips. “Everything You Need to Know About In-Vehicle Infotainment Systems.” Accessedon July 8, 2020, at https://www.einfochips.com/blog/everything-you-need-to-know-about-in-vehicle-infotainment-system/.

5

Sarwant Singh. (Nov. 11, 2019). Forbes. “Connected & Autonomous Cars Have Arrived, And They Are Forcing
Car Companies To Build New Vehicle Architectures.” Accessed on July 8, 2020, at https://www.forbes.com/sites/
sarwantsingh/2019/11/11/connected--autonomous-cars-have-arrived-and-they-are-forcing-car-companies-to-build-newvehicle-architectures/?sh=415175052cb1.

6

David Zax. (Dec. 3, 2012). MIT Technology Review. “Many Cars Have a Hundred Million Lines of Code.” Accessed on June 23,
2020, at https://www.technologyreview.com/2012/12/03/181350/many-cars-have-a-hundred-million-lines-of-code/.

7

Jim Motavalli. (Feb. 4, 2010). The New York Times. “The Dozens of Computers That Make Modern Cars Go (and Stop).”
Accessed on June 23, 2020, at https://www.nytimes.com/2010/02/05/technology/05electronics.html.

8

Kvaser. (n.d.). Kvaser. “Introduction to the LIN bus.” Accessed on June 24, 2020, at https://www.kvaser.com/about-can/canstandards/linbus/.

9

Evaluation Engineering. (June 1, 2014). Evaluation Engineering. “Entertainment rides the MOST bus.” Accessed on June 24,
2020, at https://www.evaluationengineering.com/instrumentation/article/13009506/entertainment-rides-the-most-bus.

10 Bob O’Donnell. (June 28, 2016). USA Today. “Your average car is a lot more code-driven than you think.” Accessed on June23, 2020, at https://www.usatoday.com/story/tech/columnist/2016/06/28/your-average-car-lot-more-code-driven-thanyouthink/86437052/.
11 Robert Bell. (Oct. 13, 2018). Space News. “Satellites and the Connected Car.” Accessed on June 23, 2020, at https://spacenews.com/satellites-and-the-connected-car/.
12 Loren Grush. (March 24, 2020). The Verge. “The true impact of SpaceX’s Starlink constellation on astronomy is coming
into focus.” Accessed on June 23, 2020, at https://www.theverge.com/2020/3/24/21190273/spacex-starlink-satelliteinternetconstellation-astronomy-coating.
13 Tesla. (n.d.). Tesla. “Support: Connectivity.” Accessed on June 23, 2020, at https://www.tesla.com/support/connectivity.
14 B.E. Bilgin and V.C. Gungor. (Nov. 6, 2013). International Journal of Vehicular Technology. “Performance Comparison of IEEE
802.11p and IEEE 802.11b for Vehicle-to-Vehicle Communications in Highway, Rural, and Urban Areas.” Accessed on June23, 2020, at https://www.hindawi.com/journals/ijvt/2013/971684/.
15 Charles McLellan. (Nov. 4, 2019). ZDNet. “What is V2X communication? Creating connectivity for the autonomous car era.”
Accessed on June 23, 2020, at https://www.zdnet.com/article/what-is-v2x-communication-creating-connectivity-for-theautonomous-car-era/.
16 National Highway Traffic Safety Administration (NHTSA). (n.d.) National Highway Traffic Safety Administration (NHTSA).
“Automated Vehicles for Safety.” Accessed on June 23, 2020, at https://www.nhtsa.gov/technology-innovation/automatedvehicles-safety.
17 Tesla. (n.d.). Tesla. “Support: Autopilot and Full Self-Driving Capacity.” Accessed on June 23, 2020, at https://www.tesla.com/
support/autopilot.
18 Kyle Field. (Aug. 3, 2020). CleanTechnica. “Tesla Achieved The Accuracy Of Lidar With Its Advanced Computer Vision
Tech.” Accessed on Jan. 11, 2021, at https://cleantechnica.com/2020/04/24/tesla-achieved-the-accuracy-of-lidar-with-itsadvanced-computer-vision-tech/.
19 BBC News. (Sept. 16, 2020). BBC News. “Uber’s self-driving operator charged over fatal crash.” Accessed on Jan. 11, 2021,
at https://www.bbc.com/news/technology-54175359.

79 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

20 Numaan Huq, Rainer Vosseler, and Morton Swimmer. (2017). Trend Micro. “Cyberattacks Against Intelligent Transportation
Systems: Assessing Future Threats to ITS.” Accessed on June 23, 2020, at https://documents.trendmicro.com/assets/white_
papers/wp-cyberattacks-against-intelligent-transportation-systems.pdf.
21 MITRE ATT&CK®. (Sept. 16, 2020). MITRE ATT&CK®. “ATT&CK®.” Accessed on Jan. 11, 2021, at https://attack.mitre.org.
22 Trend Micro Security News (n.d.) Trend Micro Security News. “Cybercriminal Underground.” Accessed on Jan. 11, 2021, at
https://www.trendmicro.com/vinfo/us/security/news/cybercriminal-underground.
23 Dr. Charlie Miller and Chris Valasek. (Aug. 10, 2015). Illmatics. “Remote Exploitation of an Unaltered Passenger Vehicle.”
Accessed on June 24, 2020, at http://illmatics.com/Remote%20Car%20Hacking.pdf.
24 Tencent Keen Security Lab. (March 3, 2020). Keen Security Lab Blog. “Tencent Keen Security Lab: Experimental Security
Assessment on Lexus Cars.” Accessed on June 24, 2020, at https://keenlab.tencent.com/en/2020/03/30/Tencent-KeenSecurity-Lab-Experimental-Security-Assessment-on-Lexus-Cars/.
25 Kevin Mahaffey. (Aug. 7, 2015). Lookout Blog. “Hacking a Tesla Model S: What we found and what we learned.” Accessed onJune 24, 2020, at https://blog.lookout.com/hacking-a-tesla.
26 Matthew Greenwood. (June 29, 2020). Engineering.com. “Chinese Automaker Plans Satellite Network to Support Autonomous
Vehicles.” Accessed on July 20, 2020, at https://www.engineering.com/AdvancedManufacturing/ArticleID/20027/
ChineseAutomaker-Plans-Satellite-Network-to-Support-Autonomous-Vehicles.aspx.
27 Scott Campbell. (n.d.). Circuit Basics. “Basics of the SPI Communication Protocol.” Accessed on June 24, 2020, at https://www.circuitbasics.com/basics-of-the-spi-communication-protocol/.
28 Scott Campbell. (n.d.). Circuit Basics. “Basics of the UART Communication.” Accessed on June 24, 2020, at https://www.
circuitbasics.com/basics-uart-communication/.
29 Trend Micro Security News. (July 27, 2017). Trend Micro Security News. “InfoSec Guide: Defending Against Man-in-theMiddle Attacks.” Accessed on June 25, 2020, at https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digitalthreats/infosec-guide-defending-against-man-in-the-middle-attacks.
30 Marc-Antoine Boutin. (Jan. 31, 2017). VanillaPlus. “Network slicing unleashes 5G opportunities, when service quality can beassured – Part 2.” Accessed on Jan. 11, 2021, at https://www.vanillaplus.com/2017/01/31/24983-network-slicing-unleashes5g-opportunities-service-quality-can-assured-part-2/.
31 Feike Hacquebord, Robert McArdle, Fernando Mercês, and David Sancho (Sept. 4, 2019). Trend Micro. “Ready or Not for
PSD2: The Risks of Open Banking.” Accessed on Jan. 11, 2021, at https://documents.trendmicro.com/assets/white_papers/
wp-PSD2-The-Risks-of-Open-Banking.pdf.
32 David Undercoffler. (March 6, 2013.) Los Angeles Times. “Rolls Royce debuts all-new Wraith with GPS-controlled
transmission.” Accessed on Jan. 11, 2021, at https://www.latimes.com/business/autos/la-fi-hy-autos-geneva-rolls-roycewraith-20130306-story.html.
33 Carla Tardi. (Aug. 27, 2020). Investopedia. “Moore’s Law.” Accessed on Jan. 11, 2021, at https://www.investopedia.com/
terms/m/mooreslaw.asp.
34 Nicolas Vega. (Sept. 23. 2020). New York Post. “Tesla’s global network outage disables mobile app functionality.” Accessedon Jan. 11, 2021, at https://nypost-com.cdn.ampproject.org/c/s/nypost.com/2020/09/23/teslas-global-network-outagedisables-mobile-app-functionality/amp/.
35 Morton Swimmer, Fyodor Yarochkin, Joey Costoya, and Roel Reyes. (2020). Trend Micro. “Untangling the Web of Cloud
Security Threats.” Accessed on Jan. 11, 2021, at https://documents.trendmicro.com/assets/white_papers/wp-untangling-theweb-of-cloud-security-threats.pdf.
36 Kelly Sheridan. (March 6, 2020). DarkReading. “7 Cloud Attack Techniques You Should Worry About.” Accessed on Jan. 11,
2021, at https://www.darkreading.com/cloud/7-cloud-attack-techniques-you-should-worry-about/d/d-id/1337259?image_number=7.
37 Mercedes-Benz, 360 Group, and Sky-Go. (n.d.). Black Hat USA. “Security Research Report on Mercedes-Benz Cars.”Accessed on Jan. 11, 2021, at https://i.blackhat.com/USA-20/Thursday/us-20-Yan-Security-Research-On-Mercedes-BenzFrom-Hardware-To-Car-Control-wp.pdf.
38 Mercedes-Benz, 360 Group, and Sky-Go. (n.d.). Black Hat USA. “Security Research Report on Mercedes-Benz Cars.”Accessed on Jan. 11, 2021, at https://i.blackhat.com/USA-20/Thursday/us-20-Yan-Security-Research-On-Mercedes-BenzFrom-Hardware-To-Car-Control-wp.pdf.

80 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

39 Lindsey O’Donnell. (Aug. 6, 2020). Threatpost. “Black Hat 2020: Mercedes-Benz E-Series Rife with 19 Bugs.” Accessed on
Jan. 11, 2021, at https://threatpost.com/black-hat-19-flaws-connected-mercedes-benz-vehicles/158144/.
40 Jon Fingas. (April 12, 2020). Engadget. “Elon Musk explains why Tesla’s Model 3 has an in-cabin camera.” Accessed on Jan.
11, 2021, at https://www.engadget.com/tesla-model-3-cabin-camera-explained-222017515.html.
41 Mr. Benz. (July 10, 2020). YouTube. “2021 S-CLASS INTERIOR + New Infotainment & First Look.” Accessed on Jan. 11, 2021,
at https://www.youtube.com/watch?v=EeuY_B9jQxM.
42 Trend Micro and Europol’s European Cybercrime Center (EC3). (Sept. 5, 2017). Trend Micro. “Cashing in on ATM Malware.”Accessed on Jan. 11, 2021, at https://documents.trendmicro.com/assets/white_papers/wp-cashing-in-on-atm-malware.pdf.
43 MITRE ATT&CK®. (Sept. 16, 2020). MITRE ATT&CK®. “ATT&CK®.” Accessed on Jan. 11, 2021, at https://attack.mitre.org.
44 MITRE ATT&CK®. (n.d). MITRE ATT&CK®. “Navigator v2.3.2.” Accessed on Jan. 11, 2021, at https://mitre-attack.github.io/
attack-navigator/v2/enterprise/#.
45 GitHub. (2020). GitHub, Inc. “ATT&CK® Navigator.” Accessed on Jan. 11, 2021, at https://github.com/mitre-attack/attacknavigator.
46 Apple. (n.d.). Apple, Inc. “CarPlay.” Accessed on Jan. 11, 2021, at https://www.apple.com/ca/ios/carplay/.
47 Tesla. (Feb. 13, 2019). Tesla. “Sentry Mode: Guarding Your Tesla.” Accessed on Jan. 11, 2021, at https://www.tesla.com/
en_CA/blog/sentry-mode-guarding-your-tesla.
48 Robert Siciliano. (n.d.). Hotspot Shield. “Watch this guy hack and steal a Tesla Model S in seconds.” Accessed on Jan. 11,
2021, at https://www.hotspotshield.com/blog/tesla-model-s-hack/.
49 Justin Gerdes. (Nov. 8, 2019). Greentech Media. “Will Your EV Keep the Lights On When the Grid Goes Down?” Accessed on
Jan. 11, 2021, https://www.greentechmedia.com/articles/read/will-your-ev-keep-the-lights-on-when-the-grid-goes-down.
50 Tesla. (n.d.). Tesla. “Support: Connectivity.” Accessed on June 23, 2020, at https://www.tesla.com/support/connectivity.
51 Nicolas Vega. (Sept. 23. 2020). New York Post. “Tesla’s global network outage disables mobile app functionality.” Accessed
on ___, at https://nypost-com.cdn.ampproject.org/c/s/nypost.com/2020/09/23/teslas-global-network-outage-disablesmobile-app-functionality/amp/.
52 Fred Lambert. (March 8, 2017). Electrek. “Tesla’s app/API has been down and/or spotty for the past 24 hours [Update:
resolved].” Accessed on Jan. 11, 2021, at https://electrek.co/2017/03/08/teslas-app-apidown-andor-spotty/.
53 Craig Gibson. (Nov. 15, 2019). Trend Micro. “Securing 5G Through Cyber-Telecom Identity Federation.” Accessed on Feb. 10,
2021, at https://documents.trendmicro.com/assets/white_papers/wp-securing-5g-through-cyber-telecom-identity-federation.
pdf.
54 United Nations Economic and Social Council. (June 23, 2020). UNECE. “Proposal for a new UN Regulation on uniform
provisions concerning the approval of vehicles with regard to cyber security and of their cybersecurity management systems.”
Accessed on Jan. 11, 2021, at http://www.unece.org/fileadmin/DAM/trans/doc/2020/wp29grva/ECE-TRANS-WP29-2020079-Revised.pdf.
55 Lo/Jack®. (n.d.). Lo/Jack®. “Connected Car & Stolen Vehicle Recovery.” Accessed on Jan. 11, 2021, at https://www.lojack.
com/products/.
56 Warwick Goodall et al. (2017). Deloitte Review. “The rise of mobility as a service.” Accessed on Jan. 11, 2021, at https://www2.deloitte.com/content/dam/Deloitte/nl/Documents/consumer-business/deloitte-nl-cb-ths-rise-of-mobility-as-a-service.
pdf.
57 Tesla. (n.d.). Tesla. “Support: Connectivity.” Accessed on June 23, 2020, at https://www.tesla.com/support/connectivity.
58 Gareth Corfield. (Nov. 16, 2019). The Register. “5G SIM-swap attacks could be even worse for industrial IoT than now.”
Accessed on Jan. 11, 2021, at https://www.theregister.com/2019/11/16/5g_iot_report/.
59 Craig Gibson and Europol. (Oct. 23, 2018). Trend Micro. “Toll Fraud, International Revenue Share Fraud and More: How
Criminals Monetize Hacked Cellphones and IoT Devices for Telecom Fraud.” Accessed on Jan. 11, 2021, at https://www.
trendmicro.com/vinfo/us/security/news/internet-of-things/toll-fraud-irsf-criminals-monetize-hacked-phones-iot-devicestelecom-fraud.
60 Aimee Chanthadavong. (June 24, 2020). ZDNet. “Nvidia and Mercedes to roll out software-defined autonomous vehicles by2024.” Accessed on Jan. 11, 2021, at https://www.zdnet.com/article/nvidia-and-mercedes-benz-to-roll-out-software-definedautonomous-vehicles-by-2024.

81 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

61 Kari Paul. (Feb. 19, 2020). The Guardian. “My smart car rental was a breeze – until I got trapped in the woods.” Accessed on
Jan. 11, 2021, at https://www.theguardian.com/technology/2020/feb/18/smart-car-gig-rental-app-trapped.
62 Sarah White. (Nov. 2, 2017). CIO. “What is geofencing? Putting location to work.” Accessed on Jan. 11, 2021, at https://www.
cio.com/article/2383123/geofencing-explained.html.
63 Loukia Papadopoulos. (June 20, 2020). Interesting Engineering. “Tesla’s Head of AI Says The Firm Uses a Harder Approach
to Self-Driving for Scalability Reasons.” Accessed on Jan. 11, 2021, at https://interestingengineering.com/teslas-headof-ai-says-the-firm-uses-a-harder-approach-to-self-driving-for-scalability-reasons?utm_source=Facebookandutm_
medium=Articleandutm_campaign=organicandutm_content=Jun20.
64 Kaiser Larsen. (Sept. 13, 2018). AWS Machine Learning Blog. “Mapillary uses Amazon Rekognition to work towards building
parking solutions for US cities.” Accessed on Jan. 11, 2021, at https://aws.amazon.com/blogs/machine-learning/mapillaryuses-amazon-rekognition-to-work-towards-building-parking-solutions-for-us-cities/.
65 Trend Micro Research, United Nations Interregional Crime and Justice Research Institute (UNICRI), and Europol’s European
Cybercrime Centre (EC3). (Nov. 19, 2020). Trend Micro. “Malicious Uses and Abuses of Artificial Intelligence.” Accessedon Jan. 11, 2021, at https://documents.trendmicro.com/assets/white_papers/wp-malicious-uses-and-abuses-of-artificialintelligence.pdf.
66 Katyanna Quach. (Feb. 20, 2020). The Register. “Researchers trick Tesla into massively breaking the speed limit by sticking
a 2-inch piece of electrical tape on a sign.” Accessed on July 20, 2020, at https://www.theregister.com/2020/02/20/tesla_ai_
tricked_85_mph/.
67 Chris Young. (June 10, 2020). Interesting Engineering. “Tesla Semi Truck Moving Into ‘Volume Production,’ Says Elon Muskin Leaked Memo.” Accessed on Jan. 11, 2021, at https://interestingengineering.com/tesla-semi-truck-moving-into-volumeproduction-says-elon-musk-in-leaked-memo.
68 Simon Weckert. (n.d.) Simon Weckert. “About.” Accessed on Jan. 11, 2021, at http://simonweckert.com/about.html.
69 Simon Weckert. (Feb 1, 2020). Youtube. “Google Maps Hacks by Simon Weckert video.” Accessed on Jan. 11, 2021, at
https://www.youtube.com/watch?v=k5eL_al_m7Q.
70 Felix Gary Gray (director). (2003). The Italian Job movie. “The Italian Job.”
71 Trend Micro Research, United Nations Interregional Crime and Justice Research Institute (UNICRI), and Europol’s European
Cybercrime Centre (EC3). (n.d.) Trend Micro. “Malicious Uses and Abuses of Artificial Intelligence.” Accessed on Jan. 11,
2021, at https://documents.trendmicro.com/assets/white_papers/wp-malicious-uses-and-abuses-of-artificial-intelligence.pdf.
72 Crypto World Club. (Feb. 26, 2020). CryptoWorldClub. “CoinDesk Explains SIM Jacking or ‘SIM Hacks.’” Accessed on Jan.
11, 2021, at https://cryptoworld.club/coindesk-explains-sim-jacking-or-sim-hacks/.
73 Andreas Floemer. (May 7, 2020). t3n Magazin. “BMW OS 7: Großes Update bringt Android Auto und mehr auf über 750.000
Fahrzeuge.” Accessed on Jan. 11, 2021, at https://t3n.de/news/schlummernde-funktionen-abomodell-1296599/.
74 Cherise Threewitt. (June 3, 2020). HowStuffWorks. “Ford Software Update Lets Cop Cars Cook Away Coronavirus with Heat.”
Accessed on Jan. 11, 2021, at https://auto.howstuffworks.com/car-driving-safety/safety-regulatory-devices/ford-police-carcoronavirus.htm.
75 Tracy Camp, Jeff Boleng, and Vanessa Davies. (Sept. 11, 2002). Wiley Online Library. “A survey of mobility models for ad hoc
network research.” Accessed on Jan. 11, 2021, at https://onlinelibrary.wiley.com/doi/pdfdirect/10.1002/wcm.72.
76 Techopedia. (March 6, 2013). Techopedia. “Nomadic Wireless.” Accessed on Jan. 11, 2021, at https://www.techopedia.com/
definition/2961/nomadic-wireless.
77 Carritech Telecommunications. (Jan. 28, 2019). Carritech Telecommunications. “What is OTT and how is it impacting Telecom
Service Providers?” Accessed on Jan. 11, 2021, at https://www.carritech.com/news/ott-telecom-providers/.
78 Brad Templeton. (June 26, 2020). Forbes. “Amazon Buys Self-Driving Company Zoox For $1.2B And May Rule The World.”
Accessed on Jan. 11, 2021, at https://www.forbes.com/sites/bradtempleton/2020/06/26/amazon-buys-self-driving-companyzoox-for-12b-and-may-rule-the-world/?sh=6560149e769c.
79 Brenda Goh and Yilei Sun. (July 9, 2020). Reuters. “Tesla ‘very close’ to level 5 autonomous driving technology, Musk says.”
Accessed on Jan. 11, 2021, at https://www.reuters.com/article/us-tesla-autonomous/tesla-very-close-to-level-5-autonomousdriving-technology-musk-says-idUSKBN24A0HE.
80 Margaret Rouse. (April 2014). TechTarget. “mobile virtual network operator (MVNO).” Accessed on Jan. 11, 2021, at https://whatis.techtarget.com/definition/mobile-virtual-network-operator-MVNO.

82 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

81 EC-Council. (n.d.). EC-Council. “What is DNS Hijacking and How to Combat It.” Accessed on Jan. 11, 2021, at https://blog.
eccouncil.org/what-is-dns-hijacking-and-how-to-combat-it/.
82 Federal Communications Commission. (n.d.) Federal Communications Commission. “Cell Phone Fraud.” Accessed on Jan.
11, 2021, at https://www.fcc.gov/consumers/guides/cell-phone-fraud.
83 Cambridge Dictionary. (n.d.). Cambridge Dictionary. “Wiretap.” Accessed on Jan. 11, 2021, at https://dictionary.cambridge.
org/dictionary/english/wiretap.
84 Derrick Rountree. (2013). ScienceDirect. “Federated Identity.” Accessed on Jan. 11, 2021, at https://www.sciencedirect.com/
topics/computer-science/federated-identity.
85 Sierra Rogers. (Nov. 11, 2020). Capterra. “Single Sign-On: What It Is, How It Works, and Why You Need It.” Accessed on Jan.
11, 2021, at https://blog.capterra.com/single-sign-on/.
86 Bluetooth. (n.d.). Bluetooth. “SAP and Remote Network Access.” Accessed on Jan. 11, 2021, at https://www.bluetooth.com/
bluetooth-resources/sap-and-remote-network-access/.
87 O’Reilly Media. (n.d.) O’Reilly Media. “Home eNB (HeNB).” Accessed on Jan. 11, 2021, at https://www.oreilly.com/library/view/radio-protocols-for/9781118188569/chapter09.html.
88 Marco Balduzzi et al. (Aug. 5, 2020). Trend Micro. “Lost in Translation: When Industrial Protocol Translation Goes Wrong.”
Accessed on Jan. 11, 2021, at https://documents.trendmicro.com/assets/white_papers/wp-lost-in-translation-whenindustrial-protocol-translation-goes-wrong.pdf.
89 Terry Young. (Jan. 30, 2020). ITProPortal. “Why roaming still matters in a 5G world.” Accessed on Jan. 11, 2021, at https://www.itproportal.com/features/why-roaming-still-matters-in-a-5g-world/.
90 GSMA. (n.d.). GSM Association. “GSMA.” Accessed on Jan. 11, 2021, at https://www.gsma.com.
91 Techopedia. (n.d.). Techopedia. “Mobile Phone Spam.” Accessed on Jan. 11, 2021, at https://www.techopedia.com/
definition/16072/mobile-phone-spam.
92 3G4G. (March. 1, 2020). The 3G4G Blog. “5G Private and Non-Public Network (NPN).” Accessed on Jan. 11, 2021, at https://blog.3g4g.co.uk/2020/03/5g-private-and-non-public-network-npn.html.
93 Craig Gibson. (Nov. 15, 2019). Trend Micro. “Securing 5G Through Cyber-Telecom Identity Federation.” Accessed on Jan. 11,
2021, at https://documents.trendmicro.com/assets/white_papers/wp-securing-5g-through-cyber-telecom-identity-federation.
pdf.
94 Blue Origin. (n.d.). Blue Origin. “Blue Origin.” Accessed on Jan. 11, 2021, at https://www.blueorigin.com.
95 Starlink. (n.d.). Starlink. “Starlink.” Accessed on Jan. 11, 2021, at https://www.starlink.com.
96 Craig Gibson. (June 11, 2018). Trend Micro. “IoT and Satellite Security in the Age of 5G.” Accessed on Jan. 11, 2021, at
https://blog.trendmicro.com/trendlabs-security-intelligence/attack-vectors-in-orbit-need-for-satellite-security-in-5g-iot/.
97 GSMA. (n.d.). GSM Association. “Smart Cities Transport.” Accessed on Jan. 11, 2021, at https://www.gsma.com/iot/smartcities-resources/smart-cities-transport/.
98 Trend Micro Research, United Nations Interregional Crime and Justice Research Institute (UNICRI), and Europol’s European
Cybercrime Centre (EC3). (Nov. 19, 2020). Trend Micro. “Malicious Uses and Abuses of Artificial Intelligence.” Accessedon Jan. 11, 2021, at https://documents.trendmicro.com/assets/white_papers/wp-malicious-uses-and-abuses-of-artificialintelligence.pdf.
99 Vit Sembera. (June 29, 2020). Trend Micro. “ISO/SAE 21434: Setting the Standard for Connected Cars’ Cybersecurity.”
Accessed on Jan. 11, 2021, at https://documents.trendmicro.com/assets/white_papers/wp-setting-the-standard-forconnected-cars-cybersecurity.pdf.
100 Trend Micro Research and Europol’s European Cybercrime Centre (EC3). (March 21, 2019). Europol. “Cyber-telecom Crime
Report 2019.” Accessed on Jan. 11, 2021, at https://www.europol.europa.eu/publications-documents/cyber-telecom-crimereport-2019.
101 SCADAHacker. (n.d.). SCADAHacker. “Assessing the Security of ICS Using Threat Modeling.” Accessed on June 25, 2020, at
https://scadahacker.com/howto/howto-threatmodeling.html.
102 Shodan. (n.d.). Shodan. “Shodan.” Accessed on June 25, 2020, at https://www.shodan.io/.
103 Trend Micro. (n.d.). Trend Micro. “SQL injection.” Accessed on June 25, 2020, at https://www.trendmicro.com/vinfo/us/
security/definition/sql-injection.

83 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

104 Trend Micro. (n.d.). Trend Micro. “Cross-site scripting (XSS).” Accessed on June 25, 2020, at https://www.trendmicro.com/
vinfo/us/security/definition/cross-site-scripting-(xss).
105 OWASP. (n.d.). OWASP. “Session hijacking attack.” Accessed on June 25, 2020, at https://owasp.org/www-community/
attacks/Session_hijacking_attack.
106 Justin Jett. (Feb. 15, 2019). Threatpost. “Tips on How to Fight Back Against DNS Spoofing Attacks.” Accessed on June 25,
2020, at https://threatpost.com/dns-spoofing-attacks/141880/.
107 OWASP. (n.d.). OWASP. “Application threat modeling.” Accessed on June 25, 2020, at https://owasp.org/www-community/
Application_Threat_Modeling.
108 David Czagan. (May 21, 2014). InfoSec Institute. “Qualitative Risk Analysis with the DREAD Model.” Accessed on June 25,
2020, at https://resources.infosecinstitute.com/qualitative-risk-analysis-dread-model/.
109 Trend Micro Security News. (Nov. 27, 2017). Trend Micro Security News. “Securing the Transportation Network of Tomorrow.”
Accessed on June 25, 2020, at https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/securing-thetransportation-network-of-tomorrow.
110 Vit Sembera. (June 29, 2020). Trend Micro. “ISO/SAE 21434: Setting the Standard for Connected Cars’ Cybersecurity.”
Accessed on Jan. 11, 2021, at https://documents.trendmicro.com/assets/white_papers/wp-setting-the-standard-forconnected-cars-cybersecurity.pdf.
111 Nuuman Huq. (March 12, 2015). Trend Micro. “Defending Against Pos RAM Scrapers.” Accessed on June 26, 2020, at https://documents.trendmicro.com/assets/wp/wp-defending-against-pos-ram-scrapers.pdf.
112 Venafi. (n.d.) Venafi. “Code Signing Certificates [Your In-Depth Guide].” Accessed on Jan. 11, 2021, at https://www.venafi.
com/education-center/code-signing/what-is-code-signing.
113 VMware. (n.d.) VMware. “What is application security?” Accessed on Jan. 11, 2021, at https://www.vmware.com/topics/
glossary/content/application-security.
114 Trend Micro. (n.d.) Trend Micro. “Trend Micro Cloud One™ Application Security.” Accessed on Jan. 11, 2021, at https://www.
trendmicro.com/en_ca/business/products/hybrid-cloud/cloud-one-application-security.html.
115 Trend Micro. (n.d.) Trend Micro. “Device Control.” Accessed on Jan. 11, 2021, at http://docs.trendmicro.com/all/ent/
officescan/v10.0/en-us/osce_10.0_olhsrv/osceag/osceag-scan/device_control.htm.
116 Scott Rose et al. (Aug. 2020). National Institute of Standards and Technology (NIST). “Zero Trust Architecture.” Accessed on
Jan. 11, 2021, at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf.
117 Scott Rose et al. (Aug. 2020). National Institute of Standards and Technology (NIST). “Zero Trust Architecture.” Accessed on
Jan. 11, 2021, at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf.
118 Dave Nyczepir. (n.d.) Scoop News Group. “NIST releases finalized zero-trust architecture guidance.” Accessed on Jan. 11,
2021, at https://www.fedscoop.com/nist-finalized-zero-trust-guidance/.
119 Trend Micro IoT Security. (n.d.). Trend Micro IoT Security. “Trend Micro IoT Security for Automotive.” Accessed on July 8,
2020, at https://www.trendmicro.com/us/iot-security/product/iot-security-for-auto?solutions=connected-car.
120 Trend Micro IoT Security. (n.d.). Trend Micro IoT Security. “Connected Car.” Accessed on Feb. 5, 2021, at https://www.
trendmicro.com/en_us/business/solutions/iot/5g-and-iot.html#t4https://www.trendmicro.com/us/iotRE-security/product/
trend-micro-virtual-network-function-suite?solutions=retail.
121 Trend Micro. (n.d.). Trend Micro. “Hybrid Cloud Security.” Accessed on July 8, 2020, at https://www.trendmicro.com/en_us/
business/products/hybrid-cloud.html#t2.
122 Trend Micro IoT Security. (n.d.). Trend Micro IoT Security. “Trend Micro IoT Security™.” Last accessed on July 13, 2020, at
https://www.trendmicro.com/us/iot-security/product/trend-micro-iotsecurity?solutions=smart-city.
123 Trend Micro. (n.d.). Trend Micro. “XDR: Detection and response across email, endpoints, servers, cloud workloads, andnetworks.” Accessed on July 8, 2020, at https://www.trendmicro.com/en_us/business/products/detection-response/xdr.html.
124 Internet of Business. (n.d.) Internet of Business. “Connected cars report: 125 million vehicles by 2022, 5G coming.” Accessedon Jan. 11, 2021, at https://internetofbusiness.com/worldwide-connected-car-market-to-top-125-million-by-2022/.
125 Nick Michell. (Dec. 5, 2016). Cities Today. “Self-driving cars to reach 14.5 million by 2025, says new study.” Accessed on Jan.
11, 2021, at https://cities-today.com/self-driving-car-production-reach-14-5-million-2025-says-new-study/.

84 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

126 Michael Morand. (March 1, 2019). Association for Supply Chain Management (ASCM). “The Red Queen Hypothesis.”
Accessed on Jan. 27, 2021, at https://www.ascm.org/ascm-insights/the-red-queen-hypothesis/.
127 Dr. Charlie Miller and Chris Valasek. (Aug. 10, 2015). Illmatics. “Remote Exploitation of an Unaltered Passenger Vehicle.”
Accessed on June 24, 2020, at http://illmatics.com/Remote%20Car%20Hacking.pdf.
128 Chris Welch. (July 24, 2015). The Verge. “Chrysler recalls 1.4 million cars at risk of being remotely hijacked.” Accessed onJune 24, 2020, at https://www.theverge.com/2015/7/24/9032179/chrysler-announces-voluntary-recall-hack.
129 Black Hat. (Dec. 29, 2015). YouTube. “Remote Exploitation Of An Unaltered Passenger Vehicle.” Accessed on July 8, 2020, at
https://www.youtube.com/watch?v=MAcHkASmXEc.
130 Jeep. (n.d.). Jeep. “Uconnect® overview.” Accessed on June 24, 2020, at https://www.jeep.com/uconnect.html.
131 Scott Reeves. (Nov. 11, 2013). TechRepublic. “Pros and cons of using femtocells.” Accessed on June 24, 2020, at https://www.techrepublic.com/blog/data-center/pros-and-cons-of-using-femtocells/.
132 Mopar. (n.d.). Mopar. “Why wiTECH 2.0?” Accessed on June 24, 2020, at https://www.fcawitech.com/.
133 Kvaser. (n.d.). Kvaser. “CAN Messages.” Accessed on June 24, 2020, at https://www.kvaser.com/lesson/can-messages/.
134 Hideyoshi Kume. (Feb. 17, 2020). Nikkei Asian Review. “Tesla teardown finds electronics 6 years ahead of Toyota and VW.”
Accessed on June 24, 2020, at https://asia.nikkei.com/Business/Automobiles/Tesla-teardown-finds-electronics-6-yearsahead-of-Toyota-and-VW2.
135 Sen Nie, Ling Liu, and Yuefeng Du. (n.d.). Black Hat. “Free-Fall: Hacking Tesla From Wireless To Can Bus.” Accessed on June24, 2020, at https://www.blackhat.com/docs/us-17/thursday/us-17-Nie-Free-Fall-Hacking-Tesla-From-Wireless-To-CAN-Bus.
pdf.
136 Sen Nie, Ling Liu, and Yuefeng Du. (n.d.). Black Hat. “Free-Fall: Hacking Tesla From Wireless To Can Bus.” Accessed on June24, 2020, at https://www.blackhat.com/docs/us-17/thursday/us-17-Nie-Free-Fall-Hacking-Tesla-From-Wireless-To-CAN-Bus.
pdf.
137 WebKit. (n.d.). WebKit. “WebKit.” Accessed on June 24, 2020, at https://webkit.org/.
138 Common Vulnerabilities and Exposures. (n.d.). Common Vulnerabilities and Exposures. “CVE-2013-6282.” Accessed on June24, 2020, at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6282.
139 Chriss Hoffman. (n.d.). How-To Geek. “What Is AppArmor, and How Does It Keep Ubuntu Secure?” Accessed on Jan 11,
2021, at https://www.howtogeek.com/118222/htg-explains-what-apparmor-is-and-how-it-secures-your-ubuntu-system/.
140 1SSH. (n.d.). SSH. “SSH (Secure Shell).” Accessed on June 24, 2020, at https://www.ssh.com/ssh/.
141 Jeff Tyson. (n.d.). How Stuff Works. “How Encryption Works.” Accessed on June 24, 2020, at https://computer.howstuffworks.
com/encryption7.htm.
142 TechTerms. (n.d.). TechTerms. “UDP.” Accessed on June 24, 2020, at https://techterms.com/definition/udp.
143 Bosch. (Feb. 15, 2016). Bosch. “Preventing skidding: The Electronic Stability Program ESP®.” Accessed on June 24, 2020, at
https://www.bosch.com/stories/the-electronic-stability-program-esp/.
144 National Instruments (NI). (n.d.). National Instruments Corp. “UDS (Unified Diagnostic Services).” Accessed on June 24, 2020,
at http://zone.ni.com/reference/en-XX/help/372140J-01/adcs/udsunifieddiagnosticservices/.
145 Sen Nie et al. (n.d.). Black Hat. “Over-The-Air: How We Remotely Compromised the Gateway, BCM, and Autopilot ECUs Of
Tesla Cars.” Accessed on June 24, 2020, at https://i.blackhat.com/us-18/Thu-August-9/us-18-Liu-Over-The-Air-How-WeRemotely-Compromised-The-Gateway-Bcm-And-Autopilot-Ecus-Of-Tesla-Cars-wp.pdf.
146 NXP. (February 2011). NXP. “Freescale MSD FATFS Users Guide.” Accessed on June 24, 2020, at https://www.nxp.com/docs/
en/user-guide/MSDFATFSUG.pdf.
147 Fox Van Allen. (April 27, 2018). CNet. “Incredibly cool Tesla Easter eggs.” Accessed on June 24, 2020, at https://www.cnet.
com/pictures/tesla-easter-eggs/.
148 Tesla. (n.d.). Tesla. “Future of Driving.” Accessed on June 24, 2020, at https://www.tesla.com/autopilot?redirect=no.
149 Tencent Keen Security Lab. (March 2019). Keen Security Lab. “Experimental Security Research of Tesla Autopilot.” Accessedon June 24, 2020, at https://keenlab.tencent.com/en/whitepapers/Experimental_Security_Research_of_Tesla_Autopilot.pdf.

85 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

150 Tencent Keen Security Lab. (n.d.). Keen Security Lab. “Experimental Security Assessment of BMW Cars: A Summary Report.”
Accessed on June 24, 2020, at https://keenlab.tencent.com/en/whitepapers/Experimental_Security_Assessment_of_BMW_
Cars_by_KeenLab.pdf.
151 Tencent Keen Security Lab. (n.d.). Black Hat. “0-Days & Mitigations: Roadways to Exploit and Secure Connected BMW Cars.”Accessed on June 24, 2020, at https://i.blackhat.com/USA-19/Thursday/us-19-Cai-0-Days-And-Mitigations-Roadways-ToExploit-And-Secure-Connected-BMW-Cars.pdf.
152 The OBD II Home Page. (n.d.). The OBD II Home Page. “OBD-II Background.” Accessed on June 24, 2020, at http://www.
obdii.com/background.html.
153 BMW USA. (n.d.). BMW USA. “BMW ConnectedDrive.” Accessed on June 24, 2020, at https://www.bmwusa.com/explore/
connecteddrive.html.
154 Newtis.info. (n.d.). Newtis.info. “Telematic Communication Box.” Accessed on June 25, 2020, at https://www.newtis.info/
tisv2/a/en/e90-320d-lim/wiring-functional-info/body/audio-video-telephone-navigation-most-ring/telecommunications/documents/Jxfm2y8o.
155 Sascha Segan. (April 7, 2020). PCMag. “CDMA vs. GSM: What’s the Difference?” Accessed on June 25, 2020, at https://www.
pcmag.com/news/cdma-vs-gsm-whats-the-difference.
156 Common Weakness Enumeration. (n.d.). Common Weakness Enumeration. “CWE-367: Time-of-check Time-of-use (TOCTOU)
Race Condition.” Accessed on June 25, 2020, at https://cwe.mitre.org/data/definitions/367.html.
157 QNX. (n.d.). QNX. “What is Qnet?” Accessed on July 8, 2020, at http://www.qnx.com/developers/docs/qnxcar2/index.
jsp?topic=%2Fcom.qnx.doc.neutrino.prog%2Ftopic%2Fqnet_WQCDFY.html.
158 PressClub USA. (Aug. 1, 2008). BMW Group. “Bmw Presents Open Source Telematics Protocol.” Accessed on June25, 2020, at https://www.press.bmwgroup.com/usa/article/detail/T0017923EN_US/bmw-presents-open-sourcetelematicsprotocol?language=en_US.
159 Takuji Hara, Norio Kambayashi, and Noboru Matsushima. (n.d.). Google Books. “Industrial Innovation in Japan.” Accessed onJune 25, 2020, at https://books.google.com.ph/books/about/Innovation_in_Japan.html?id=TYtoMguVdl0C&redir_esc=y.
160 Alessio Filippi, Kees Moerman, Gerardo Daalderop, Paul D. Alexander, Franz Schober, and Werner Pfliegl. (n.d.) Siemens.
“Ready to roll: Why 802.11p beats LTE and 5G for V2x.” Accessed on Jan. 11, 2021, at https://assets.new.siemens.com/
siemens/assets/api/uuid:ab5935c545ee430a94910921b8ec75f3c17bab6c/its-g5-ready-to-roll-en.pdf.
161 Dr. Yunpeng Zang (on behalf of Dr. Mikael Fallgren). (March 2018). 5GCAR. “Session 3 5GCAR (Presentation for the
9th ETSI ITS Workshop, 6-8 March 2018, in Berlin, Germany).” Accessed on Jan. 11, 2021, at https://docbox.etsi.org/
Workshop/2018/20180306_ITS_WORKSHOP/S03_FRAMING_NEEDS_AUTOMATED-DRIV/5GCAR_ERICSSON_ZANG.pdf.
162 Dr. Yunpeng Zang (on behalf of Dr. Mikael Fallgren). (March 2018). 5GCAR. “Session 3 5GCAR (Presentation for the
9th ETSI ITS Workshop, 6-8 March 2018, in Berlin, Germany).” Accessed on Jan. 11, 2021, at https://docbox.etsi.org/
Workshop/2018/20180306_ITS_WORKSHOP/S03_FRAMING_NEEDS_AUTOMATED-DRIV/5GCAR_ERICSSON_ZANG.pdf.
163 Dr. Yunpeng Zang (on behalf of Dr. Mikael Fallgren). (March 2018). 5GCAR. “Session 3 5GCAR (Presentation for the
9th ETSI ITS Workshop, 6-8 March 2018, in Berlin, Germany).” Accessed on Jan. 11, 2021, at https://docbox.etsi.org/
Workshop/2018/20180306_ITS_WORKSHOP/S03_FRAMING_NEEDS_AUTOMATED-DRIV/5GCAR_ERICSSON_ZANG.pdf.
164 Dr. Yunpeng Zang (on behalf of Dr. Mikael Fallgren). (March 2018). 5GCAR. “Session 3 5GCAR (Presentation for the
9th ETSI ITS Workshop, 6-8 March 2018, in Berlin, Germany).” Accessed on Jan. 11, 2021, at https://docbox.etsi.org/
Workshop/2018/20180306_ITS_WORKSHOP/S03_FRAMING_NEEDS_AUTOMATED-DRIV/5GCAR_ERICSSON_ZANG.pdf.
165 Dr. Yunpeng Zang (on behalf of Dr. Mikael Fallgren). (March 2018). 5GCAR. “Session 3 5GCAR (Presentation for the
9th ETSI ITS Workshop, 6-8 March 2018, in Berlin, Germany).” Accessed on Jan. 11, 2021, at https://docbox.etsi.org/
Workshop/2018/20180306_ITS_WORKSHOP/S03_FRAMING_NEEDS_AUTOMATED-DRIV/5GCAR_ERICSSON_ZANG.pdf.
166 Dr. Yunpeng Zang (on behalf of Dr. Mikael Fallgren). (March 2018). 5GCAR. “Session 3 5GCAR (Presentation for the
9th ETSI ITS Workshop, 6-8 March 2018, in Berlin, Germany).” Accessed on Jan. 11, 2021, at https://docbox.etsi.org/
Workshop/2018/20180306_ITS_WORKSHOP/S03_FRAMING_NEEDS_AUTOMATED-DRIV/5GCAR_ERICSSON_ZANG.pdf.
167 Tesla. (Sept. 30, 2019) YouTube. “Smart Summon.” Accessed on Jan. 11, 2021, at https://www.youtube.com/
watch?v=nlCQG2rg4sw.

86 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

168 Andrew J. Hawkins. (Sept. 30, 2019). The Verge. “Tesla’s Smart Summon feature is already causing chaos in parking lots
across America.” Accessed on Jan. 11, 2021, at https://www.theverge.com/2019/9/30/20891343/tesla-smart-summonfeature-videos-parking-accidents.
169 Dr. Yunpeng Zang (on behalf of Dr. Mikael Fallgren). (March 2018). 5GCAR. “Session 3 5GCAR (Presentation for the
9th ETSI ITS Workshop, 6-8 March 2018, in Berlin, Germany).” Accessed on Jan. 11, 2021, at https://docbox.etsi.org/
Workshop/2018/20180306_ITS_WORKSHOP/S03_FRAMING_NEEDS_AUTOMATED-DRIV/5GCAR_ERICSSON_ZANG.pdf.
170 Fatih Sakiz and Sevil Sen. (March 2017) ResearchGate. “A Survey of Attacks and Detection Mechanisms onIntelligent Transportation Systems: VANETs and IoV.” Accessed on Jan. 11, 2021, at https://www.researchgate.net/
publication/315439003_A_Survey_of_Attacks_and_Detection_Mechanisms_on_Intelligent_Transportation_Systems_VANETs_
and_IoV.
171 Fatih Sakiz and Sevil Sen. (March 2017) ResearchGate. “A Survey of Attacks and Detection Mechanisms onIntelligent Transportation Systems: VANETs and IoV.” Accessed on Jan. 11, 2021, at https://www.researchgate.net/
publication/315439003_A_Survey_of_Attacks_and_Detection_Mechanisms_on_Intelligent_Transportation_Systems_VANETs_
and_IoV.
172 Fatih Sakiz and Sevil Sen. (March 2017) ResearchGate. “A Survey of Attacks and Detection Mechanisms onIntelligent Transportation Systems: VANETs and IoV.” Accessed on Jan. 11, 2021, at https://www.researchgate.net/
publication/315439003_A_Survey_of_Attacks_and_Detection_Mechanisms_on_Intelligent_Transportation_Systems_VANETs_
and_IoV.
173 Fatih Sakiz and Sevil Sen. (March 2017) ResearchGate. “A Survey of Attacks and Detection Mechanisms onIntelligent Transportation Systems: VANETs and IoV.” Accessed on Jan. 11, 2021, at https://www.researchgate.net/
publication/315439003_A_Survey_of_Attacks_and_Detection_Mechanisms_on_Intelligent_Transportation_Systems_VANETs_
and_IoV.

87 | Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and Other Connected Technologies

TREND MICROTM RESEARCH
Trend Micro, a global leader in cybersecurity, helps to make the world safe for exchanging digital information.
Trend Micro Research is powered by experts who are passionate about discovering new threats, sharing key insights, and supporting
efforts to stop cybercriminals. Our global team helps identify millions of threats daily, leads the industry in vulnerability disclosures,and publishes innovative research on new threat techniques. We continually work to anticipate new threats and deliver thoughtprovoking research.
www.trendmicro.com©2021 by Trend Micro, Incorporated. All rights reserved. Trend Micro and the Trend Micro t-ball logo are trademarks or registered trademarks ofTrend Micro, Incorporated. All other product or company names may be trademarks or registered trademarks of their owners.