INOM EXAMENSARBETE DATATEKNIK,GRUNDNIVÅ, 15 HP

, STOCKHOLM SVERIGE 2020

Penetration testing of Android applications

ROBIN NILSSON

KTHSKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP

Abstract The market of Android applications is huge, and in 2019, Google Play users worldwide downloaded 84.3 billion mobile applications. With such a big user base, any security issues could have big negative impacts. That is why penetration testing of Android applications is important and it is also why Google has a bug bounty program where people can submit vulnerability reports on their most downloaded applications. The aim of the project was to assess the security of Android applications from the Google Play Security Reward Program by performing penetration tests on the applications. A threat model of Android applications was made where potential threats were identified. A choice was made to focus on the Spotify Application for Android where threats were given ratings based on risks associated with them in the context of the Spotify Application. Penetration tests were made where testing depth was determined by the ratings associated with the attacks. The results of the tests showed that the Spotify Application is secure, and no test showed any real possibility of exploiting the application. The perhaps biggest potential exploit found is a Denial of Service attack that can be made through a malicious application interacting with the Spotify application. The result doesn’t guarantee that the application isn’t penetrable and further testing is needed to give the result more reliability. The methods used in the project can however act as a template for further research into both Spotify and other Android applications. Keywords - Ethical hacking; penetration testing; Android application security; reverse engineering; threat modeling

Sammanfattning Marknaden för Android applikationer är enorm och 2019 laddade Google Play användare ner 84.3 miljarder mobil-applikationer. Med en så stor användarbas kan potentiella säkerhetsproblem få stora negativa konsekvenser. Det är därför penetrationstest är viktiga och varför Google har ett bug bounty program där folk kan skicka in sårbarhetsrapporter för deras mest nedladdade applikationer. Målet med projektet är att bedöma säkerheten hos Android applikationer från Google Play Security Reward Program genom utförande av penetrationstester på applikationerna. En hotmodell över Android applikationer skapades, där potentiella hot identifierades. Ett val att fokusera på Spotify för Android gjordes, där hot gavs rankingar baserat på riskerna associerade med dem i kontexten av Spotify applikationen. Penetrationstest gjordes med testdjup avgjort av rankingarna associerade med attackerna. Resultatet av testen visade att Spotify applikationen var säker, och inga test visade på några riktiga utnyttjningsmöjligheter av applikationen. Den kanske största utnyttjningsmöjligheten som hittades var en Denial of Service-attack som kunde göras genom en illvillig applikation som interagerar med Spotify applikationen. Resultaten garanterar inte att applikationen inte är penetrerbar och fortsatt testande behövs för att ge resultatet mer trovärdighet. Metoderna som användes i projektet kan i alla fall agera som en mall för fortsatt undersökning av både Spotify såväl som andra Android applikationer. Nyckelord - Etisk hacking; penetrationstest; Android-applikationssäkerhet; baklängeskonstruktion; hotmodellering

Table of Contents

1 Introduction 11.1 Themerelevance.......................................................................................................................11.2 Objective......................................................................................................................................11.3 Delimitations.............................................................................................................................11.4 Projectrelevance......................................................................................................................1

1.5Reportoutline.…………..............................................................................................................1

2 Background/Theory 22.1 AndroidOS.................................................................................................................................22.2 Androidapplication.................................................................................................................42.3 Androidsecurityimplementations....................................................................................5

3 Methodology 6

4 SystemdescriptionofSpotify 7

5 Threatmodel 85.1 Threatmodeldiagramandtable...........................................................................…………85.2 Regardingthereferencesusedforthethreatmodeling.............................................125.3 ThethreatsappliedtoSpotifyforAndroid......................................................................145.4 Motivationforchoiceofattackstotestandtheirtestingdepth...............................16

6 Penetrationtesting 166.1 Reverseengineeringattacktofindsensitivedataintheapplicationcode………166.2 Reverseengineeringattacktomakepackagealterations.........................................186.3 Maninthemiddleattack.......................................................................................................216.4 LookingattheinnerfilesoftheAndroiddevice...........................................................226.5 Databaseattack.........................................................................................................................246.6 Intentinjectionattack.............................................................................................................266.7 Cross-sitescriptingattack......................................................................................................276.8 ReadingofimplicitIntentwithsensitivedata.................................................................296.9 UsingADBshelltoexploreinternalapplicationpages................................................306.10Backendserverattacks...........................................................................................................31

7 Ethicsandsustainability 33

8 Results 33

9 Discussion 34

10 Conclusions 34

References 35

1

1 Introduction

1.1 Theme relevance

The mobile application market is huge, and in 2019, Google Play users worldwide

downloaded 84.3 billion mobile applications [46]. There is no denying that

vulnerabilities in these applications could affect a lot of people negatively. That is why

there is a need for security tests on the applications and it is also why Google has a

rewards bug bounty program giving out big money to people submitting vulnerability

reports on their most downloaded applications.

1.2 Objective

The objective of the project is to assess the security of Android applications qualified to

the Google Play Reward Program because of their 100 million or more downloads [47].

The assessment of the application will be made through penetration tests. The purpose

is not necessarily to find vulnerabilities within the system; it could rather be a

demonstration of a secure application which was not penetrable within given delimiters.

1.3 Delimitations

The delimitations brought upon the project is that of time and resources. Due to time

restrictions only the one application was assessed. Namely the Spotify application,

because finding vulnerabilities in an application with a big userbase would have a bigger

impact than finding them in an application with only a few users. Some of the possible

attacks were given less depth because of time limitations. Due to resource limitations,

some of the possible attack surfaces were not tested.

1.4 Project relevance

The project could be relevant to millions of people using the application, if

vulnerabilities are found and mitigated. As well as for other applications on the Google

Play Store, since Google uses vulnerabilities in the submitted reports to scan for similar

vulnerabilities in their other applications [48]. If, however the project does not find any

vulnerabilities, it could still be relevant to security researchers as a testing method

template for other Android Applications, as many of the themes do reoccur within the

applications on the Google Play Store. It could also help Spotify security testers see what

penetration tests already have been proven unsuccessful and may not need further

testing.

1.4 Report outline

In chapter 1, the project is introduced.

2

In chapter 2, a background to Android is given with explanation of the operating system,

an android application and some security implementations.

In chapter 3, the methods used in the project are described along with motivations for

picking them.

In chapter 4, a system description is made of Spotify for Android.

In chapter 5, the result of the threat modeling is presented in diagram and tables. This is

followed by an explanation of the sources used to help guide the threat modeling

process.

In chapter 6, the penetration tests are described along with discussions about the

validity of their results.

In chapter 7, the ethics and sustainability revolving the project is discussed.

In chapter 8, the results of the penetration testing are summarized.

In chapter 9, the validity of the results of the penetration testing are discussed as well as

the relevance of the result of the project.

In chapter 10, the conclusions that are drawn from the project result is presented.

2 Background/Theory

2.1 Android OS

The Android operating system is based on a modified version of the Linux Kernel. The

operating system is based on open source software and uses ARM for its hardware

platform. Later versions of Android OS support x86 and x86-64 architectures. The

system is mainly designed for touchscreen mobile devices. Because of the system’s open

nature, consumers are able to create content for the system which enables a big number

of ideas to be generated for the platform, while at the same time making it possible for

malicious activities with their system. Things like hiding viruses with tracking abilities

and or data stealing could be very harmful to the system’s users. [25]

3

The OS is divided into five main layers. The Linux Kernel, Libraries, Android runtime,

application framework and the applications layer.

Figure 1 showing the architecture of Android, retrieved from: https://www.elprocus.com/what-is-

android-introduction-features-applications/

The Linux Kernel is the bottom layer and works as an abstraction layer between the

software and hardware of the device it runs on. The Kernel is responsible for managing

input and output requests from the software. The Kernel contains drivers to handle

input hardware. The Kernel also handles system functionalities such as management of

processes and memory as well as security and networking.

Libraries is made up of various C/C++ core libraries provided with several open source

tools. To give some examples we have WebKit which is an open source web browser

engine that provides web browsing functionalities, OpenGL which provides a cross-

platform API to produce 2D and 3D computer graphics. We also have SSL which stands

for Secure Socket Layer and provides secure internet communication.

Android Runtime provides an application runtime environment to the OS by

translating bytecode into native instructions that are executed by the runtime

environment of the device. Dalvik virtual machine was based on Java virtual machine to

be better suited for the Android OS but was replaced by the Android Runtime in later

versions of the OS.

4

Applications framework provides application developers with high-level services

such as Window Manager, Content Providers, Activity Manager and View System.

Giving the developer prebuilt functionalities to their applications. Where the for

example View System builds the user interface handling views and layouts.

Applications is the top layer of the android architecture and is where applications are

written and installed. Applications can be everything ranging from pre-installed

applications to third-party installations. [20]

2.2 Android application

Android applications can be written in Java, Kotlin or C++ languages and the Android

SDK tools can be used to compile code and resources into an Android package or APK

for short. The APK is an archive file containing all the contents of the application and is

the file used to install applications on the Android devices. The APK includes a

classes.dex folder with source code classes compiled in dex file format which is

understandable by Android Runtime. It also has a resources folder with strings and

images and xml-layout. The APK also includes an AndroidManifest.xml file that

contains information about the application such as the applications package name, the

components, the permissions the application requires, and the software and hardware

features the application needs. For security reasons the AndroidManifest.xml file

contains information of how the applications components can be started through

something called intent filters. There are four types of Components within Android

applications: Activities, Services, Broadcast Receivers and Content Providers. [24]

Activities represent a single screen with a user interface and is the entry point to user

interaction.

Services are general-purpose entry points for keeping applications running in the

background. It might for example be playing music in the background or fetching data

over the internet without interrupting the current user activity.

Broadcast Receivers enables the system to deliver events to applications outside of

the regular user flow. They can even deliver broadcasts to applications that are not

running. A lot of broadcasts come from the system itself such as events of screen turning

off or low battery. But it could also come from applications for example telling another

application that a photo has been downloaded and can be used by that application.

Content Providers manage a shared set of data that can be stored within the device’s

file system as well as on the web using for instance SQLite database. Upon permission

other applications can query and modify data through the content provider.

5

In order to activate activities, services and broadcast receivers Intents are used. The

intent can either be implicit or explicit. An implicit intent activates a particular type of

component while an explicit intent activates a specific component. Content providers

however are activated through a targeted request from a ContentResolver. [45], [22]

2.3 Android security implementations

There are two levels of enforcement mechanisms for protection of Android, one at the

System level and one at the Inter Component Communication (ICC) level. At the system

level we have something called Application Sandboxing where each Application is

assigned a unique user ID (UID) and is run as a separate process. So, if for instance an

application tries to read data from another application, this is prevented by the fact that

the application does not have the right user privileges to read the data. A permission

model is used on the applications, where the user decides which functions of the device

to grant to the application. This can for instance be sensitive functions like camera,

internet or position access. This is to enable the user to prevent malicious applications

from getting access to the device’s resources. [23]

At the ICC level, the AndroidManifest.xml file contains information regarding the

allowed communication that can take place between application components. For

example, if an exported attribute of a component is set to false, the component is private

and only accessible within the application it originates. [23]

Android applications are required to be signed digitally; a private key is used to sign the

applications. This key can then be used by the application developer to for example

update their application on the Google Play Store or share data between applications.

The signing mechanism is great to prevent reverse-engineered malicious versions of

applications from replacing the original version on the Play Store.

Newer versions of Android also feature file-based encryption that enables different files

to be encrypted with different keys allowing the files to be unlocked independently.

Trusted Environment Execution is also a security feature of Android in which an

isolated area of the main processor is used to perform protected operations such as

storing secret data. Verified Boot is also a security feature of Android OS where a chain

of trust starts from the hardware-protected root to the boot loader, to the boot partition

as well as other verified partitions. This is used to ensure that executed code comes from

trusted sources. [21]

OAuth 2.0 is a delegation protocol that provides authorization flows used by a lot of

Android applications and enables the applications to obtain limited access to HTTP

services by delegating the user authentication process to the service hosting the user

6

account. It also allows for third-party application access to the user account if the user

grants the application the privileges for it. An example flow of the protocol is that an

application requests authorization to access the server from a user, the user accepts the

request and the application requests an access token from the authorization server,

authenticating with the application identity and authorizing by the grant from the user.

Upon successful authentication and authorization, the server issues an access token to

the application that can now be used to make API calls to the server for a limited period

of time. [43], [44]

3 Methodology The start of the project consisted of a theory phase where a lot of information about

Android and its applications was gathered. As well as information about the thesis

project itself such as what methods to use throughout the project. This was a useful

backbone when starting the next step of the project which was threat modeling.

“Threat modeling is the use of abstractions to aid in thinking about risks.” according to

Shostack [10]. It is meant to be a helpful tool in aiding with risk identification and thus

it is not about strictly following a guide but rather to use the methods that suits your

own system and actually has some use. That is why in this project a choice was made to

combine different methods based on how they helped in identification of threats to the

Android applications. Following the five steps in Synopsis’ 5 pillars of a successful threat

model, a diagram of the Android system and its different data flows and trust

boundaries were drawn [1].

A concept called STRIDE was used, where STRIDE stands for Spoofing, Tampering,

Repudiation, Information disclosure, Denial of Service and Elevation of Privilege.

Spoofing is to make the system believe that you are someone or something that you are

not. Tampering is to modify data which is not supposed to be modified. Repudiation is

to deny or contest that you have done something, for example received an email or

virtually signed a contract. Denial of Service is when an attacker prevents a server from

providing its service by crashing it, filling its memory or making it slower. Elevation of

privilege is when a program or user gets permissions of higher privileges than originally

intended. A Separation of threats into these categories helped in coming up with

potential threats to the system. [10]

Another method to come up with threats to the system was to make use of already made

research in the field. OWASP, a non-profit foundation working to improve software

security, has a top 10 threat list for mobile applications which was really useful in

coming up with threats as well as other sources mentioned in chapter 5.2 of this report.

By combining different literature and internet articles a more thorough threat model

was created. [3]

7

Continuing with steps from the Synopsis’ article, a threat traceability matrix was created

for each possible attack found. A traceability matrix is used to examine the different

threat agents in a structured manner with the columns: threat agent, asset, attack,

attack surface, attack goal, impact and control in accordance with the Synopsis article.

Threat agent is the person or group that constitutes the threat to the system. Asset is

something that is valuable to the company that owns the application or to an attacker.

Attack is the type of attack that can be performed by the threat agent when trying to get

access to the asset. Attack surfaces are found where there are trust boundaries in the

system and show where an attacker interacts with the system to launch attacks. Attack

goal is what the attacker wants to achieve from the attack. Impact is what negative

consequences a successful attack could have and who are affected. Control is what

mitigation measures that can be taken to avoid, make it harder or at least a reduce

negative impacts of the attack. [1], [10]

The next step was the preface of the penetration testing. Before choosing which test to

start with and how much time to spend on the different tests, the threat traceability

matrix was used to determine this. It showed potential impacts of the different attacks

in combination with showing how to control the attack. If an attack showed to be both

easy to perform and had a big potential impact, the attack was given high priority for the

penetration testing meaning it could be given more time as well as be carried out earlier.

This type of ranking of the threats is sort of similar to the DREAD system where ratings

are given based on damage, reproducibility, exploitability, affected users and

discoverability [49]. Though because of time restrictions as well as the fact that most of

the possible attacks were going to be penetration tested anyway, a choice was made to

give a bit less consideration to the rankings and rather just decide which attacks were

high, medium and low priority to test.

The next step was the actual penetration testing. The methods for testing the different

attacks were highly dependent on what they were, but what they all had in common was

that they all started with a theory phase where the attacking method was studied via

literature before actually trying the attacks. Another thing the tests had in common was

a result phase where the result of the attack was written down along with a discussion

on the relevance and validity of the findings.

4 System description of Spotify The system under consideration is the Spotify application for Android. For those who

are unfamiliar with Spotify, it is an application that offers music streaming to logged in

users. The Android application authenticates requests with OAuth 2.0, which is

described in chapter 2.3 of this report [44]. By having a valid OAuth access token in the

request header, the application is able to send requests to the Spotify Web API. The

8

requests are sent based on REST principles. This means that the request contains URI

for resource identification and HTTP verbs like GET and POST for action determination.

The response data is always returned as JSON objects in Spotify’s case. Through the

response data the application is able to display track Metadata as well as play songs

from the Spotify web servers.

As for the application itself, it uses Dagger for dependency injection. It uses GSON and

Jackson for serialization and deserialization of Objects. The application also uses

comScore, Moat and Crashlytics for analytics of the application. The application uses

Firebase for handling push notifications and it uses Proguard for App obfuscation. The

application features Bluetooth functions where you can remotely control song playback

by linking your application to for example a speaker device, or a car. There are

numerous other libraries and frameworks used by the application, but these can at least

help exemplify the type of dependencies the application has.

5 Threat model

5.1 Threat model diagram and table

Below are the diagram and tables created by following the method described in chapter

3 of this report.

Figure 2 showing a generic Android applications attack diagram. Arrows indicate data flow; green stripes

indicate trust boundaries

9

Figure 2 was used to come up with the possible attacks described in the threat

traceability matrices shown below.

Table 1.1: Threat traceability matrix for Bluetooth hacking [11]

Threat agent Asset Attack surface Attacker in close proximity to the user

Sensitive information Bluetooth connection with application

Attack goal Impact Control Access confidential data, use Bluetooth functions maliciously, denial of service

Personal data leak, reputational damage, denial of service.

Be wary of using Bluetooth functions that have access to sensitive data.

Table 1.2: Threat traceability matrix for Reading of sensitive data from implicit

application Intent [6], [11]

Threat agent Asset Attack surface Malicious application Sensitive information Android device Attack goal Impact Control Access sensitive data Data leakage, personal integrity

loss, application company integrity reputation damage, lawsuits

Don not send sensitive data with implicit Intents.

Table 1.3: Threat traceability matrix for Intent injection attack [13]

Threat agent Asset Attack surface Malicious application Sensitive information, privileged

application functions Android device

Attack goal Impact Control Access sensitive data, access unauthorized functions.

Data leakage, identity theft, reputational damage,

Verify that actions and data are validated via an Intent filter for all Activities.

Table 1.4: Threat traceability matrix for Cross-site scripting attack [14], [15]

Threat agent Asset Attack surface Malicious application Sensitive information, privileged

application functions, whatever asset is obtainable through server transactions

Android device

Attack goal Impact Control Access sensitive data, session hijacking

Identity theft, data leakage, reputational damage, fraud, potential stealing of user assets connected to the application service.

Use safe APIs, sanitize input, use safe ways of displaying data.

10

Table 1.5: Threat traceability matrix for Man In the middle attack [3], [9], [11]

Threat agent Asset Attack surface Malicious user on the same network

Sensitive information, whatever asset is possible to send via internet transactions.

Client/server network

Attack goal Impact Control Read and alter client/server communication to gain information and impersonate both parties to gain other potential assets.

Application integrity damage, privacy loss, identity theft, fraud, data leakage, denial of service, potential transferring of money from client to attacker etc. Lawsuits

Encrypt messages with HTTPS communication, use pinning, use certificate transparency

Table 1.6: Threat traceability matrix for Malicious code injection through file processing

of application [11], [14]

Threat agent Asset Attack surface Careless user installing malicious files on SD card.

Sensitive information, privileged application functions

Application processing user files.

Attack goal Impact Control Gain access to user device Information theft, users giving

control of Android devices to attackers and whatever they choose to do with it, application company reputation loss. Lawsuits

Carefully handle user file processing. If using buffers, check that the input length is as expected.

Table 1.7: Threat traceability matrix for Reverse engineering attack to find sensitive data

in the source code of the application [3], [9]

Threat agent Asset Attack surface Malicious user using Android Debug Bridge with application

Sensitive data APK file of the application

Attack goal Impact Control Find sensitive data and weak points in the application. Find hidden functions and testing code.

Data leakage, intellectual property theft, reputational damage, identity theft, compromised backend servers, bridge to further attacks.

Obfuscate code using for example Proguard. Do not store sensitive data in app source code. Check that no test code is left in the final production build of the application.

Table 1.8: Threat traceability matrix for Finding sensitive information within the

device’s file system [3], [9], [11]

Threat agent Asset Attack surface Malicious user using Android Debug Bridge on Android device

Sensitive data Android Debug Bridge to access the Android device’s file system

Attack goal Impact Control Find and read/alter sensitive data

Identity theft, privacy violation, fraud, data loss, application company reputation damage, material loss, External policy violation

Do not store unnecessary data in local device storage, or at least use secure encryption.

11

Table 1.9: Threat traceability matrix for Database hacking [11], [16]

Threat agent Asset Attack surface Malicious user making server requests

Sensitive data, data giving access to company assets

Server to database of application

Attack goal Impact Control Read, delete and modify application data.

Data leakage and data privacy loss, bad reputation for the company, gaining company assets through database alterations, lawsuits.

Handle user input carefully, Configure the database to only allow the authorized user access to the appropriate data read and alterations.

Table 1.10: Threat traceability matrix for Backend server attacks [3], [9]

Threat agent Asset Attack surface Malicious user making server requests

Sensitive data, privileged functions

Server connected with application

Attack goal Impact Control Access privileged functions and sensitive data from application server

Unauthorized access to data and functions, data theft, reputational damage, lawsuits

Use secure authorization and authentication processes before allowing privileged server request to application server

Table 1.11: Threat traceability matrix for Reverse engineering to repackage applications

with malicious alterations [3], [9], [12], [8]

Threat agent Asset Attack surface Malicious user using Android Debug Bridge with application

Sensitive data, privileged functions

Android device

Attack goal Impact Control Change application behavior to gain access to sensitive data and privileged functions, as well as insert malware into applications.

Identity theft, fraud and application company integrity loss, unauthorized new features, revenue loss due to piracy

Obfuscate code using for example Proguard, use self-protection code to detect package altering. Use root detection code

Table 1.12: Threat traceability matrix for Using Android Debug Bridge shell functions to

go to internal application pages [17]

Threat agent Asset Attack surface Malicious user using Android Debug Bridge shell

Sensitive data, privileged functions

Android Debug Bridge shell session to Android device

Attack goal Impact Control Gain access to sensitive data and privileged functions through Android Debug Bridge shell interaction

Admin and premium features in the hands of an attacker, resulting in data leakage, denial of service and application company reputation damage among other things the admin page enables the attacker to do, potential for lawsuits

Implementation of root detection code, server-side token authorization

12

Table 1.13: Threat traceability matrix for Deserialization attack [18]

Threat agent Asset Attack surface Malicious application Sensitive data, device assets Android device

Attack goal Impact Control Remote code execution on the victim’s device

Company reputational damage, data theft, lawsuits, identity theft

Log deserialization exceptions, validate input, do not accept serialized input from untrusted sources, run deserialization code with limited access permissions.

5.2 Regarding the references used for the threat modeling [1] is an article provided by Synopsis which is a big and respected tech company and is used to help guide the threat modeling process of the project. [2] is a page provided by Guardsquare which is a global reference in mobile application protection and is used to find information about Proguard which among other benefits is a way to protect against reverse engineering attacks. [3] is a page provided by The Open Web Application Security Project and is well known in the cyber security circles. Its top 10 mobile risks list is used to come up with several of the possible attacks as well as mitigation procedures. It helped in coming up with reverse engineering attacks enabling things such as package modification and read of sensitive data regarding the application. It showed what impacts that could have and a bit about mitigation measures that can be taken. It also gave information regarding the man in the middle attacks, what consequences they can have, and what countermeasures that can be taken. It showed information regarding server request attacks, their impacts and mitigations. Lastly, it helped with finding information, impacts and mitigation for reading files in the file system of the phone to access sensitive data. [4], [5] are pages provided by The Open Web Application Security Project and it is well known in the cyber security circles. Their application threat modeling description is used to guide the threat modeling process of the project. [6] is a page provided by Common weakness enumeration, a community developed list of common hardware and software weakness types. This page is used to identify the implicit Intent read of sensitive data attack and helped in describing potential impacts of the attack. [7] is the official certificate transparency web page, which is a google project designed to secure flaws in the SSL communication. It is used to find information on the certificate transparency mitigation to man in the middle attacks. [8] is a page provided by the Internet Society, founded by people involved in the Internet Engineering Task Force. It is used to find information about the self-protection code used as a possible mitigation to the repackaging attacks.

13

[9] is a SlideShare page with slides from the Denim Group which is a well-respected and leading software security firm. They are used to help guide the threat modeling process as well as help find several possible attacks to the android apps. It does not dive deep into the different attacks, but it shows the possibility of, man in the middle attacks, reverse engineering attacks, finding sensitive application data in the local storage of the device, attacking the web server of the application by bypassing the mobile client and a mention of using intents to get data from other apps. [10] is a book by Adam Shostack, a leading expert on threat modeling. It is used to help guide the threat modeling process. Especially with regards to the STRIDE concept. [11] is a book by Japan Smartphone Security Forum, which is an establishment founded to create a secure environment on smartphones for both users and service providers. It is used to help find a lot of the potential attacks on the android apps. It enlightened me of the possibility of Bluetooth hacking in android, as well as reading sensitive intents data with a malicious application. It was one of the references that mentioned man in the middle attacks. It informed me of the possibility of using Android debug bridge to read, possibly sensitive data within the device’s file system. It also informed me about the possibility of malicious files being wrongfully processed. It told me about the possibilities regarding SQL-injection and database hacking and countermeasures to avoid such attacks. Lastly, it also helped when designing the diagram of the threats. [12] is an article by International Journal of Innovative Research in Advanced Engineering, a leading journal for publication of new ideas of engineers. It is used to find information regarding repacking attacks as well as general information regarding the android architecture and security. [13] is a book authored by Prashant Verma, Certified Information Systems Security Professional and Akshay Dixit, information security specialist, consultant, speaker, researcher, and entrepreneur. It was used to find and describe the intent injection attack. [14] is a report published by the Department of Electrical Engineering & Computer Science, Syracuse University. It is used to find possible injection attacks on the android apps such as cross-site scripting attacks and code injection from SD card files. It is also used to find mitigation methods for such attacks. [15] is an article published by International Journal of Computer Science and Network, an open access online peer reviewed computer science journal registered under NISCAIR India. It is used to describe and find cross-site scripting attack methods. [16] is an article provided by Appknox, started with the sole purpose of making the mobile application ecosystem more secure and safe. It is used to find attacks concerning client-side injections as well as possible impacts of such attacks. [17] is an article on LinkedIn by Tal Melamed, a cloud security evangelist. It mentioned the possibility of using the android debug bridge shell to bypass authorization screens of

14

the application and access any part of the application. The article also mentions possible mitigations to the attack. [18] is an article by the Open Web Application Security Project describing the insecure deserialization vulnerability with its potential impacts and was used to find the vulnerability for the threat matrix.

5.3 The threats applied to Spotify for Android Applying the generic application threat model to the Spotify Application, it is in fact clear that all of the attacks to some extent could be possible to execute on the application if the right mitigation controls are not in place. However, some of the attack’s potential impacts would not be as big as they might be in other Android applications. As described in chapter 3 of the report, a rating system ranging from high to low priority was given to the attacks to decide depth and order of performing the tests. Below the reasons for giving the attacks their different ratings are motivated. The Bluetooth hacking of the Spotify application gets a low priority because the attack is hard to perform since it requires Bluetooth specific hacking tools in combination with being in the Bluetooth range of the device that is to be hacked. This would probably result in a low potential impact. The attack can target the Bluetooth car remote control function of the application and would probably only result in Denial of Service or handing control of song choosing to an attacker while using Bluetooth. The reading of implicit intent with sensitive data attack gets a medium priority because the attack is easy to perform but requires the user to install a malicious application or somehow give the attacker control of their android device. Then the impacts of the attack could be somewhat big, with at least personal information being leaked. The intent injection attack also gets a medium priority for its easiness to perform but that it also requires the user to install malware or somehow give the attacker control over the android device. This is considered in combination with a possible impact of the attacker getting access to personal data that could be passwords for instance. Cross-site scripting attack gets a medium priority because it is not super easy to perform since it requires the user to install malware or click on malware links in combination with requiring the attacker to know a bit of JavaScript. The impacts of the attack could be pretty big with users getting their sessions hijacked and their personal data exposed. The man in the middle attack gets a high priority because of its easiness to perform with the user only needing to be on the same network as the attacker, for example a cafe with free WIFI. This combined with the impact of possible user credentials and session tokens being revealed as well as a possibility to impersonate both the user and the server makes for possibly huge consequences. The file processing code injection attack gets a low priority because it is very hard to perform such attacks, requiring the attacker to know how to implement shell code in

15

media files whilst avoiding malware detection. This combined with the fact that the user has to install malware files on the device and open them in the application, which in the Spotify application only involves profile picture uploading. Where the chance of the user having malware inside their own photos goes down even further. The impact if such an attack is successful however is pretty big where the attacker could for instance take control of the user's device. Reverse engineering attack to find sensitive data within the application code is given a high priority because it is very easy to perform at least some form of attack on the system if the proper mitigation measures have not been taken. The attack only requires an android phone with the Spotify application installed and a computer with the right reverse engineering tools installed. The potential impact of the attack is huge as well where the attacker could potentially find weaknesses in the backend servers or find secret API keys or developer passwords and features. Finding sensitive data within the device’s file system is given high priority to test with the Spotify application installed. This is because it is relatively easy to get access to the inner files only requiring a rooted Android device with Spotify installed and a computer that can take a look at the file system using for instance Android Studio. The potential impacts of the attack are big where for example secret API keys, and passwords could be leaked. Database hacking attack on the application is given a high priority because it is relatively easy to attack, requiring the attacker to know what database URLs are used and some basic commands to use them. The attack only requires a computer connected to the internet once the URLs of the databases are known. This combined with the fact that the potential impact of the attack is big where data can be tampered with and sensitive data such as passwords could be stolen makes the attack important to test. Backend server attacks are given a medium priority since they are a bit hard to attack, requiring knowledge of the backend system and how requests are made. The attack is also a bit out of the scope of the study of the Android application since it involves servers being used by desktop versions along with IOS versions as well. So, it could rather be a matter of finding out if the application is somehow compromising the security of the backend servers. This is already to some extent covered by the reverse engineering attacks in combination with the man in the middle attacks. Since they help in revealing how the requests work. The impact of infiltrating the backend servers of Spotify could however be huge, since it could affect the integrity of Spotify across all platforms and lead to data leakage and modification for all its users. Repacking attacks are given high priority for the Spotify application since it is relatively easy to do, requiring an android device with Spotify and reverse engineering tools as well as some basic knowledge of how Android applications work. The impact of the reverse engineering attacks could be big since they could result in revenue loss from piracy for example giving people free premium versions. It could also result in sensitive data leak from the application.

16

The accessing of inner application pages through ADB shell attack is given a medium priority since it is easy to do the attack only requiring a device with Spotify installed and a computer with ADB installed, but the impact of the attack is not huge since it most likely involves the attacker getting access to premium pages unpaid for. There could however be a small risk that the developers left testing pages within the source code that could lead to sensitive data leakage or give unauthorized features to the attacker. The deserialization attack gets a low priority, the impact of the attack could be severe with remote code execution on the victim’s device being possible but the attack is hard to execute, requiring the victim to install a malicious application on their device as well as requiring the attacker to know a lot of theory to make the attack successful.

5.4 Motivation for choice of attacks to test and their testing depth A choice was made to make a thorough test on one application instead of briefly checking a lot of applications since this could be more meaningful in the result it has. That is why almost all of the attacks were tried, where exceptions were made for the Bluetooth attack, the file processing attack and the deserialization attack which were neglected. The reason for this was that all of them got a low priority rating from the previous subchapter. This was because they were time and or resource demanding, where the budget for both already was limited. The high priority attacks were performed before the medium priority once as well as with a higher depth.

6 Penetration testing

6.1 Reverse engineering attack to find sensitive data in the application

code

BACKGROUND

All applications on Android are to some extent subject to reverse engineering. The

application files are stored in an APK on Android devices. This APK can be unzipped

with a number of different tools on a computer. There is a classes.dex file which

contains dalvik byte code, readable by the Android device, but not readable for humans.

The dex file can however be decompiled into something called smali code using a choice

of tools on a computer. Smali code is more readable for humans and is an assembler for

the dex format. The smali code is still quite hard to comprehend, so there are tools for

converting dex files into jar files, which in combination with using tools for decompiling

the jar files into plain text java. All this being done, the code still will not be perfect, and

you would not be able to execute it, the code is however pretty readable which works

great for our purposes. [27]

There are ways to protect the APK file from reverse engineering attacks and that is done

through obfuscation tools such as Proguard. Obfuscating the code makes it harder to

read, this is done by changing names of methods and classes and fields into random

17

letters. The obfuscation as such will not make it impossible to read and follow along how

the application works, but it makes it a lot more time consuming and difficult to find out

how it works. [26]

METHOD

The reverse engineering process started with downloading the Spotify application to the

Android device and then copying its APK file to a computer. A tool called Apktool was

then used to decode the resources of the APK file. In order to get the java source code

from the dex file, a tool called Jadx was used.

Once the code was reverse engineered it was time to start analyzing the code. To begin

with the AndroidManifest.xml file was analyzed. A special focus on trying to find keys

and other secrets were given. A look at what permissions were granted to the application

was also taken to see what type of potential access a hacker could get if a successful

penetration was to be made. This was followed by looking at the resources folder, giving

special attention to the strings.xml file where hardcoded strings of the application are

stored. A search for keys and other secrets were made here as well.

At this moment it was time to look at the actual source code of Spotify. The folders were

given different amounts of attention depending on if they actually had to do with Spotify

or if they were just imported libraries. They were also given higher attention if their

names and classes had more relevance in a security aspect. For example, a class such as

QuickLogin seems much more relevant to look at than a class like

LyricsFullscreenHeaderView. A special look out was made for classes such as testing

classes or admin classes and anything like that. As for looking at the classes themselves,

as had been done in the previous files a search for keys and other secrets were made.

Then the classes’ methods were analyzed to try to find out how they work and what

other classes’ methods they make use of. Weak spots in authorization and encryption

controls were also looked for. [28]

RESULTS

From the analyses of the source code and resources of the application there were not a

lot of weaknesses found. What was found however was an API key in the

AndroidManifest.xml file:

<meta-data android:name="com.crashlytics.ApiKey" android:value="ed79a89851fe4ae8eb60f37284a088b1055997d8"/>

And in the strings.xml file the following things were found:

<string name="default_web_client_id">494597445014-tfb24qacapieae13b1k4efe7p14b737q.apps.googleusercontent.com</string>

18

<string name="firebase_database_url">https://pushka-notifications.firebaseio.com</string> <string name="gcm_defaultSenderId">494597445014</string> <string name="google_api_key">AIzaSyDqQSJmMHjaXI_aFg7GWB-U2y1hk_qbFcc</string> <string name="google_crash_reporting_api_key">AIzaSyDqQSJmMHjaXI_aFg7GWB-U2y1hk_qbFcc</string>

As for the source code of the application it was clear that an obfuscation tool was in use.

The names of a lot of classes and methods were given random letters. This made the

code very hard to follow. It was possible to see that a REST interface was implemented

with requests being made to the Spotify APIs and responses sent via JSON objects. This

communication type was implemented for authorization as well as for media streaming

and searching. This means that a lot of the security aspects are outsourced to the Spotify

servers.

It could also be concluded that the source file of the application contained a huge

number of classes (over 30 000 files including the folders.) This is of course counting

imported libraries that the application uses. Out of the files looked at however (100+),

no real weaknesses were found.

DISCUSSION

The applications files did contain API keys, these keys however do not seem to be

harmful to include, since they are mainly concerned with crash analytics. The database

URL included could potentially be harmful depending on the security configuration it

uses but is not in of itself a security issue. This means that the system withstood the

reverse engineering attack to find sensitive data in the source files but because of the

huge number of files within the application only a select number of files were explored.

This means that the result does not imply that the application is completely safe from

such an attack. But it does mean that given a serious attempt with regards to searching

relevant files, nothing important was revealed. The complexity of reading the obfuscated

code could also be a weak link in the result given, because an attacker might have a

better understanding of the system at hand and could potentially find some weakness

not found in this testing.

6.2 Reverse engineering attack to make package alterations

BACKGROUND

There are many ideas behind making package alterations, these could for instance be to

get access to functions that are otherwise only available to premium users, or it could be

to install malware hidden inside the application and then trick users into downloading

the Spotify looking application with hidden malicious intentions.

19

As described in chapter 6.1’s background it is possible to reverse engineer Android

applications with a set of tools. With reverse engineered code available one can make

changes to existing files and add new ones as well. Using tools on a computer you can

compile the reverse engineered files back into an APK. This APK can then be signed with

other tools available making it possible to install the application on the Android device.

[29]

Since this is a big security issue there are ways to try to prevent this such as root

detection code that can check if the device is rooted. A self-protection method can be

used that randomly splits repackage detection code into several blocks which are then

directly inserted into the applications’ byte code. This method can thus detect

modifications to the code. [8], [30]

METHOD

The same steps taken in 6.1 can be made to get the reverse engineered files of the

application in this step. The strings.xml file was modified in order to see if the

application was able to detect such minor changes like changing a string name. The next

test was to test altering java code within source files, the last test was to add new maps

and new files. For every test once the code was altered the APK was rebuilt using

Apktool, and then signed with a key using jarsigner. Before being installed on the

Android device.

RESULTS

The result of the testing was that changes to string names were not detected but the

impacts were nothing but aesthetic as the name of things displayed in the UI was

altered. As for both trying to alter java source code and trying to add files and folders to

the application, an error was given when trying to build the APK:

Robins-MacBook-Air:Repackage robin$ apktool b com.spotify.music-1.apk-decompiled/ -o

com.spotify.music-1.apk

I: Using Apktool 2.4.1

I: Checking whether sources has changed...

I: Smaling smali folder into classes.dex...

W: Unknown file type, ignoring: com.spotify.music-1.apk-decompiled/smali/.DS_Store

W: Unknown file type, ignoring: com.spotify.music-1.apk-decompiled/smali/com/.DS_Store

W: Unknown file type, ignoring: com.spotify.music-1.apk-decompiled/smali/com/moat/.DS_Store

W: Unknown file type, ignoring: com.spotify.music-1.apk-

decompiled/smali/com/moat/analytics/.DS_Store

W: Unknown file type, ignoring: com.spotify.music-1.apk-decompiled/smali/com/spotify/.DS_Store

W: Unknown file type, ignoring: com.spotify.music-1.apk-

decompiled/smali/com/spotify/music/.DS_Store

20

W: Unknown file type, ignoring: com.spotify.music-1.apk-

decompiled/smali/com/spotify/signup/.DS_Store

W: Unknown file type, ignoring: com.spotify.music-1.apk-

decompiled/smali/com/spotify/signup/api/.DS_Store

W: Unknown file type, ignoring: com.spotify.music-1.apk-

decompiled/smali/com/spotify/signup/api/services/.DS_Store

W: Unknown file type, ignoring: com.spotify.music-1.apk-decompiled/smali/com/malware/.DS_Store

Exception in thread "main" org.jf.util.ExceptionWithContext: Exception occurred while writing

code_item for method Lcom/comscore/android/vce/b;->a([Ljava/lang/String;)V

at org.jf.dexlib2.writer.DexWriter.writeDebugAndCodeItems(DexWriter.java:917)

at org.jf.dexlib2.writer.DexWriter.writeTo(DexWriter.java:341)

at org.jf.dexlib2.writer.DexWriter.writeTo(DexWriter.java:297)

at brut.androlib.src.SmaliBuilder.build(SmaliBuilder.java:61)

at brut.androlib.src.SmaliBuilder.build(SmaliBuilder.java:36)

at brut.androlib.Androlib.buildSourcesSmali(Androlib.java:418)

at brut.androlib.Androlib.buildSources(Androlib.java:349)

at brut.androlib.Androlib.build(Androlib.java:301)

at brut.androlib.Androlib.build(Androlib.java:268)

at brut.apktool.Main.cmdBuild(Main.java:251)

at brut.apktool.Main.main(Main.java:79)

Caused by: org.jf.util.ExceptionWithContext: Error while writing instruction at code offset 0x6

at org.jf.dexlib2.writer.DexWriter.writeCodeItem(DexWriter.java:1190)

at org.jf.dexlib2.writer.DexWriter.writeDebugAndCodeItems(DexWriter.java:913)

... 10 more

Caused by: org.jf.util.ExceptionWithContext: Unsigned short value out of range: 65538

at org.jf.dexlib2.writer.DexDataWriter.writeUshort(DexDataWriter.java:116)

at org.jf.dexlib2.writer.InstructionWriter.write(InstructionWriter.java:356)

at org.jf.dexlib2.writer.DexWriter.writeCodeItem(DexWriter.java:1150)

... 11 more

The build error has to do with an exceeding of the maximum number of methods within

the application: 65536 [50]. Which can be seen by the error: org.jf.util.ExceptionWithContext: Unsigned short value out of range: 65538

This means that adding methods to the application is not possible without removing

already existing ones or enabling something called Multidexing through the Gradle

Build which requires access to the project files and not just the APK files.

DISCUSSION

The result indicates that package modification is possible, but to actually make the

changes useful to an attacker you have to alter the application methods. Since the

application already is at the maximum number of methods this requires you to change

existing methods and or replace them, which makes it much harder to carry out the

attack. The attack might still be possible despite this, but at least it should be deterring a

lot of attackers from trying. Further testing could be done where methods are modified

in ways that does not destroy the normal flow of the application while at the same time

introducing malicious activities into it.

21

6.3 Man in the middle attack

BACKGROUND

Man in the middle attacks are done by the attacker inserting itself in the middle of the

network where the user communicates with a server. This enables the attacker to look at

the conversation as well as tamper with the requests from the user and replies from the

server. [31]

There are different ways to prevent this type of attack. One example is using HTTPS

instead of HTTP where the data being sent is encrypted using for example TLS.

(Transport Layer Security) A typical usage scenario of TLS is having the server

configured with a certificate containing a public key and a corresponding private key.

Via a handshake procedure with the client, the server proves its validity using the

private key to sign its certificate with public key cryptography. The servers are usually

configured with well-known issuers’ certificates called Certificate Authorities (CAs). The

client then has a set of trusted CAs used to verify that the server has a certificate issued

by a CA known to the platform. There are in fact two types of certificates on an Android

device, user and system installed. It is possible to configure network security on the

application and determine if the application should trust user installed certificates or

not, as well as basing the trust on different domains. [32]

METHOD

Burp suite was used as a proxy server to intercept the traffic of the application client and

server. The settings of the Android device were changed so that it used the proxy server

at the IP address of the testing computer, and both were set to use port 8080. Testing

was made to try and intercept traffic from client/server communication. After the initial

test a certificate file was then downloaded from the Burp suite program and installed on

the Android device as a trusted certificate. With the certificate installed another traffic

interception was made when communication between client and server of the

application.

RESULTS

When trying to intercept traffic without installing the certificate of the proxy server, the

traffic data is not accessible, however with the certificate installed among trusted ones.

The data is accessible, and you can see what type of request is being made and what

response is given. However, there does not seem to be any sensitive data being exposed.

22

Figure 3 showing the results of the traffic interception

The POST request from figure 3 above is probably used for authenticating a user and

since the data being sent is sensitive, the request data is encrypted. From the result we

can conclude that the application uses HTTPS communication and probably has a

network configuration where it only trusts system installed CAs for sensitive requests to

certain domains. This means that the attacker would need to somehow use a proxy

server that has a certificate installed as a system trusted CA on the victim’s device.

DISCUSSION

The result shows that there are mitigations taken to prevent man in the middle attacks

on the Spotify Application for Android. The result does not guarantee that the

application always is safe from traffic interception, since the user could somehow

happen to be using a rooted device where it is possible to install your own system

trusted certificates and have the attacker ´s proxy certificate installed. Though it

probably means that Spotify is not held responsible for any impacts of the attack.

6.4 Looking at the inner files of the Android device

BACKGROUND

Applications store data locally on the Android device, included in this data is sensitive

information such as usernames and passwords. While the data is usually stored in a

23

data/data folder in the applications file system which cannot be accessed without root

access there are several ways of bypassing this protection scheme. It is therefore

important that the data is encrypted.

Another problem is usually the shared preferences files intended for storing things like

user preferences that can survive a restart of the application. These files can contain

key/value pairs, and sometimes developers assume this to be a safe place and insert

sensitive API keys among other sensitive information here. [33]

METHOD

Since the data of the application cannot be accessed on a normal Android device, an

attempt was made to root the device. The rooting attempts were unsuccessful for some

reason, so rather than trying for another time with another rooting method, another

method was tried. As it turned out, a method existed for accessing the data without

requiring root access. The method was to use the techniques in chapter 6.2 to repackage

the application, this time adding a debug flag in the AndroidManifest.xml file thus

enabling debug mode of the application before reinstalling the application on the device.

In the debug mode of an application, the data/data folders are accessible through an

ADB shell session of the device. This meant that it was now possible to access this folder

for the Spotify application.

After creating a test user account on the application with inputted and saved credentials,

the folders and files inside data/data were downloaded to the computer.

Some of the files were easily opened with text editors, like the shared preferences. The

folders also contained database files which were opened with the program DB Browser

for SQLite. The files were searched for API keys and other sensitive information that

might be included, along with a search for user credentials.

RESULTS

There was not anything sensitive stored in the shared preferences, except for the

username of the user and some client sender id for client cast analytics data: <map>

<string name="client_sender_id">e39e4b23-75cc-483d-b7d8-76ed8d4e32e8</string>

</map>

As well as a Crashlytics id:

<string

name="crashlytics_partner_id">00b1ee2564b8a81333d0f1f95c3c826056d9460aa8986856a2d7de</st

ring>

24

As for the database files, the account_info_db contained username in clear text and a

link to profile image of the user, possible to open without any credentials required.

There was however no password stored in the database. It was also possible to see some

user action history in cache files, such as recently played playlists:

"spotify:user:spotifytest1337@hotmail.com:playlist:2MpssZFujoLoEEyP0gSkA9","collectionLink":null,

"name":"Veronica Maggio – Fiender är tråkigt

DISCUSSION

If we are looking at the attack where the user of the application owns the device and

tries to get API keys and other sensitive information regarding the application, there is

not much to be found. The ids that are found are probably not useful for attacking

purposes anyway since they are concerned with analytics data. Looking at the possibility

of an attack against the device owner through the app data however there is at least

username, profile picture and some activity history to be gained. One can however argue

that these being exposed is the least bit of worry for a user that has let an attacker get

access to their device, either through physically obtaining it or accessing it in a shell

session.

This does not guarantee that there is not anything useful for an attacker in the app data

of the device, since things can be missed when going through several lines of code and

even though search functions were used to try to find keys, ids and passwords, there are

still chances of missing important things. It does however show that the developers have

given thought as to what they put in the app data files and it seems as though the

application can withstand this type of attack.

6.5 Database attack

BACKGROUND

There are several choices of cloud databases for Android applications to use as well as

the possibility of using your own cloud database. One of the most common databases for

Android applications is Google's Firebase. The Firebase platform includes 17 products

used by more than 1.5 million applications. Among these there is the Cloud Firestore

which is a NoSQL real-time document-oriented database. There is also Firebase Cloud

Messaging which is used for messages and notifications for Android applications. [34]

Since a lot of sensitive data is stored in the databases, a big focus on security has to be

made. The Firebase platforms come with its own security implementations and how

these are used can be configured in security rules for the developer that implements

Firebase to their application. There are options to determine who are allowed to read

and write and upon which conditions. A lot of application developers have made reading

25

and writing allowed for everyone to make the testing of the database faster and easier,

there are some that forgets to change this when the application is released. While the

Firebase services are safe to use, they can be configured incorrectly to be penetrable

anyway. [35]

METHOD

Using the method from 6.1 to reverse engineer the application, it was found that the

application uses Firebase for push-notifications and the URL to the database was in fact

found:

<string name="firebase_database_url">https://pushka-notifications.firebaseio.com</string>

By trying to access the database in a web browser using: https://pushka-notifications.firebaseio.com/.json The entire database is dumped using the: .json at the end of the URL if the read operation is set to true without conditions. This method has been seen in a previous database attack carried out by Muhammad Khizer Javed [51]. Another approach was also taken to test the database security similar to the attack made by Emmanuel Ortiguela [52], where a curl command is used to try to make requests to the database: curl -X GET "https://firestore.googleapis.com/v1/projects/pushka-

notifications/databases/(default)/

RESULTS The result of trying the https://pushka-notifications.firebaseio.com/.json URL in a browser was the following response: { "error" : "Permission denied" }

The result from trying the curl command was: Robins-MacBook-Air:~ robin$ curl -X GET "https://firestore.googleapis.com/v1/projects/pushka-

notifications/databases/(default)/"

{

"error": {

"code": 401,

"message": "Request is missing required authentication credential. Expected OAuth 2 access token,

login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-

in/web/devconsole-project.",

"status": "UNAUTHENTICATED"

}

}

This means that the database uses proper security configurations where a user needs to

be authenticated for access and this means that the security responsibility is in the

hands of Firebase. The application code did not reveal any other cloud databases being

26

used. The rest of the databases used are part of the Spotify API which is penetration

tested in chapter 6.10.

DISCUSSION

The results show that the Firebase database used by the application has been configured

correctly and it is not possible to retrieve or post data on it. This means that even though

the URL of the database is visible within the application code, there is not a way of

exploiting it, unless the attacker for some reason got their hands on a valid login cookie

or authentication credential some other way. As for Spotify backend databases used by

the application there are not tests done in this penetration test so without further testing

done in chapter 6.10, it cannot yet be confirmed to withstand attacks.

6.6 Intent injection attack

BACKGROUND

Android applications use Intents to start Activities, Services and Broadcast Receivers. In

the AndroidManifest.xml used Activities, Services and Broadcast Receivers are declared,

if the exported attribute is set to true, the component can be started by other possibly

malicious applications. For security reasons an intent filter can be set to limit the forms

of actions that can be taken, what type of data that can be sent and what category the

intent should be in. [36]

The activity manager can be used in an Android Debug Bridge shell to start application

components by specifying an Intent. An attacker can use this for an intent injection

attack where for example malicious code is injected into the application through the

application component being called. To prevent an intent injection attack, the exported

attribute can be set to false, thus only allowing internal components of the application to

start the given component. If, however you have to allow external applications abilities

to start your application components it is important to sanitize the input data to make

sure it is safe as well as limiting the actions that can be taken with the above-mentioned

intent-filter. [37]

METHOD

The first step in the attack was to use the method in chapter 6.1 to reverse engineer the

application. Then the AndroidManifest.xml was checked for Components that were

exported. All 23 exported components’ intent-filters were checked as to what type of

actions they allowed and using ADB shell on a computer connected with the Android

device via USB.

27

am start -n com.spotify.music/component_name -e data was used to try to start the

exported components with different data depending on what was specified in their

respective java source files.

The next step was using the method in chapter 6.2 to repackage the

AndroidManifest.xml where the exported attribute of interesting components were

changed to true. The application was then reinstalled and in a shell session with the

device am start -n com.spotify.music/component_name -e data was tried on these

components as well.

RESULTS

All exported components included an intent-filter with specified actions that could take

place when calling the component. The intent injections resulted in the app crashing or

in nothing happening at all except for the QuickLoginActivity which was exported to

begin with without the need for repackaging. With the command:

am start -n com.spotify.music/com.spotify.loginflow/QuickLoginActivity -e username spotifytest1337@hotmail.com -e password ********* The user was logged in to the application without needing to type anything on the

Android device.

DISCUSSION

The result shows that there are restrictions as to what can be sent with the intents, while

the result showed that it was not possible to start any of the components except for one,

it does not guarantee that an attacker would not be able to do it by including some

required input parameters missed in this attacking attempt.

As for the QuickLoginActivity it is not possible to send any malicious code through it

since the input is validated in the Activity code, it might however be possible to use the

type of command used to start the Activity to brute force password combinations with

wordlists. This being said it is already a problem for desktop versions of Spotify with

tools like Spotify Cracker v1 available [53].

6.7 Cross-site scripting attack

BACKGROUND

If you send a crafted intent to Android applications, you can execute malicious

JavaScript if JavaScript is enabled in the component you are calling. This type of attack

is often called Cross-application scripting. [38]

For applications in android to be vulnerable to this type of attack they need to have

exported components that use WebKit with JavaScriptEnabled(true). There are still

28

ways to protect applications that do have all the above-mentioned attributes. By using

intent-filters to limit what URLs that are accepted as well as having input validation in

the component classes these types of attacks can be prevented. It is not only possible to

send JavaScripts or a redirect to an http URL, you can also enable file-URL access to be

able to access files from the Android device via sending Intents. All of these possibilities

need to be prevented from attackers. [39]

Logcat is a command line tool that dumps a log of system messages including stack

traces with error messages of the android device. [40]

METHOD

The first step was to use the method in chapter 6.1 to reverse engineer the application.

Then the AndroidManifest.xml was looked at to see what components are exported.

Looking at the classes of these components the use of WebKit and

JavaScriptEnabled(true) was searched for. Once a class was found that had the above-

mentioned attributes the ADB shell was used on the device to try to inject code into the

component. First of an attempt to input JavaScript was made:

am start -n com.spotify.music/component_name -d “javascript:alert(1);” Secondly inputting a URL link: am start -n com.spotify.music/component_name -d “https://evilpage.com” Lastly inputting a file url: am start -n com.spotify.music/component_name -d “file:///sdcard/contacts/secretContact” After the injection attempts were done, the logcat of the Android device was looked at to see what errors the injection attempts gave. Also, a look at the class code was made to see if input was validated as well as a look at the AndroidManifest.xml if the component had an intent-filter with data specifications.

RESULTS

Out of all 23 exported components, only AuthorizationActivity included WebKit and had

JavaScript enabled. The following commands were tried:

am start -n com.spotify.music/com.spotify.mobile.android.sso.AuthorizationActivity -d “javascript:alert(1);” am start -n com.spotify.music/com.spotify.mobile.android.sso.AuthorizationActivity -d “https://evilpage.com” am start -n com.spotify.music/com.spotify.mobile.android.sso.AuthorizationActivity -d “file:///sdcard/contacts/secretContact” All commands resulted in the following error found in Logcat of the device: Caused by: java.lang.AssertionError: The in-app protocol has not been set

W/System.err( 8610): at com.spotify.mobile.android.sso.AuthorizationActivity.o(SourceFile:400)

This means that the attacks were unsuccessful. Looking at the AuthorizationActivity class it is clear that input validation is done: Intent intent = getIntent();

29

String c = hhz.c(intent); if ("1".equals(c)) { hhq = new hhu(); } else if ("sonos-v1".equals(c)) { hhq = new hhs(); } else if ("com.spotify.sso.action.START_GOOGLE_AUTH_FLOW_V1".equals(intent.getAction())) { hhq = new hhr(); } else if (intent.getDataString() != null && hhz.a(intent.getDataString())) { hhq = new hht(); }

In the AndroidManifest.xml there is data specification in the intent filter of the

component as well restricting what urls can be used: <data android:host="accounts.spotify.com"/> <data android:scheme="https"/> <data android:pathPrefix="/inapp-authorize"/>

Meaning that the application component only accepts URLs beginning with

https://accounts.spotify.com/inapp-authorize

DISCUSSION

The result shows that measures have been taken to prevent Cross-site scripting attacks

to the application and that only a single class has a potential vulnerability to it. That

class has validation methods for its input data. The application clearly withstood the

attack and unless some class used WebKit out of the 23 exported ones that was not

found, the application should be considered safe in regard to cross-site scripting attacks.

6.8 Reading of implicit Intent with sensitive data

BACKGROUND

A malicious application can register itself via intent-filter in the AndroidManifest.xml

file to receive implicit intents that were meant for other applications, this could result in

the malicious application receiving sensitive data such as authorization codes and is

called Intent hijacking [54].This is the reason why it is unwise to send sensitive data via

implicit intents. Instead explicit intents should be used for such confidential operations.

Looking at a Java code example [36], we have: Intent sendIntent = new Intent();

sendIntent.setAction(Intent.ACTION_SEND);

sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage);

sendIntent.setType("text/plain");

This is code for starting an implicit intent with a text message. Notice that no receiving

class is specified.

On the other hand, we the code from the same webpage: Intent downloadIntent = new Intent(this, DownloadService.class);

downloadIntent.setData(Uri.parse(fileUrl));

startService(downloadIntent);

30

This is an example of an explicit intent where a class has been specified for receiving the

intent.

METHOD

Using the method in chapter 6.1 the application was reverse engineered and the

AndroidManifest.xml was looked at. A search for components that might contain

sensitive data was made. Once these components were found, their source code was

analyzed to see if it contained any intent sending. If the code included intents being

sent, a check was made whether or not the intent sent was implicit or explicit. Any

implicit intent sent would then be checked to see if it contained any sensitive

information.

RESULTS

Out of the 30+ classes checked that sounded like they could potentially have sensitive

data, some of them sent out intents and none of them were implicit intents. This meant

that there was no use in trying to attack them with a malicious application since they

would not send any data to that application anyway.

DISCUSSION

Because of the big number of classes in the application and the time given to the attack

test, only a select number of classes were analyzed. This means that while the

application withstood the attack for these handpicked classes, it is not guaranteed that it

would do so for every class in the application. This test more so shows that it is likely

that the application is not vulnerable to the attack than that it is guaranteed.

6.9 Using ADB shell to explore internal application pages.

BACKGROUND

As described in chapter 2 of this report, Activities are single screen user interfaces and

they can be activated through intents. In the AndroidManifest.xml file you can set an

exported attribute as true in order to be able to call the component outside of the

application it belongs. By using the Activity Manager (AM) over an Android Debug

Bridge (ADB) shell session with the Android device, intents can be sent to try to start

activities from the application. Since this is a possibility you should not leave any testing

or admin pages on the application when released to the public. You should also

preferably have session/token management for accessing data from the servers of the

application. [17]

31

METHOD

The first step was to use the method in chapter 6.1 to reverse engineer the application.

After that a look was taken on the AndroidManifest.xml to see what Activities were used

by the Spotify application. Names like test or admin were searched for as well as other

relevant sounding names. Some of the Activities were already exported while other

activities could be exported through the repackaging method in 6.2 when a new

application was installed where these activities were exported as well. For all activities

tested the ADB shell was used on the device and the command: am start -n

com.spotify.music/Activity_Name to invoke the activity to start. The logcat was looked

at for seeing possible errors linked to the starting of the Activities.

RESULTS

There were no Activities found that were there for testing or admin purposes. There

were however some activities that had interesting names. Out of these activities some

were just normal activities that you are allowed to access anyway within the application

and trying to open some other of them actually caused the application to crash. No

unprivileged operations were performed from this attack.

DISCUSSION

The result indicates that the attack was unsuccessful in regard to performing

unprivileged operations or gaining access to testing or admin pages. The test did

however not go through every single activity, and guarantees cannot be made that the

neglected activities will not give the attacker something. They were neglected however

because of time and the fact that their names did not suggest that they would be

dangerous or unallowed to access. The test did have cases where the application

crashed, this could be used by an attacker to do a Denial of Service attack. The attacker

could create a malicious application which constantly made calls to the activity that

causes the application to crash, meaning that the application would be unusable. This

could be useful for competing companies since it would make the customer choose them

instead. This type of attack does require the user to install malware and stopping this is

something that should be handled by the operating system rather than the application

itself, but measures could have been taken to avoid the crash.

6.10 Backend server attacks

BACKGROUND

Using a proxy server on the application you can see what requests and replies are made

between client and server. This information combined with looking at the source files of

the application for secret API keys or other things that might compromise the backend

32

servers, could possibly enable an attacker to make privileged server requests among

other things. [41]

As can be seen in chapter 4 of this report the application makes calls to Spotify backend

servers using authentication tokens. Requiring authentication when making calls to the

Spotify API means that attackers are prevented from getting unauthorized access to the

servers.

METHOD

Using the method in chapter 6.3 the calls that the application makes to the backend

servers are revealed. Using the curl command in a terminal window, attempts were

made to make calls to the URLs used by the application. Using the methods in chapter

6.1 and 6.4 the application was searched to see if it revealed any compromising

information regarding access to the backend servers.

RESULTS

No information that could compromise the backend servers was found when using the

methods from chapter 6.1 and 6.4. When trying to make calls to the servers every

attempt failed due to being unauthorized to make the request. For example:

curl https://api.spotify.com/v1 gives {

"error": {

"status": 401,

"message": "No token provided"

}

}

DISCUSSION

Looking at developer pages of Spotify [55], you can see that other developers are allowed

to make calls to their APIs using authorization tokens from logging in a user to their

Spotify account. So, there is no secret regarding the calls that the application makes, and

they are in fact meant to be used by other applications. The API calls are also used by

desktop versions as well and therefore making further attempts to attack these servers

falls a bit out of scope of this project. The focus of the attack was rather on what could be

revealed through the application code, and nothing useful in attacking the backend

servers was found. This does not guarantee the code is free from backend compromising

information, since every line of code was not searched. The result does however show

that it is not easy to find any exploitable information looking through the application

files.

33

7 Ethics and sustainability Since a bug bounty type of project was chosen, and due to the fact that the Spotify team

even have their own bug bounty program it is actually allowed for people to try to

penetrate their application, provided that guidelines were followed. One of such

guidelines was to use your own accounts for the testing, as to not compromise other

people's privacy. Another guideline was to not use automated testing without consulting

with them first since they can be very loud for Spotify's detection system. [42]

The guidelines mentioned above was followed, and the principle of responsible

disclosure [56], was going to be followed in case of any exploits being found. In this

manner the project actually is ethically sound and with a goal that is ultimately to make

the application more secure and even have the research act as help for other

application’s security, the impact of the project should be considered good.

Looking at the environmental impacts of the project, the research was done with eBooks

and internet articles. In comparison with physical books, no paper or shipping of the

book was needed. The computer and android device that was used for the testing were

used devices hence, no new devices had to be produced for the project. This means that

the direct environmental impact of the project is very low. As for Spotify, the plastic

production has gone way down since the selling of CDs did so. Though, studies done by

a team from the University of Glasgow in the UK and the University of Oslo [57], show

that the environmental impact may have gone up anyways due to the energy resources

required for streaming the music being so high. Helping Spotify with their security,

could mean helping them expand which could actually be bad for the environment. The

choice of application to review the security of could hence have environmental impacts

indirectly and choosing eco-friendly companies could help bring down the

environmental impacts.

8 Results

The result of all the penetration testing was that no exploits worthy of reporting were

found. The testing showed that mitigation measures had been taken to avoid every

attack scenario mentioned in the threat model of this report. While hardcoded API keys,

listening history and a database URL was found within the code, it was no real value

getting them to an attacker. There were ways for malicious applications to make Denial

of Service attacks against the Spotify application by calling components that cause the

application to crash. Though stopping malicious applications like this is at least in part

the responsibility of the operating system. In intent injection attacks it was possible to

login to Spotify through an ADB shell in a terminal, while this could be a problem for

34

brute force attacks, that problem already exists for the desktop version of Spotify

anyway.

9 Discussion

As can be seen from the results of penetration testing the Spotify application for

Android, the application is very secure. The tests are however not definitive proof of the

application being able to withstand these attacks, since further testing could have been

made in every category. To give an example, the reverse engineering attack could have

been given more time to understand the system as well as try to find weaknesses in the

code.

Reviewing the security of Android applications is not a one-man job, and claims are not

made to convince the reader that the application is impenetrable. Rather the project

shows a procedure that can be taken when reviewing the safety of an application. This

procedure can just as well be taken to review other Android applications adjusting

attack focus and depth depending on the respective applications risks. The reason that

the rewards program exists in the first place is to motivate a lot of people to try to find

weaknesses in the application and together contribute to making it safe.

10 Conclusions

While penetration tests were made to try to find exploits in the application, the end goal

never revolved around actually finding exploits since the application has a big security

team behind it as well all bounty hunters from the reward program already finding these

types of exploits. If the goal was to actually find exploits in an Android application, a

better bet would have been to look at less popular applications with a lot of weaknesses

yet to be revealed. The impact however of finding those exploits is not near as big as

finding them in popular applications with a lot more users.

The testing results do show how serious the Spotify team is when it comes to security

and can act as a template for further research into the Spotify application as well as

other applications on the Google Play Store.

35

References

[1] Synopsys Editorial Team. “The 5 pillars of a successful threat model” URL: https://www.synopsys.com/blogs/software-security/5-pillars-successful-threat-model/ [2] Guard square. “Proguard” URL: https://www.guardsquare.com/en/products/proguard [3] OWASP. “OWASP Mobile top 10” URL: https://owasp.org/www-project-mobile-top-10/ [4] OWASP. “OWASP Application threat modeling” URL: https://owasp.org/www-community/Application_Threat_Modeling# [5] OWASP. “OWASP Simplifying threat modeling” URL: https://2011.appsecusa.org/p/simplifyingthreatmodeling.pdf [6] Common Weakness Enumeration. “Common weakness enumeration” URL: https://cwe.mitre.org/data/definitions/927.html [7] Certificate Transparency. “Certificate transparency” URL: https://www.certificate-transparency.org/ [8] Internet Society. “Self-protection code prevent app repackaging” URL: https://www.internetsociety.org/resources/doc/2017/protecting-android-apps-from-repackaging-by-self-protection-code/ [9] Denim group. “Developing secure mobile applications” URL: https://www.slideshare.net/denimgroup/developing-secure-mobile-applications-17732256 [10] Threat modeling, designing for security, Adam Shostack (2014) [11] Android Application Secure Design/Secure Coding Guidebook, Japan Smartphone Security Association (2019) [12] A Comprehensive Study on Security issues in Android Mobile Phone — Scope and Challenges, International Journal of Innovative Research in Advanced Engineering (2016) [13] Mobile Device Exploitation Cookbook, Prashant Verma, Akshay Dixit (2016) [14] X. Jin, X. Hu, K. Ying, W. Du, H. Yin, G. N. Peri. “Code Injection Attacks on HTML5-based Mobile Apps: Characterization, Detection and Mitigation” URL: http://www.cis.syr.edu/~wedu/Research/paper/code_injection_ccs2014.pdf [15] B. A. Bache. “Cross-site Scripting Attacks on Android WebView” URL: https://www.researchgate.net/publication/236455748_Cross-site_Scripting_Attacks_on_Android_WebView [16] P. Panda. “Understanding OWASP Top 10 Mobile: Client Side Injection” URL: https://www.appknox.com/blog/understanding-owasp-top-10-mobile-client-side-injection [17] T. Melamed. “Hacking Android Apps Through Exposed Components” URL: https://www.linkedin.com/pulse/hacking-android-apps-through-exposed-components-tal-melamed/ [18] OWASP. “A8:2017-Insecure Deserialization” URL: https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A8-Insecure_Deserialization [19] Android Developers. “App Manifest Overview” URL: https://developer.android.com/guide/topics/manifest/manifest-intro [20] D. Nautiyal. “Android System Architecture” URL: https://www.geeksforgeeks.org/android-system-architecture/

36

[21] S. Lahoti. “What role does Linux play in securing Android devices?” URL: https://hub.packtpub.com/what-role-does-linux-play-in-securing-android-devices/ [22] Android Developers. “Application Fundamentals” URL:

https://developer.android.com/guide/components/fundamentals

[23] Android Developers. “Android Security Features” URL:

https://source.android.com/security/features

[24] Android Developers. “Analyze your build with APK Analyzer” URL:

https://developer.android.com/studio/build/apk-analyzer

[25] M. Rouse. “Android OS” URL:

https://searchmobilecomputing.techtarget.com/definition/Android-OS

[26] DLT Labs. “Introduction to Code Obfuscation” URL: https://medium.com/better-programming/code-obfuscation-introduction-to-code-obfuscation-part-1-93a6797349b0 [27] Curls. “Reverse engineering and modifying an Android game (.apk) — CTF” URL: https://medium.com/swlh/reverse-engineering-and-modifying-an-android-game-apk-ctf-c617151b874c [28] J. Damian. “What to Look for When Reverse Engineering Android Apps” URL: https://www.nowsecure.com/blog/2020/02/26/what-to-look-for-when-reverse-engineering-android-apps/ [29] W. Du. “Android Repackaging Attack Lab” URL: http://www.cis.syr.edu/~wedu/seed/Labs_16.04/Mobile/Android_Repackaging/Android_Repackaging.pdf [30] Guardsquare. “Protecting Android applications and SDKs against reverse engineering and hacking” URL: https://www.guardsquare.com/en/products/dexguard [31] Imperva. “Man in the middle (MITM) attack” URL: https://www.imperva.com/learn/application-security/man-in-the-middle-attack-mitm/ [32] M. Dolan. “Android Security: SSL Pinning” URL: https://medium.com/@appmattus/android-security-ssl-pinning-1db8acb6621e [33] Srinivas. “Insecure Local Storage: Shared Preferences” URL: https://resources.infosecinstitute.com/android-hacking-security-part-9-insecure-local-storage-shared-preferences/ [34] D. Winder. “4,000 Android Apps Expose Millions Of Passwords, Phone Numbers And Messages” URL: https://www.forbes.com/sites/daveywinder/2020/05/12/revealed-4000-android-apps-expose-millions-of-passwords-phone-numbers-and-messages/#8e7cdc1438d2 [35] Firebase. “Firebase Security Rules” URL: https://firebase.google.com/docs/rules [36] Android Developers. “Intents and Intent Filters” URL: https://developer.android.com/guide/components/intents-filters [37] Srinivas. “Android Hacking and Security, Part 3: Exploiting Broadcast Receivers” URL: https://resources.infosecinstitute.com/android-hacking-security-part-3-exploiting-broadcast-receivers/ [38] AndroidVulnerabilities. “Browser Cross-App Scripting” URL: https://androidvulnerabilities.org/vulnerabilities/Browser_Cross-App_Scripting [39] E. Yalon. “Android WebView: Secure Coding Practices” URL:

37

https://www.checkmarx.com/2017/11/16/android-webview-secure-coding-practices/ [40] Android Developers. “Logcat command-line tool” URL: https://developer.android.com/studio/command-line/logcat [41] Hacking Android, Srinivasa Rao Kotipalli, Mohammed A. Imran (2016)

[42] HackerOne. “Spotify - Bug Bounty Program | HackerOne” URL:

https://hackerone.com/spotify

[43] M. Anicas. ”An Introduction to OAuth 2” URL:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

[44] J. Richer. “User Authentication with OAuth 2.0” URL: https://oauth.net/articles/authentication/ [45] W. Enck, M. Ongtang, P. McDaniel. “Understanding Android Security” URL: https://www.researchgate.net/publication/224378192_Understanding_Android_Security [46] J. Clement. “Annual number of app downloads from the Google Play Store worldwide from 2016 to 2019” URL: https://www.statista.com/statistics/734332/google-play-app-installs-per-year/ [47] C. Cimpanu. “Google adds all Android apps with +100m installs to its bug bounty program” URL: https://www.zdnet.com/article/google-adds-all-android-apps-with-100m-installs-to-its-bug-bounty-program/ [48] A. Spadafora. “Google boosts bug bounties for Play Store apps” URL: https://www.techradar.com/uk/news/google-ups-play-store-bug-bounties [49] D. Czagan. “Qualitative Risk Analysis with the DREAD Model” URL: https://resources.infosecinstitute.com/qualitative-risk-analysis-dread-model/ [50] Android Developers. “Enable multidex for apps with over 64K methods” URL: https://developer.android.com/studio/build/multidex [51] M. K. Javed. “Exploiting Insecure Firebase Database” URL:

https://blog.securitybreached.org/2020/02/04/exploiting-insecure-firebase-database-

bugbounty/

[52] HackerOne. “Firebase Firestore insecure database” URL:

https://hackerone.com/reports/731724

[53] T. Armerding. “Is your Spotify password up to scratch?” URL: https://nakedsecurity.sophos.com/2018/01/04/is-your-spotify-password-up-to-

scratch/

[54] The MITRE Corporation. “Android Intent Hijacking” URL:

https://attack.mitre.org/techniques/T1416/

[55] Android Developers. “Web API Tutorial” URL:

https://developer.spotify.com/documentation/web-api/quick-start/

[56] HackerOne. ”Responsible Disclosure Limits Risk” URL:

https://www.hackerone.com/responsible-disclosure-overview

[57] B. Pedersen. ”The environmental impact of streaming music with Spotify and co.”

URL: https://www.dpa-international.com/topic/environmental-impact-streaming-

music-spotify-co-urn%3Anewsml%3Adpa.com%3A20090101%3A190524-99-365820

TRITA-EECS-EX-2020:475

www.kth.se