Full Text 01

EXAMENSARBETE INOM DATATEKNIK,
GRUNDNIVÅ, 15 HP
STOCKHOLM, SVERIGE 2020
Penetration testing of
Android applications
ROBIN NILSSON
KTH
SKOLAN 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 1
1.1 Theme relevance....................................................................................................................... 1
1.2 Objective...................................................................................................................................... 1
1.3 Delimitations............................................................................................................................. 1
1.4 Project relevance...................................................................................................................... 1
1.5 Report outline.………….............................................................................................................. 1
2 Background/Theory 2
2.1 Android OS................................................................................................................................. 2
2.2 Android application................................................................................................................. 4
2.3 Android security implementations.................................................................................... 5
3 Methodology 6
4 System description of Spotify 7
5 Threat model 8
5.1 Threat model diagram and table...........................................................................………… 8
5.2 Regarding the references used for the threat modeling............................................. 12
5.3 The threats applied to Spotify for Android...................................................................... 14
5.4 Motivation for choice of attacks to test and their testing depth............................... 16
6 Penetration testing 16
6.1 Reverse engineering attack to find sensitive data in the application code……… 16
6.2 Reverse engineering attack to make package alterations......................................... 18
6.3 Man in the middle attack....................................................................................................... 21
6.4 Looking at the inner files of the Android device........................................................... 22
6.5 Database attack......................................................................................................................... 24
6.6 Intent injection attack............................................................................................................. 26
6.7 Cross-site scripting attack...................................................................................................... 27
6.8 Reading of implicit Intent with sensitive data................................................................. 29
6.9 Using ADB shell to explore internal application pages................................................ 30
6.10 Backend server attacks........................................................................................................... 31
7 Ethics and sustainability 33
8 Results 33
9 Discussion 34
10 Conclusions 34
References 35
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.
1
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]
2
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.
3
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.
4
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
5
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]
6
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
7
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
8
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 Sensitive information Bluetooth connection with
the user application
Attack goal Impact Control
Access confidential data, use Personal data leak, reputational Be wary of using Bluetooth
Bluetooth functions maliciously, damage, denial of service. functions that have access to
denial of service sensitive data.
Table 1.2: Threat traceability matrix for Reading of sensitive data from implicit
application Intent [6], [11]

Malicious application Sensitive information Android device
Access sensitive data Data leakage, personal integrity Don not send sensitive data with
loss, application company implicit Intents.
integrity reputation damage,
lawsuits
Table 1.3: Threat traceability matrix for Intent injection attack [13]
Malicious application Sensitive information, privileged Android device
application functions
Access sensitive data, access Data leakage, identity theft, Verify that actions and data are
unauthorized functions. reputational damage, validated via an Intent filter for
all Activities.
Table 1.4: Threat traceability matrix for Cross-site scripting attack [14], [15]
Malicious application Sensitive information, privileged Android device
application functions, whatever
asset is obtainable through
server transactions
Access sensitive data, session Identity theft, data leakage, Use safe APIs, sanitize input,
hijacking reputational damage, fraud, use safe ways of displaying data.
potential stealing of user assets
connected to the application
service.
9
Table 1.5: Threat traceability matrix for Man In the middle attack [3], [9], [11]
Malicious user on the same Sensitive information, whatever Client/server network
network asset is possible to send via
internet transactions.
Read and alter client/server Application integrity damage, Encrypt messages with HTTPS
communication to gain privacy loss, identity theft, communication, use pinning,
information and impersonate fraud, data leakage, denial of use certificate transparency
both parties to gain other service, potential transferring of
potential assets. money from client to attacker
etc. Lawsuits
Table 1.6: Threat traceability matrix for Malicious code injection through file processing
of application [11], [14]
Careless user installing Sensitive information, privileged Application processing user
malicious files on SD card. application functions files.
Gain access to user device Information theft, users giving Carefully handle user file
control of Android devices to processing. If using buffers,
attackers and whatever they check that the input length is as
choose to do with it, application expected.
company reputation loss.
Lawsuits
Table 1.7: Threat traceability matrix for Reverse engineering attack to find sensitive data
in the source code of the application [3], [9]
Malicious user using Android Sensitive data APK file of the application
Debug Bridge with application
Find sensitive data and weak Data leakage, intellectual Obfuscate code using for
points in the application. Find property theft, reputational example Proguard. Do not store
hidden functions and testing damage, identity theft, sensitive data in app source
code. compromised backend servers, code. Check that no test code is
bridge to further attacks. 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]
Malicious user using Android Sensitive data Android Debug Bridge to access
Debug Bridge on Android device the Android device’s file system
Find and read/alter sensitive Identity theft, privacy violation, Do not store unnecessary data in
data fraud, data loss, application local device storage, or at least
company reputation damage, use secure encryption.
material loss, External policy
violation
10
Table 1.9: Threat traceability matrix for Database hacking [11], [16]
Malicious user making server Sensitive data, data giving Server to database of application
requests access to company assets
Read, delete and modify Data leakage and data privacy Handle user input carefully,
application data. loss, bad reputation for the Configure the database to only
company, gaining company allow the authorized user access
assets through database to the appropriate data read and
alterations, lawsuits. alterations.
Table 1.10: Threat traceability matrix for Backend server attacks [3], [9]
Malicious user making server Sensitive data, privileged Server connected with
requests functions application
Access privileged functions and Unauthorized access to data and Use secure authorization and
sensitive data from application functions, data theft, authentication processes before
server reputational damage, lawsuits 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]
Malicious user using Android Sensitive data, privileged Android device
Debug Bridge with application functions
Change application behavior to Identity theft, fraud and Obfuscate code using for
gain access to sensitive data and application company integrity example Proguard, use self-
privileged functions, as well as loss, unauthorized new features, protection code to detect
insert malware into revenue loss due to piracy package altering. Use root
applications. detection code
Table 1.12: Threat traceability matrix for Using Android Debug Bridge shell functions to
go to internal application pages [17]
Malicious user using Android Sensitive data, privileged Android Debug Bridge shell
Debug Bridge shell functions session to Android device
Gain access to sensitive data and Admin and premium features in Implementation of root
privileged functions through the hands of an attacker, detection code, server-side
Android Debug Bridge shell resulting in data leakage, denial token authorization
interaction of service and application
company reputation damage
among other things the admin
page enables the attacker to do,
potential for lawsuits
11
Table 1.13: Threat traceability matrix for Deserialization attack [18]
Malicious application Sensitive data, device assets Android device
Remote code execution on the Company reputational damage, Log deserialization exceptions,
victim’s device data theft, lawsuits, identity validate input, do not accept
theft 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.
12
[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
13
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
14
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.
15
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
16
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>
17
<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.
18
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
decompiled/smali/com/spotify/music/.DS_Store
19
decompiled/smali/com/spotify/signup/.DS_Store
decompiled/smali/com/spotify/signup/api/.DS_Store
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.
20
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.
21
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
22
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>
23
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
24
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
25
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.
26
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
27
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);”
d “https://evilpage.com”
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();
28
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);
29
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]
30
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
31
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.
32
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
33
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.
34
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/
35
[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/Andr
oid_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:
36
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_Secur
ity
[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
37
TRITA-EECS-EX-2020:475
www.kth.se

Full Text 01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Text 01

Uploaded by

Copyright:

Available Formats

EXAMENSARBETE INOM DATATEKNIK,

Keywords - Ethical hacking; penetration testing; Android application security; reverse

Nyckelord - Etisk hacking; penetrationstest; Android-applikationssäkerhet;

1.4 Project relevance

1.4 Report outline

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

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

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

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

Android Runtime provides an application runtime environment to the OS by

2.2 Android application

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

2.3 Android security implementations

4 System description of Spotify

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

Threat agent Asset Attack surface

5.2 Regarding the references used for the threat modeling

[2] is a page provided by Guardsquare which is a global reference in mobile application

[6] is a page provided by Common weakness enumeration, a community developed list

[11] is a book by Japan Smartphone Security Forum, which is an establishment founded

[13] is a book authored by Prashant Verma, Certified Information Systems Security

[14] is a report published by the Department of Electrical Engineering & Computer

[15] is an article published by International Journal of Computer Science and Network,

[17] is an article on LinkedIn by Tal Melamed, a cloud security evangelist. It mentioned

5.3 The threats applied to Spotify for Android

6.1 Reverse engineering attack to find sensitive data in the application

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

6.2 Reverse engineering attack to make package alterations

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

6.4 Looking at the inner files of the Android device

As well as a Crashlytics id:

6.5 Database attack

By trying to access the database in a web browser using: https://pushka-

6.6 Intent injection attack

6.7 Cross-site scripting attack

Looking at the AuthorizationActivity class it is clear that input validation is done:

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

6.8 Reading of implicit Intent with sensitive data

Looking at a Java code example [36], we have:

6.9 Using ADB shell to explore internal application pages.

6.10 Backend server attacks

You might also like