Ethical Hacking of Android Auto in the Context of Road Safety

EXAMENSARBETE INOM DATATEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2021

ALEXANDER PALM

BENJAMIN GAFVELIN

Abstract

With a more than ever increasing demand to interconnect smartphones with infotainment systems, Android Auto has risen in popularity with its services used in modern vehicles worldwide. However, as users progressively connect their smartphones to in-vehicle infotainment systems, the opportunity for malicious actors to endanger and access private data of Android Auto users advances as well. The goal with this thesis is to determine how secure Android Auto is for road use. The main research question is to ﬁgure out if Android Auto is susceptible to attacks that exploit certain vulnerabilities in the Android operating system.The research question was answered by creating several proof-of- concept attacks on Android Auto using an emulated infotainment system with mobile devices. An investigation was also conducted regarding the application’s communication channel between the mobile device and infotainment display. Results of this thesis demonstrate that several attacks are substantially severe to endanger drivers on the road. There is a great risk of successful exploits when running Android Auto locally on the phone without a connection to the infotainment system, and a lesser risk when connected to the infotainment system. Intercepting communication in the USB channel revealed an encryption algorithm whose version has published exploits and can be cracked to potentially exploit Android Auto.

Keywords Android Auto Security; Infotainment System; Road Safety; Penetration Testing; Malicious Apps; Android Security; ii | Abstract Sammanfattning | iii

Sammanfattning

I takt med en evigt ökande efterfrågan på att sammankoppla smart- telefoner med infotainmentsystem, har allt fler börjat använda Android Auto i sina fordon världen över. En bieffekt av att allt fler sammankopplar sina mobiler till infotainmentsystem, är att det leder till fler möjligheter för illvilliga parter att stjäla privat data och sätta Android Auto- användares liv i fara. Målet med denna avhandling är att fastställa hur säkert Android Auto är i avseende till vägsäkerhet. Den huvudsakliga forskningsfrågan är att lista ut om Android Auto kan attackeras av attacker som utnyttjar sårbarheter i Android operativsystemet. Forsknings- frågan besvarades genom att skapa flertal konceptattacker mot Android Auto användandes av ett emulerat infotainmentsystem och mobiltelefoner. En utredning utfördes även gällande applikationens kommunikationskanal mellan telefonen och infotainmentskärmen. Resultatet från denna avhandling demonstrerade att många attacker är tillräckligt allvarliga för att äventyra trafikanternas säkerhet. Det finns en avsevärd risk för framgångsrika attacker när Android Auto körs lokalt på telefonen utan en USB koppling till infotainmentsystemet, och en liten risk när telefonen är kopplad till infotainmentsystemet. Avlyssning och uppfångning av kommunikationen i USB kanalen visade att en krypteringsalgoritm vars version har existerande sårbarheter kan avkrypteras och utnyttjas för att potentiellt attackera Android Auto.

Nyckelord Android Auto Säkerhet; Infotainment-system; Vägsäkerhet; Penetrationstest; Skadliga Appar; Android Säkerhet; iv | Sammanfattning CONTENTS | v

Contents

1 Introduction1 1.1 Similar Platforms and Competitors...... 3 1.2 Motivation...... 3 1.3 Problem Statement...... 4 1.4 Purpose...... 4 1.5 Goals...... 4 1.6 Scope of Research...... 5 1.7 Contributions...... 5 1.8 Attacks...... 6 1.9 Vulnerabilities in the USB Connection...... 6 1.10 Thesis structure...... 7

2 Method of research9 2.1 Research Methodology...... 9 2.1.1 Problem Identification and Motivation...... 9 2.1.2 Define the Objectives for a Solution...... 11 2.1.3 Design and Development...... 11 2.1.4 Demonstration...... 11 2.1.5 Evaluation...... 11 2.1.6 Communication and Contribution...... 12 2.2 Ethical Approach...... 12 2.2.1 Authorization...... 12 2.2.2 Non-disclosure...... 13 2.2.3 Confidentiality...... 13 2.2.4 Boundaries...... 13

3 Related Research 15 vi | Contents

4 Attacks and Attack Environment 17 4.1 Attack Environment...... 17 4.2 Attacks...... 19 4.2.1 Task Hijacking...... 19 4.2.2 Intent Storm...... 20 4.2.3 SoundBlast...... 21

5 Results 23 5.1 Task hijacking...... 23 5.2 Intent Storm...... 24 5.3 SoundBlast...... 24

6 Discussion 25 6.1 Attacks...... 25 6.1.1 Task Hijacking...... 25 6.1.2 Intent Storm...... 26 6.1.3 SoundBlast...... 27 6.1.4 CVSS 3.0...... 28 6.2 Delimitations...... 28 6.3 Research Methodology...... 29

7 USB Investigation 31 7.1 Raw Packet Analysis...... 31 7.2 Android LogCat Analysis...... 32 7.3 TLS Decryption...... 33

8 Future work 35

9 Conclusion 37

References 39

A CVSS3 Vector String 43 List of acronyms and abbreviations | vii

List of acronyms and abbreviations

ADB Android Debug Bridge

CVSS Common Vulnerability Scoring System

DHU Desktop Head Unit

DOS Denial-of-Service

IHU Infotainment Head Unit

MitM Man-in-the-Middle

SDK Software Development Kit viii | List of acronyms and abbreviations LISTINGS | ix

Listings

4.1 Detect when USB is plugged in...... 18 4.2 Detect when Android Auto is running...... 18 4.3 Task Hijacking manifest.xml...... 19 4.4 Intent Storm...... 21 4.5 SoundBlast...... 21 x | LISTINGS Introduction | 1

Chapter 1

Introduction

Modern vehicles are increasingly manufactured with touchscreen-based infotainment systems. They are primarily intended for GPS navigation, playing music, making phone calls and sending text messages. Additionally, the infotainment system provides an optional hands-free experience through the use of voice control. With technological advancements comes the desire to integrate several smartphone applications into the car software. When talking about an Android powered infotainment system, two diﬀerent types of systems exist. Android Auto is a platform that provides the opportunity to incorporate 3rd party apps into the infotainment system. Through the use of a USB or Bluetooth connection from an Android phone to the infotainment system Android Auto projects the app’s content onto the car touchscreen. Android Automotive is native to the vehicle’s operating system and is running directly inside of the infotainment system independently from any external device1. Android apps can easily be converted to a version compatible with Android Auto through simple manipulation of source ﬁles that regard app build tools and app design2. Viewing Android Auto compatible apps show a large supply available on the market3. Several 3rd party media and messaging apps, such as Spotify, Audible, various radio and

1 “What is Android Automotive? Android Open Source Project,”Oct 2020. [Online]. Available: https://source.android.com/devices/automotive/start/what_automotive Accessed 20201-04-16 2 Google, “Build media apps for cars,” 2021. [Online]. Available: https://developer.android.com/training/cars/media Accessed 2021-04-17 3 Apps for Android Auto.”[Online]. Available:https://play.google.com/store/apps/ collection/promotion_3001303_android_auto_all?hl=en&gl=SE Accessed 2021-05- 07 2 | Introduction

podcast stations, Facebook Messenger and many more are ready to be downloaded and projected to infotainment system displays worldwide. Adding apps to the app store is a beneficial way of marketing the app and ensuring users that the application is safer for download compared to an external platform because of the mandatory review performed by experts employed by the app store1. However, due to the human factor in the in the review stage, a slight security risk exists when analysing these apps. Research regarding manual threat modeling explain that the analysis process is prone to errors [1]. Consequently, bugs or exploits may remain in the published app that when downloaded potentially can lead to data breaches. Another issue with the review stage is how time-consuming manual threat modeling can be [2]. The Android app store is the official platform where Android applications are installed from. However, one study from 2020 reveals that these downloads may not be entirely safe. 87% of all app installs are made from the app store, but 67% of apps with malware also originate from the app store [3]. Additionally, the app store is not the single platform where apps are downloaded from. Downloading apps from external platforms that do not strive for user protection may consequently lead to user security becoming highly compromised. Due to the lack of research about Android Auto security it becomes a significant topic to explore in order to ensure user and road safety. Malicious apps may distract the driver, consequently endangering other drivers, cyclists or pedestrians. Android Auto requires extensive permissions in order to function properly, which means that if it were to be compromised, then the attacker would have almost full access to the device2. To mention a few permissions Android Auto has access to: location, system’s internal state, the microphone, full access to the calendar, text messages, contacts, call logs, Wi-Fi connection, the phone status & identity, access to find all accounts on the device, enabling and disabling components of other applications, modify system settings, prevent device from sleeping, etc. All these permissions could be used to essentially accomplish a near full takeover of the target device.

1 E. Kim, “Creating Better User Experiences on Google Play,” 2015.[Online]. Available: https://android-developers.googleblog.com/2015/03/creating-better-user- experiences-on.html Accessed 2021-05-07 2 Google, “Android Auto Google play page,” 2021. [Online] Available: https://play.google.com/store/apps/details?id=com.google.android.projection.gearhead Accessed 2021-04-13. Introduction | 3

1.1 Similar Platforms and Competitors

In addition to Android Auto, there exists other entertainment system platforms. Apple CarPlay is available for iOS devices on infotainment systems that support CarPlay1. Most cars that support CarPlay also support Android Auto. MirrorLink is an alternative to OS speciﬁc platforms2. MirrorLink does not require a USB connection, but works similarly to Android Auto and CarPlay in that the apps are powered by the phone and not the infotainment system itself. MirrorLink is not as widely supported as Android Auto and CarPlay when comparing the supported vehicles list.

1.2 Motivation

Creating a complex ecosystem that is impenetrable and secure from all types of attacks is a daunting task, and a project that is never complete. Vulnerabilities and exploits are found over time, and it is impossible for a group of developers at a company to find and patch them all, which is why many of the large technology companies use bounty programs, where independent hackers can submit vulnerabilities in exchange for a payout [4]. Not all hackers are ethical. Unethical hackers that encounter vulnerabilities and choose not to disclose the information to the company leave the attack vector open for other malicious actors. In the case of Android Auto, high security is of great significance since the application is to be used when operating a motor vehicle. If a malicious actor is able to distract, scare or annoy a driver, the driving performance may be greatly reduced [5,6] and could thus lead to a dangerous situation. A study found that drivers that were annoyed by urgent sounds showed a tendency to increase the throttle, and drivers that were shocked by a sound tended to release the throttle [7]. This effect may harm the traffic rhythm and endanger the road users. Penetration testing systems and platforms that integrate with an automotive interface is poorly researched, as most of the focus lies on finding vulnerabilities directly in the automotive interface or the platform connecting to it. However, research methods for evaluating automotive

1 “Carplay a way to connect a smart device to a vehicle.” [Online]. Available: https://www.apple.com/ios/carplay/ Accessed 2021-04-14. 2 “Mirrorlink the most ingenious way to bring smartphone content to the dash.” [Online]. Available: https://www.mirrorlink.com Accessed 2021-04-14 4 | Introduction

security by utilizing one system’s vulnerabilities to aﬀect another system are lacking. Discovering that the systems are challenging to penetrate would assure Android users to feel safe and comfortable with using Android services. Android Auto requires a great amount of accepted permissions in order to function. By knowing that malicious attackers struggle with accessing private data and property, Android Auto and 3rd party apps can continue developing and expanding their systems with the driver safety intact.

1.3 Problem Statement

The research question that arises is, what vulnerabilities exist in Android Auto and Android that potentially could put a driver in a dangerous situation by an attacker?

1.4 Purpose

The purpose of the thesis is to test if Android Auto targeted attacks are able to endanger a driver and access private data. The thesis aims to bring light to possible attack vectors that are relatively unexplored for Android Auto speciﬁc attacks in order for these vulnerabilities to be closed or mitigated. With the acquired knowledge, Android and Android Auto can be informed about the ﬁndings, which ultimately leads to an improved development of their security. Consequently, users will become more protected in terms of driver safety. This paper will use a method for evaluating the impact of certain exploitable vulnerabilities called Common Vulnerability Scoring System (CVSS)1 and argue for its implications in the context of driving experience.

1.5 Goals

The goal of this study is to conduct multiple penetration tests in order to gather an adequate amount of data to establish if Android and Android

1 Common Vulnerability Scoring System Version 3.0 Calculator [Online] Available: https://www.ﬁrst.org/cvss/calculator/3.0 Introduction | 5

Auto is sufficiently secure for road safety. To establish if Android and Android Auto is sufficiently secure, the study will discuss the significance of the consequences from successful and unsuccessful exploits. Additionally a USB investigation will be conducted to discover if it is possible to exploit Android Auto through the communication channel between the mobile device and infotainment system.

1.6 Scope of Research

This thesis does not include pen-testing or analysis of the Android Automotive operating system, Apple CarPlay or MirrorLink, as the area of focus is the Android Auto platform. The experiments have not been conducted on a physical Infotainment Head Unit (IHU) due to the lack of resources, an emulator referred to as the Desktop Head Unit (DHU) has been used as its replacement. The DHU will be treated as if it were an IHU in order to present the implications of potential exploits in the setting of the thesis. Results from the study may differ compared to experiments with an IHU, and these differences are detailed in the discussion section. The Android Auto application was not reverse engineered, and no binary exploitations were performed on it. The focus of the thesis is attacking Android Auto in a car setting, thus general purpose attacks against the Android operating system or the car firmware have not been considered. The exploits have been limited to those that affect the device running Android Auto and consequently may endanger and affect the driver security and experience.

1.7 Contributions

The findings from this study will contribute to the benefit of the Android Auto- and road users, since navigation, media and telephony are widely used in infotainment systems inside modern vehicles daily. Continued development of 3rd party apps justifies the demand to pen-test and insure that systems that are used on the road worldwide are safe. Discovering and learning about possible exploits and their potential negative use cases may lead to patches that eliminate the attack-vectors, thus creating a safer environment on the road for all. Research on the subject of Android Auto security is lacking, therefore this report will help build a foundation and bring breadth to the topic. 6 | Introduction

The thesis provides a foundation for further research into the topic and suggests attack vectors to investigate.

1.8 Attacks

In order to conduct research on potential exploits relevant to Android Auto it is crucial to analyze the attack surface 3rd party apps have access to. Since Android Auto functionality is separate from the car functions, potential targets for malicious apps are other mobile applications and the car’s infotainment system itself. The infotainment display could potentially crash or change brightness, app data could be leaked and the infotainment system volume could be tampered with. The report will closer examine these attack vectors through various exploits. One harmful exploit is Task hijacking that regards when a malicious application takes over the execution from a legitimate application. Instead of the phone opening a user’s authentic banking application, a visually similar application could be opened instead, extracting user credentials to a hacker’s server1 [8]. SoundBlast is an attack that targets the driver directly. The attack involuntarily modiﬁes the volume to max volume as media is played in the background. This attack does not require any special permissions and can easily be exploited by an application [9]. The purpose of an Intent Storm is to deplete the system resources, rendering the Android system unusable until it ultimately crashes. It is achieved by continually sending intents to reopen the application on several threads. Since opening applications is resource intensive, this will quickly use up all available resources [9].

1.9 Vulnerabilities in the USB Connection

In addition to purely software based attacks, the report will attempt to discover if it is possible to use the USB connection that the device uses to connect to the vehicle as an attack vector. All content shown on the screen of the DHU/IHU is projected from the device, which means that the data has to be transferred through the USB cable. This investigation

1 I. Markovic, “Android Task Injection aka "StrandHogg vulnerability",” 2019. [Online]. Available: https://github.com/Ivan-Markovic/Android-Task-Injection Accessed 2021-04-20. Introduction | 7

is signiﬁcant since control of the ﬂow of data between the device and the DHU/IHU could be an attack vector with serious implications.

1.10 Thesis structure

The remainder of the report is structured in 8 subsequent chapters.

• Chapter 2 describes the method of research.

• Chapter 3 discusses the related research.

• Chapter 4 describes the attack environment and details the penetration attacks utilized.

• Chapter 5 discusses the results obtained from the methods.

• Chapter 6 discusses the results.

• Chapter 7 presents the ﬁndings from the USB channel investigation.

• Chapter 8 mentions future work needed on this topic.

• Chapter 9 summarizes and concludes the ﬁndings of the study. 8 | Introduction Method of research | 9

Chapter 2

Method of research

This section describes the Research Methodology and concerns the methodological process of identifying a problem and traversing through necessary stages in order to accomplish a technical study to finally contribute to the scientific field.

2.1 Research Methodology

This paper is written in accordance with the DSRM [10]. The outline of the methodology and the way it was applied follows in the next subsections and can be viewed in ﬁgure 2.1. Some of the material has been presented in chapter1 but it is repeated below for completeness.

2.1.1 Problem Identification and Motivation As mentioned in 1.2, exploits leading to findings regarding Android Auto in terms of execution, driver safety and data leaks make it possible to draw conclusions about the state of Android Auto security. Apps published on the app store are reviewed by alleged experts before accepted1. A problems with manual analysis of apps is that there is a risk where malicious apps may proceed undetected and pass the control, thus containing code that compromises user integrity. It is essential to investigate if drivers are safe to use Android Auto due to the large audience that actively use its services. Since the topic lacks sufficient

Figure 2.1 – The adaptation of the design science research methodology used in this thesis. The work process was design & development centered and is thus the only entry point that is highlighted at the bottom of the ﬁgure. Method of research | 11

research about security and app exploits, it cannot be presumed that the application is safe for users.

2.1.2 Deﬁne the Objectives for a Solution As mentioned in 1.4, the objectives for a solution is to exploit an attack vector to distract or in another way endanger the driver’s life by attacking Android Auto. The goal is to write reproducible attacks that target Android Auto in such a way that the attention of the driver is required. Any successful attack has the potential to work on other applications as well, which makes this research applicable to other investigations in the application security sector.

2.1.3 Design and Development Previous research projects on Android related system security were the basis for the attacks in this thesis, since parts from these projects could be modiﬁed and used to target Android Auto. The attacks were designed to be executed on Android devices, since Android Auto solely runs on Android. The literature provided the foundation of theoretical and applied attacks that could be used as a foundation for crafting the attacks. The severity of the attack is determined by how complex the attack is and how easy it is to put into practice. The act of rating attacks based on severity required assessment of the characteristics of the attack, which were based on literature on vulnerability ratings.

2.1.4 Demonstration After the exploits had been developed they were adapted to the attack environment to experiment with the identified attack vectors. Distraction related exploits were conducted to discover if they had any significance on the device, which ultimately may affect the driver and road safety in general. Additionally, an exploit was utilized to find a procedure that enables the opportunity to extract sensitive user data through phishing. Resources required for the demonstration have been listed in chapter4.

2.1.5 Evaluation The attacks were evaluated by ﬁrst making sure that the attack was successfully executed, and subsequently rated based on their complexity 12 | Method of research

and how easy they were to exploit. These scores have been generated using the CVSS Version 3.0. Attack scores establish the severity of the software vulnerabilities in relation to other vulnerabilities. Unsuccessful attacks attain the severity score of zero and extremely severe attacks are rated a score of 10.

2.1.6 Communication and Contribution The process of using broad attacks and using them to target specific applications can be applied to research related to any Android applications security. The exploits provide an effective practice to validate if apps are safe against discussed attack vectors. All the findings of this thesis were reported to Google for evaluation.

2.2 Ethical Approach

Ethical hacking is about exploring and testing a system to determine what vulnerabilities exist and to discover if malicious parties are able to access sensitive information. The ethical hacking process commences with obtaining the consent from the owner of a system or network by agreeing upon the extent of the attacks. It has a systematic approach and ultimately leads to the company being informed about the vulnerabilities, thus leading to a fortiﬁed system where the attack vectors have been eliminated. However, hacking a system without following a certain set of rules is illegal and can lead to serious implications. Therefore, there are several moral and ethical obligations that needs to be followed to conduct ethical pen-testing [11]. These obligations include authorization, non- disclosure, conﬁdentiality and boundaries that will be described below.

2.2.1 Authorization Always gain the authorization of a system owner before pen-testing. Some vendors use bug bounty programs where they outline the rules and the scope of allowed pen-testing, without requiring every pen-tester to explicitly ask for permission. The bug bounty program that Google runs also includes Android Auto and the Android operating system. Method of research | 13

2.2.2 Non-disclosure Most pen-testers sign a non-disclosure agreement to ensure that no conﬁdential information is released before during or after the testing. Android Auto runs by Google, whose bug bounty program states that any research conducted on their products should be disclosed to Google and the results should not be posted publicly until after their 90-day disclosure deadline1.

2.2.3 Conﬁdentiality Never release any conﬁdential information about an individual, test or company to any third-party. The tests conducted in this thesis will not expose any personal information since all tests are run on emulators or the authors’ personal mobile devices. At no point was the personal information of other individuals or the intellectual property of Google at risk of being disclosed, uncovered or shared.

2.2.4 Boundaries Before pen-testing starts, it is important to know what is allowed and what is not allowed. Overstepping these boundaries could either be illegal or grounds for legal repercussions or other disciplinary action, such as being banned from the platform and/or unable to continue with the bug bounty program. The tests conducted in this thesis are within the boundaries of the law and the guidelines provided by Google for their bug bounty program.

1 “Application Security – Google.” [Online]. Available: https://www.google.com/about/appsecurity/ Accessed 2021-05-18. 14 | Method of research Related Research | 15

Chapter 3

Related Research

The most recent security research in the automotive area focus on on- board computers and systems and study their impact on the driving experience. The research often disregards Android Auto related attacks, since these attacks do not directly impact the vehicle itself. Android Auto apps are sometimes used as attack vectors. In an analysis of Android Auto apps found on the Google play store, 80% of the downloaded and tested apps showed warnings after static analysis, some 25% of apps were vulnerable to JavaScript attacks. The authors of the study also found that GPS data could be extracted without permissions and that media could be auto played, in contrast to Google’s Android Auto security standard [12]. In 2015 1.4 million vehicles were recalled by the manufacturer due to a serious security vulnerability where it was possible to remotely hack into the infotainment system. From here they could access the engine control unit to send other commands to similar car components. The exploit made it possible to affect the steering and brakes of the unmodified vehicle [13]. One study brings up the serious safety risk with allowing untrusted third-party code on Autonomous Vehicles. Several companies allow uncertified code on their platforms for the means of testing and development. However this poses a security threat. Followingly the study proposes an enhanced design of the Appified AV platform called AVGUARD to allow third-party developers to safely test their applications, thus mitigating the security issue [14]. Research conducted at the University of California, Berkeley concluded that less than a quarter of users paid attention to permissions granted 16 | Related Research

to applications on installation, and less than five percent comprehended what permissions were granted. This means that a lot of users give applications attack vectors without realizing it [15]. Another study at Berkeley investigated close to 1000 applications for overprivilege and found that around 300 were given more permissions than they used thus not adhering to the principle of least privilege [16]. Researchers at Instituto de Telecomunicações made a proof of concept of an attack that exploits a vulnerability in some vendors implementation of the Android system. The exploit uses a USB connection to exploit vendors implementation of serial AT commands to flash a compromised boot sector to gain root privileges, then enable Android Debug Bridge (ADB) to finally install surveillance software. The attack environment could be set up in a normal looking charging station, and install the surveillance software without the user ever knowing [17]. A collaborative study between CTS research center and Polytechnic Institute of Beja investigated vulnerabilities on Android devices by exploiting the ADB. The study found that by using a script on a computer, private data could surreptitiously be extracted from devices. For newer versions of Android, the user needed to accept the connection before the data extraction could begin [18]. Research into the security of MirrorLink concluded that the protocol used to communicate between the device and the infotainment system is exploitable if certain settings are changed. The research provided a proof-of-concept overflow attack that could be used to send messages to vehicles CAN bus [19]. A group of Master students from Chalmers University tested the Android Automotive operating system, and found that it was susceptible to attacks where the OS could crash, freeze or dangerously distract the driver. The students found several ways to extract private information from the vehicle without using any permissions [9]. This thesis has taken inspiration from this study by applying certain applicable attacks to Android Auto. Attacks and Attack Environment | 17

Chapter 4

Attacks and Attack Environment

This chapter contains two parts. Part one regards the environment setup for the exploits as the code environment and tools required for the attacks. In the next section, the attacks’ objectives and production methods are described in detail.

4.1 Attack Environment

The developed exploits were tested with a combination of emulators and physical hardware. The code was written in Android Studio version 4.1.3 on Windows 10 and executed on Android Software Development Kit (SDK) versions 21 to 30, Android versions 5 to 11. Tests were made on an emulated mobile device and a physical Samsung Galaxy S8, running Android version 9. The DHU emulator was retrieved from Android Studio. After downloading Android Auto, the developer mode was enabled in the application settings on the Samsung mobile device (for both physical and emulated devices). The developer mode needs to be activated to host a head unit server from the phone that uses the ADB to enable communication between the mobile device and the DHU. The head unit server was needed for both the physical- and emulated device to connect to the DHU via ADB. The physical device was connected to the computer running the DHU via USB through a USB 3.0 port. To ensure that the attacks only target the device when the user is driving, two checks were made. One check to see that the device was connected to a USB cable (listing 4.1), and one check that ensured that Android Auto was running by identifying the phone’s UI mode (listing 4.2). If the device was in the incorrect UI mode as the USB was plugged 18 | Attacks and Attack Environment

in, the device was only connected to a data transmitting device and not running Android Auto. If the UI mode was correct without a USB connection, the user had opened Android Auto but was not using the DHU and possibly not driving. However, a delimitation with the attack environment is that the USB connection could not diﬀerentiate between being connected to the DHU or another computer since both transmit data, (listing 4.1). Thus, the exploits could be launched in a scenario where Android Auto is running and connected to a computer via USB.

Listing 4.1 – Detect when USB is plugged in Intent intent = getApplicationContext().registerReceiver(null, new IntentFilter("android.hardware.usb.action.USB_STATE"));

/* * Detects if the device is connected to *a data transmitting device. Does not * differentiate between DHU and computer. */ if(intent.getExtras().getBoolean("connected")){ //USB connected to data transmitter }

Listing 4.2 – Detect when Android Auto is running Context c = getApplicationContext();

UiModeManager uiModeManager = (UiModeManager) c.getSystemService(Context.UI_MODE_SERVICE);

/* * Can only tell if Android auto is running or not * Not if it is connected toa DHU or IHU */ if (uiModeManager.getCurrentModeType() == Configuration .UI_MODE_TYPE_CAR) { //Android Auto is running } Attacks and Attack Environment | 19

4.2 Attacks

In this section the exploits are described in technical detail, how they function and the implemented approach to produce the exploits used in this thesis.

4.2.1 Task Hijacking Task hijacking revolves around making a malicious app take over the execution from a legitimate application by changing the app stack hierarchy and creating an affinity between the exploit and targeted package function in an application. StrandHogg 1.01 was used as the basis for this exploit and was achieved by manipulating the taskAffinity and task-reparenting attributes in the Android manifest file (listing 4.3). The purpose of these changes were to place the malicious activity at the root of affiliated and targeted program’s execution stack. Resultingly, when the legitimate app starts it is redirected to the malicious activity instead of the real application. Often times task hijacking exploiters design the malicious app very similar to the legitimate app in order to phish user input. As a result unaware users unknowingly enter private data into the hands of the hacker. The user would seemingly run a legitimate app inside, and compatible with Android Auto, but on the phone a malicious app would be launched as well. The intended outcome was to spoof the apps used by Android Auto in order to hijack the execution and modify the content projected on the display.

Listing 4.3 – Task Hijacking manifest.xml ...

1 https://promon.co/security-news/strandhogg/ 20 | Attacks and Attack Environment

Figure 4.1 – Illustration of how the StrandHogg exploit causes a legitimate app to be bypassed as the malicious application window launches in the foreground

4.2.2 Intent Storm Intent Storm is an attack that uses up the system resources in order to induce a crash or freeze. The attack works by creating one hundred threads in an app’s main activity, where each thread starts the applications main activity as a new task, thus creating a hundred new threads that perpetually open the application again (listing 4.4). This Denial-of-Service (DOS) attack will use up all the system resources, by utilizing the fact that creating, starting and running a new task is resource intensive. The attack will ensure that all available system resources are used to create and run the new instances of the application, thus rendering the device unresponsive and in most cases unusable. Although this attack runs on the phone, two checks (listing 4.1& 4.2) transform this attack into a targeted attack against the driver’s and passengers’ experience. To ensure that the exploit targets Android Auto speciﬁcally and no other application, the execution only begins when a USB is connected to the phone, and Android Auto is running. This is done by using Android’s scheduleAtFixedRate with a task that checks if the USB is connected and the phone is in UI_MODE_TYPE_CAR, when that is true, run the exploit. Attacks and Attack Environment | 21

Listing 4.4 – Intent Storm public class MainActivity extends AppCompatActivity { ... public void intentStorm(){ Intent main = getIntent(); for(int i = 0; i < 100; i++){ new Thread(new Runnable() { public void run(){ while(true){ startActivity(main); } } }).start(); } }

4.2.3 SoundBlast SoundBlast is designed to distract a driver by unexpectedly altering the volume playing on the infotainment system. The attack maximizes the volume of the audio stream on the phone, which shocks the driver and causes a distraction. By using Android’s built in Audio Manager, the programmer can programmatically set the volume of the application (listing 4.5). The desired outcome is a change in volume on the DHU as the phone volume changes.

Listing 4.5 – SoundBlast AudioManager am = (AudioManager)getSystemService(Context.AUDIO_SERVICE); am.setStreamVolume(STREAM_MUSIC, am.getStreamMaxVolume(STREAM_MUSIC),0); 22 | Attacks and Attack Environment Results | 23

Chapter 5

Results

This section presents the results of the exploits. Each exploit’s result will be presented in its subsequent sub-chapter. Table 5.1 contains a structured breakdown of the name, severity and category1 of the exploits. The CVSS values (calculated in A.1) displays the severity of the exploit on a scale from 0 to 10, where 0 signiﬁes a harmless exploit and 10 means that the exploit is extremely severe.

Exploits Name of exploit CVSS3 score Category SoundBlast 3.3 Audio/distraction IntentStorm 5.5 DOS/distraction Task Hijacking 6.1 Phishing

Table 5.1 – The exploits, with CVSS value and category

5.1 Task hijacking

Experimenting with task hijacking on Android Auto showed both success and failure when attempted depending on which Android version was used the targeted mobile device. On SDK 30 or Android version 11 the exploit was unable to hijack the application. However, Android versions 5-10 revealed a serious issue when launching Android Auto from the mobile phone. After ﬁrst starting the malicious app on the phone

1 The categories do not follow any particular categorization scheme, but have been chosen to explain the intended danger/impact of the exploit. Other categories may have been more appropriate, but it is not an important distinction in this context. 24 | Results

and later navigating elsewhere with the malicious app running in the background, it was possible to hijack Android Auto’s execution on the mobile device. Android Auto started in the background as the malicious application became the task in focus. However, attempting this exploit on the DHU emulator on PC did not show deﬁnitive results regardless of the SDK- and Android version. Despite running the exploit and afterwards launching Android Auto did not show any sign of a successful task hijack. A modiﬁed exploit that attacked applications used by Android Auto in the DHU, for instance Google Maps and telephony was unsuccessful as well. The exploit was ignored and the applications running inside of Android Auto started naturally.

5.2 Intent Storm

Attempting the Intent Storm exploit as the user started Android Auto revealed there is a big risk that a malicious app is able to cause Android Auto and the car infotainment display to freeze and stop functioning. The exploit was successful on all versions of Android that were tested (see 4.1). The malicious application was running in the background, waiting for the conditions (listings 4.1& 4.2) to be true before launching. As the exploit started, all mobile CPU resources were depleted, which immediately caused the DHU to completely stop. After several minutes the DHU crashed and the phone still suﬀered from unresponsiveness.

5.3 SoundBlast

The SoundBlast attack was automatically executed when the user had started the malicious app and the conditions (listings 4.1& 4.2) were met. The exploit showed the same result on all versions of Android that were tested (see 4.1). This exploit was partly unsuccessful because the change in volume was not detected on the DHU but rather on the phone itself. The volume could be set programmatically, which could executed in a loop to force the volume to always be increased to the maximum. The test was inconclusive as to whether or not the volume would change on an IHU. It was not possible to verify the change of volume on the DHU, since the emulator lacks volume controls and a volume indicator. Discussion | 25

Chapter 6

Discussion

This chapter will discuss the results of the exploits, the implications of the thesis’ delimitations and the inﬂuence of the chosen research methodology.

6.1 Attacks

In this section the results are discussed and evaluated in regards to their success, issues and expansion possibilities. Additionally, weaknesses of the exploits and potential countermeasures are considered.

6.1.1 Task Hijacking Running the DHU requires a local Android Auto server to be hosted on the phone. The StrandHogg 1.0 exploit was unsuccessful when attempted on the DHU because the server hosted on the phone uses an entirely new instance of Android Auto. The server also creates new instances of the apps available on the mobile device (media, navigation, telephony applications compatible with Android Auto). Therefore, task hijacking Android Auto locally on the device was a success where a server was not required. But the conducted experiments did not show that it was possible to execute the exploit to sever the connection between the Android Auto server and the DHU. Having access to a physical IHU would potentially show a diﬀerence of results, since a local server that does not manipulate and create new instances of the device applications in Android Auto would not be required. However, an IHU would unlikely open up opportunities to 26 | Discussion

target attacks on the apps inside Android Auto. The attempts to task hijack Google Maps and the telephony service in Android Auto showed unsuccessful results regardless if the phone was connected to the DHU or not. Thus, it does not seem probable that access to an IHU would lead to diﬀerent results for this experiment. Security researchers from Pennsylvania State University and Fire Eye Incorporated showed how task hijacking could be accomplished and proved that millions of apps were at risk [8]. This thesis has strengthened their claim and shown that it is possible to task hijack Android Auto. The exploit has a great weakness. When a malicious application with the StrandHogg exploit is opened on the phone, two application windows open. An innocent screen that represents a harmless application, and a "hacked" screen that can be designed to mimic a legitimate app. Opening the task manager on mobile after having started the StrandHogg application made it apparent that the malicious application is functioning out of the ordinary. Users that detect this anomaly can prevent the exploit by uninstalling the malicious application.

6.1.2 Intent Storm If a malicious phone application has been installed and is running in the background, it has the potential to crash the device at any time. The Intent Storm attack crafted to target the device when Android Auto was running successfully made the device freeze when the conditions were met. This type of DOS attack can be quite difficult to protect against, since the application can appear completely legitimate until certain criteria are met. To figure out what app caused the freeze could potentially be a difficult task, since it is developed to only run if Android Auto has launched and runs in the foreground. An exploit causing the mobile device to freeze or crash as Android Auto runs could endanger the driver. The driver would need to perform a manual restart, enter the PIN code, relaunch Android Auto and navigate to the GPS or media function that is desired. A study found that operation of the infotainment system distracts the driver and leads to an overall degraded driving performance [5]. The attack requires the malicious application to be running in the background in order for the Intent Storm to be executed. A user that frequently closes applications from the task menu is not likely to be affected by this attack, while users who rarely close applications are at Discussion | 27

greater risk. An issue with the attack is the possibility that users can invoke the attack when not driving. On all Android versions less than 28, Android Auto is visible in the application menu. A user with the app installed could open the application and connect their device to a computer or other data transmitting device which would invoke the attack, since all its criteria are met. To extend the attack, the application could ask for permissions to the location data, which could make speed a criteria for launching the attack. The application could also create a background service that could run indeﬁnitely, waiting for the criteria to be met before launching the attack. The background service would continue to run, even if the original application were to be closed.

6.1.3 SoundBlast Changing the volume unexpectedly could be dangerous for the driver [7]. If a driver is traveling at a high velocity, a sudden, unexpected loud sound could cause the driver to twitch and potentially lose control of the vehicle. Decreasing the volume without the driver’s permission could also result in road rage and distractions where the driver needs to manage the volume control, thus increasing the risk of a traffic accident. Lowering the volume as the driver expects to hear Google Maps directions for instance, could result in indecisive behavior from the driver thus endangering multiple road users. The potential risk could be increased if the application requests location data, and executes only if the vehicle is traveling faster than a certain speed where the driver’s attention is crucial. The exploit was successful in changing the volume, but due to the experimental setup it only changed the volume on the mobile phone. The emulated display played sound through the computer’s audio system, which naturally is isolated from the phone’s audio. Therefore, tests could not verify if the volume on the DHU was affected. However, it is possible that using the volume keys on the mobile device affects the volume on an IHU. This would mean that the attack would work on an IHU, but this claim is unverifiable without the required hardware. Developing the exploit is very simple and only requires a few lines of code and it has a few countermeasures. The application can without privileges set the volume of the device, and repeatedly setting the volume 28 | Discussion

will ensure that the user cannot mute or lower the volume. No eﬀective countermeasure was found except terminating the connection to the DHU, which could prove to be diﬃcult while driving.

6.1.4 CVSS 3.0 CVSS 3.01 is a useful metric when assessing the impact of a vulnerability. CVSS scores are sometimes used as a metric for prioritising security patches and bug ﬁxes, which is not recommended and should be used with caution due to the approximate nature of the scoring system [20]. The scores calculated are sometimes debated, where diﬀerent experts disagree on the assigned score for certain vulnerabilities [21]. CVSS scores are often uploaded to vulnerability databases along with their CVE record, and the databases do generally stay consistent with their scoring of the individual base metrics [22]. The vulnerabilities in this thesis have been assigned CVSS scores but they have not been uploaded to any vulnerability database, and have not been scored by a security expert. This thesis has presented CVSS scores, that should not be regarded as entirely reliable, but rather as an approximation of the risk that the exploits can implicate.

6.2 Delimitations

The thesis was focused on security implications of vulnerabilities in a vehicle setting. However, the vulnerabilities and exploits presented in this thesis could also be used in other contexts. Task hijacking could be used to steal usernames and passwords, read private messages or secretly record the user by phishing legitimate applications. It could also be used to request permissions to retrieve and manipulate otherwise inaccessible data on the phone. Since Android Automotive is part of the Android source code2 any attack against Android that can be exploited in a vehicle setting could also be exploited on Android Automotive. The Soundblast and Intent Storm attacks were based on Android Automotive oriented attacks. Task 1 Common Vulnerability Scoring System Version 3.0 Calculator [Online] Available: https://www.ﬁrst.org/cvss/calculator/3.0 2 “What is Android Automotive? Android Open Source Project,”Oct 2020. [Online]. Available: https://source.android.com/devices/automotive/start/what_automotive Accessed 20201-04-16 Discussion | 29

hijacking, originally crafted for Android running on mobile devices, could thus be used on Android Automotive where it would be harder to detect, since Android Automotive does not have a task menu.

6.3 Research Methodology

The design science research methodology (DSRM) utilized had a signiﬁcant inﬂuence on the outcome of this thesis. The work was design- and development centered, where design ideas were implemented and executed iteratively until the exploits became successful. Due to the methodology, a formal process model was provided that outlined the necessary stages and principles for conducting design science research on information systems. The methodology also provided an assisting structure for presenting and evaluating the results, thus facilitating the research process. 30 | Discussion USB Investigation | 31

Chapter 7

USB Investigation

One potential attack vector in exploiting Android Auto and the DHU is through the USB cable used for communication. By intercepting the channel, it may be possible to interact with the USB interface to block or alter communication sent from the mobile device to the DHU. The chapter investigates the USB communication in three sections. The ﬁrst looking at the raw packets, the second at Android Logs and the third at TLS decryption. Finally, the section presents the results that potentially can be used for exploiting Android Auto via USB.

Figure 7.1 – WRTE-block raw data

7.1 Raw Packet Analysis

A 3rd party program USBlyzer1 was utilized for investigating the raw packets sent between the DHU and the mobile device. The program revealed that several small data packets were sent regularly through the USB connection. These packets only consisted of 24 bytes, whereof the first four bytes formed the word WRTE (figure 7.1) or OKAY (figure 7.2), and the remaining 20 bytes were encrypted. WRTE and OKAY are

1 “USBlyzer” [Online]. Available: https://www.usblyzer.com/ Accessed 2021-05-12. 32 | USB Investigation

referenced in the ADB documentation1. This means that these keywords are part of the communication in the Android debugging tools that forwards the messages between the mobile device and the DHU. Analyzing the communication revealed a pattern of these messages. The packet containing WRTE was sent before transmitting a larger encrypted packet up to 5000 bytes in size (ﬁgure 7.3). When the recipient had received the packet, an acknowledging ACK was returned using the OKAY keyword.

Figure 7.2 – OKAY-block raw data

7.2 Android LogCat Analysis

The USB investigation proceeded by analyzing messages in Android LogCat to learn about the type of encryption used by Android Auto. Wireshark2 was used to capture all the logs generated by the device when opening the Android Auto application. By connecting the device to the DHU and starting Wireshark in Android Logcat Main mode revealed that Android Auto uses TLS 1.2 to communicate with the DHU. The logs show that the CAR.GAL.SECURITY package successfully initializes SSL context for protocol twice, before any logs from CAR.VIDEO are made. The logs did not provide any details about keys used for establishing an encrypted connection therefore trying to decrypt the message by obtaining data from the logs is not possible. The logs only indicate that an event has transpired or failed, without giving any details. The ﬁrst occurrence of the initialized SSL context is TLS 1.2 using the provider AndroidOpenSSL and the second case is TLS 1.2 using the provider GmsCore_OpenSSL. Further investigation show that the

1 “ADB Shell 0.3.2 Documentation.” [Online]. Available: https://adb- shell.readthedocs.io/en/stable/adb_shell.adb_device_async.html/ Accessed 2021- 05-12. 2 “Wireshark·Go Deep.” [Online]. Available: https://www.wireshark.org/ Accessed 2021-05-12. USB Investigation | 33

GmsCore_OpenSSL encryption originates from the CAR source package which in this case has the service_id 13. The associated logs with the service_id 13 are all related to setting up, and projecting services related to Android Auto.

Figure 7.3 – Encrypted-block raw data

7.3 TLS Decryption

There are a few attacks that are able to break and decrypt TLS 1.2. These attacks are built on Man-in-the-Middle (MitM) attacks. For instance, Zombie POODLE and GOLDENDOODLE are two attack that manages to recover encrypted messages into plain text when exploited1. Using these discovered exploits to decrypt the raw data retrieved in section 7.1 could reveal critical information that opens up for continued research and penetration-testing on Android Auto. Potentially it would be possible to alter the raw data to modify projected data on the DHU or send malicious commands to the devices. If the library used to encrypt the data is based on OS version, any device running on an older version might be vulnerable to known attacks [23]. However, due to the lack of time this assignment will be left as future work for interested parties.

1 “NVD - CVE-2019-6593.” [Online]. Available: https://nvd.nist.gov/vuln/detail /CVE-2019-6593 Accessed 2021-05-12 34 | USB Investigation Future work | 35

Chapter 8

Future work

One major suggestion for future work is obtaining a physical IHU in order to attempt similar exploits to obtain concrete results that indicate the state of Android Auto in a car setting. The StrangHogg 1.0 and SoundBlast exploits executed in this thesis are of particular interest since the results obtained applied to the emulated DHU. These tests could lead to a diﬀerent set of results from experiments with an IHU. In addition to hijacking tasks, further research should be made to investigate the possibility to hijacking services, since a lot of the applications run in Android Auto are run as services instead of tasks. If it was possible to hijack a service, it would be possible to show a malicious application instead of Google Maps, the built-in messaging application or the telephony application. One attack vector that deserves more research is to decrypt the USB communication between the DHU/IHU and the device, which potentially could expose sensitive data that opens up for manipulation. The device uses the Android Auto Projection Protocol to communicate with the DHU/IHU, which means that research into potential vulnerabilities in this protocol could lead to an eﬀective attack vector. 36 | Future work Conclusion | 37

Chapter 9

Conclusion

This thesis has investigated the security of the Android Auto application in regards to road safety. By attacking and exploiting vulnerabilities in the Android operating system, attacks were crafted that directly target the user when driving. In various situations the findings demonstrate that Android Auto is not secure for road safety depending on how the application is used. Running Android Auto locally on the phone without connecting it to a DHU or IHU showed a greater risk of successful exploits that compromise driver safety and user data. Task hijacking was able to take over execution, Intent Storm managed to crash the mobile and SoundBlast could change the volume without user input. However, the results from running Android Auto on the DHU indicated user security. Intent Storm managed to completely freeze and crash the DHU, which may endanger a driver by making them lose attention on the road and instead focus on restarting the unresponsive infotainment system. The USB investigation revealed details about the encrypted communication between the device and DHU. It is possible to use existing exploits to decrypt the encrypted data, where modification of the content may lead to different exploits that manipulate information on the infotainment display that reduces Android Auto security. The relevancy of the thesis is apparent since a driver’s life could be put at risk. Task hijacking could show a malicious version of a maps software and lead the user to another location than the user did not intend. SoundBlast could cause the driver to make uncontrolled movements, leading to a loss of control of the vehicle, or create a distraction which makes the driver less attentive to their surroundings. The USB findings set the foundation to investigate the possibility of attacks that could put 38 | Conclusion

the user’s data at risk. Inspiring future research to be conducted on the subject means that more possible vulnerabilities get patched and road safety increases. REFERENCES | 39

References

[1] H. Holm, M. Buschle, R. Lagerström, and M. Ekstedt, “Automatic data collection for enterprise architecture models,” Software & Systems Modeling, vol. 13, no. 2, pp. 825–841, 2014.

[2] P. Närman, P. Johnson, R. Lagerström, U. Franke, and M. Ekstedt, “Data collection prioritization for system quality analysis,” Electronic Notes in Theoretical Computer Science, vol. 233, pp. 29–42, 2009. doi: https://doi.org/10.1016/j.entcs.2009.02.059 Proceedings of the International Workshop on Software Quality and Maintainability (SQM 2008).

[3] P. Kotzias, J. Caballero, and L. Bilge, “How Did That Get In My Phone? Unwanted App Distribution on Android Devices,” ArXiv, vol. abs/2010.10088, 2020.

[4] A. Y. Ding, G. Limon De Jesus, and M. Janssen, “Ethical Hacking for IoT Security: A First Look into Bug Bounty Programs and Responsible Disclosure,” arXiv e-prints, Sep. 2019.

[5] T. Horberry, J. Anderson, M. A. Regan, T. J. Triggs, and J. Brown, “Driver distraction: The eﬀects of concurrent in-vehicle tasks, road environment complexity and age on driving performance,” Accident Analysis & Prevention, vol. 38, no. 1, pp. 185–191, 2006.

[6] A. L. Glaze and J. M. Ellis, “Pilot study of distracted drivers,” Transportation Safety Training Center for Public Policy, 2003.

[7] E. E. Wiese and J. D. Lee, “Auditory alerts for in-vehicle information systems: The eﬀects of temporal conﬂict and sound parameters on driver attitudes and performance,” Ergonomics, vol. 47, no. 9, pp. 965–986, 2004. doi: 10.1080/00140130410001686294 40 | REFERENCES

[8] C. Ren, Y. Zhang, H. Xue, T. Wei, and P. Liu, “Towards discovering and understanding task hijacking in android,” in 24th USENIX Security Symposium (USENIX Security 15). Washington, D.C.: USENIX Association, Aug. 2015. ISBN 978-1-939133-11-3 pp. 945– 959.

[9] B. Eriksson, J. Groth, and A. Sabelfeld, “On the Road with Third- Party Apps: Security Analysis of an In-Vehicle App Platform,” Master’s thesis, Gothenburg, Sweden, 2019.

[10] K. Peﬀers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A Design Science Research Methodology for Information Systems Research,” Journal of Management Information Systems, vol. 24, no. 3, pp. 52–60, 2007.

[11] K. Graves, CEH: Certiﬁed Ethical Hacker Study Guide, 1st ed. USA: SYBEX Inc., 2010. ISBN 1978-0-470-52520-3

[12] A. Mandal, A. Cortesi, P. Ferrara, F. Panarotto, and F. Spoto, “Vulnerability analysis of android auto infotainment apps,” Proceedings of the 15th ACM International Conference on Computing Frontiers, 2018.

[13] Dr. C. Miller and C. Valasek, “Remote exploitation of an unaltered passenger vehicle,” Black Hat USA, vol. 2015, no. S 91, 2015.

[14] Y. Jia, D. Zhao, Q. A. Chen, and Z. Mao, “Towards Secure and Safe Appiﬁed Automated Vehicles,” 06 2017. doi: 10.1109/IVS.2017.7995800 pp. 705–711.

[15] A. P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and D. Wagner, “Android permissions: User attention, comprehension, and behavior,” in Proceedings of the Eighth Symposium on Usable Privacy and Security, ser. SOUPS ’12. New York, NY, USA: Association for Computing Machinery, 2012. doi: 10.1145/2335356.2335360. ISBN 9781450315326

[16] A. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner, “Android permissions demystiﬁed,” Proceedings of the ACM Conference on Computer and Communications Security, pp. 627–638, 10 2011. doi: 10.1145/2046707.2046779 REFERENCES | 41

[17] A. Pereira, M. E. Correia, and P. Brandão, “USB Connection Vulnerabilities on Android Smartphones: Default and Vendors’ Customizations,” vol. 8735, 09 2014. doi: 10.1007/978-3-662-44885- 4_2

[18] J. Amarante and J. P. Barros, “Exploring usb connection vulnerabilities on android devices - breaches using the android debug bridge,” 01 2017. doi: 10.5220/0006475905720577 pp. 572–577.

[19] S. Mazloom, M. Rezaeirad, A. Hunter, and D. McCoy, “A security analysis of an in vehicle infotainment and app platform,” in Proceedings of the 10th USENIX Conference on Oﬀensive Technologies, ser. WOOT’16. USA: USENIX Association, 2016, p. 232–243.

[20] R. Rieke, “Modelling and analysing network security policies in a given vulnerability setting,” in International Workshop on Critical Information Infrastructures Security. Springer, 2006, pp. 67–78.

[21] H. Holm and K. K. Afridi, “An expert-based investigation of the common vulnerability scoring system,” Computers & Security, vol. 53, pp. 18–30, 2015.

[22] P. Johnson, R. Lagerström, M. Ekstedt, and U. Franke, “Can the common vulnerability scoring system be trusted? a bayesian analysis,” IEEE Transactions on Dependable and Secure Computing, vol. 15, no. 6, pp. 1002–1015, 2018. doi: 10.1109/TDSC.2016.2644614

[23] A. Razaghpanah, A. A. Niaki, N. Vallina-Rodriguez, S. Sundaresan, J. Amann, and P. Gill, “Studying tls usage in android apps,” in Proceedings of the 13th International Conference on emerging Networking EXperiments and Technologies, 2017, pp. 350–362. 42 | REFERENCES Appendix A: CVSS3 Vector String | 43

Appendix A

CVSS3 Vector String

Table A.1 contains the CVSS3 vector strings that were used to calculate the CVSS value of the exploits.

Exploits Name Vector String SoundBlast CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N/E:F IntentStorm CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H/E:F Task Hijacking CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:L/E:F

Table A.1 – The exploits, with their CVSS3 Vector String TRITA-EECS-EX-2021:249