penetration testing of android applications
TRANSCRIPT
INOM EXAMENSARBETE DATATEKNIK,GRUNDNIVÅ, 15 HP
, STOCKHOLM SVERIGE 2020
Penetration testing of Android applications
ROBIN NILSSON
KTHSKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP
Abstract The market of Android applications is huge, and in 2019, Google Play users worldwide downloaded 84.3 billion mobile applications. With such a big user base, any security issues could have big negative impacts. That is why penetration testing of Android applications is important and it is also why Google has a bug bounty program where people can submit vulnerability reports on their most downloaded applications. The aim of the project was to assess the security of Android applications from the Google Play Security Reward Program by performing penetration tests on the applications. A threat model of Android applications was made where potential threats were identified. A choice was made to focus on the Spotify Application for Android where threats were given ratings based on risks associated with them in the context of the Spotify Application. Penetration tests were made where testing depth was determined by the ratings associated with the attacks. The results of the tests showed that the Spotify Application is secure, and no test showed any real possibility of exploiting the application. The perhaps biggest potential exploit found is a Denial of Service attack that can be made through a malicious application interacting with the Spotify application. The result doesn’t guarantee that the application isn’t penetrable and further testing is needed to give the result more reliability. The methods used in the project can however act as a template for further research into both Spotify and other Android applications. Keywords - Ethical hacking; penetration testing; Android application security; reverse engineering; threat modeling
Sammanfattning Marknaden för Android applikationer är enorm och 2019 laddade Google Play användare ner 84.3 miljarder mobil-applikationer. Med en så stor användarbas kan potentiella säkerhetsproblem få stora negativa konsekvenser. Det är därför penetrationstest är viktiga och varför Google har ett bug bounty program där folk kan skicka in sårbarhetsrapporter för deras mest nedladdade applikationer. Målet med projektet är att bedöma säkerheten hos Android applikationer från Google Play Security Reward Program genom utförande av penetrationstester på applikationerna. En hotmodell över Android applikationer skapades, där potentiella hot identifierades. Ett val att fokusera på Spotify för Android gjordes, där hot gavs rankingar baserat på riskerna associerade med dem i kontexten av Spotify applikationen. Penetrationstest gjordes med testdjup avgjort av rankingarna associerade med attackerna. Resultatet av testen visade att Spotify applikationen var säker, och inga test visade på några riktiga utnyttjningsmöjligheter av applikationen. Den kanske största utnyttjningsmöjligheten som hittades var en Denial of Service-attack som kunde göras genom en illvillig applikation som interagerar med Spotify applikationen. Resultaten garanterar inte att applikationen inte är penetrerbar och fortsatt testande behövs för att ge resultatet mer trovärdighet. Metoderna som användes i projektet kan i alla fall agera som en mall för fortsatt undersökning av både Spotify såväl som andra Android applikationer. Nyckelord - Etisk hacking; penetrationstest; Android-applikationssäkerhet; baklängeskonstruktion; hotmodellering
Table of Contents
1 Introduction 11.1 Themerelevance.......................................................................................................................11.2 Objective......................................................................................................................................11.3 Delimitations.............................................................................................................................11.4 Projectrelevance......................................................................................................................1
1.5Reportoutline.…………..............................................................................................................1
2 Background/Theory 22.1 AndroidOS.................................................................................................................................22.2 Androidapplication.................................................................................................................42.3 Androidsecurityimplementations....................................................................................5
3 Methodology 6
4 SystemdescriptionofSpotify 7
5 Threatmodel 85.1 Threatmodeldiagramandtable...........................................................................…………85.2 Regardingthereferencesusedforthethreatmodeling.............................................125.3 ThethreatsappliedtoSpotifyforAndroid......................................................................145.4 Motivationforchoiceofattackstotestandtheirtestingdepth...............................16
6 Penetrationtesting 166.1 Reverseengineeringattacktofindsensitivedataintheapplicationcode………166.2 Reverseengineeringattacktomakepackagealterations.........................................186.3 Maninthemiddleattack.......................................................................................................216.4 LookingattheinnerfilesoftheAndroiddevice...........................................................226.5 Databaseattack.........................................................................................................................246.6 Intentinjectionattack.............................................................................................................266.7 Cross-sitescriptingattack......................................................................................................276.8 ReadingofimplicitIntentwithsensitivedata.................................................................296.9 UsingADBshelltoexploreinternalapplicationpages................................................306.10Backendserverattacks...........................................................................................................31
7 Ethicsandsustainability 33
8 Results 33
9 Discussion 34
10 Conclusions 34
References 35
1
1 Introduction
1.1 Theme relevance
The mobile application market is huge, and in 2019, Google Play users worldwide
downloaded 84.3 billion mobile applications [46]. There is no denying that
vulnerabilities in these applications could affect a lot of people negatively. That is why
there is a need for security tests on the applications and it is also why Google has a
rewards bug bounty program giving out big money to people submitting vulnerability
reports on their most downloaded applications.
1.2 Objective
The objective of the project is to assess the security of Android applications qualified to
the Google Play Reward Program because of their 100 million or more downloads [47].
The assessment of the application will be made through penetration tests. The purpose
is not necessarily to find vulnerabilities within the system; it could rather be a
demonstration of a secure application which was not penetrable within given delimiters.
1.3 Delimitations
The delimitations brought upon the project is that of time and resources. Due to time
restrictions only the one application was assessed. Namely the Spotify application,
because finding vulnerabilities in an application with a big userbase would have a bigger
impact than finding them in an application with only a few users. Some of the possible
attacks were given less depth because of time limitations. Due to resource limitations,
some of the possible attack surfaces were not tested.
1.4 Project relevance
The project could be relevant to millions of people using the application, if
vulnerabilities are found and mitigated. As well as for other applications on the Google
Play Store, since Google uses vulnerabilities in the submitted reports to scan for similar
vulnerabilities in their other applications [48]. If, however the project does not find any
vulnerabilities, it could still be relevant to security researchers as a testing method
template for other Android Applications, as many of the themes do reoccur within the
applications on the Google Play Store. It could also help Spotify security testers see what
penetration tests already have been proven unsuccessful and may not need further
testing.
1.4 Report outline
In chapter 1, the project is introduced.
2
In chapter 2, a background to Android is given with explanation of the operating system,
an android application and some security implementations.
In chapter 3, the methods used in the project are described along with motivations for
picking them.
In chapter 4, a system description is made of Spotify for Android.
In chapter 5, the result of the threat modeling is presented in diagram and tables. This is
followed by an explanation of the sources used to help guide the threat modeling
process.
In chapter 6, the penetration tests are described along with discussions about the
validity of their results.
In chapter 7, the ethics and sustainability revolving the project is discussed.
In chapter 8, the results of the penetration testing are summarized.
In chapter 9, the validity of the results of the penetration testing are discussed as well as
the relevance of the result of the project.
In chapter 10, the conclusions that are drawn from the project result is presented.
2 Background/Theory
2.1 Android OS
The Android operating system is based on a modified version of the Linux Kernel. The
operating system is based on open source software and uses ARM for its hardware
platform. Later versions of Android OS support x86 and x86-64 architectures. The
system is mainly designed for touchscreen mobile devices. Because of the system’s open
nature, consumers are able to create content for the system which enables a big number
of ideas to be generated for the platform, while at the same time making it possible for
malicious activities with their system. Things like hiding viruses with tracking abilities
and or data stealing could be very harmful to the system’s users. [25]
3
The OS is divided into five main layers. The Linux Kernel, Libraries, Android runtime,
application framework and the applications layer.
Figure 1 showing the architecture of Android, retrieved from: https://www.elprocus.com/what-is-
android-introduction-features-applications/
The Linux Kernel is the bottom layer and works as an abstraction layer between the
software and hardware of the device it runs on. The Kernel is responsible for managing
input and output requests from the software. The Kernel contains drivers to handle
input hardware. The Kernel also handles system functionalities such as management of
processes and memory as well as security and networking.
Libraries is made up of various C/C++ core libraries provided with several open source
tools. To give some examples we have WebKit which is an open source web browser
engine that provides web browsing functionalities, OpenGL which provides a cross-
platform API to produce 2D and 3D computer graphics. We also have SSL which stands
for Secure Socket Layer and provides secure internet communication.
Android Runtime provides an application runtime environment to the OS by
translating bytecode into native instructions that are executed by the runtime
environment of the device. Dalvik virtual machine was based on Java virtual machine to
be better suited for the Android OS but was replaced by the Android Runtime in later
versions of the OS.
4
Applications framework provides application developers with high-level services
such as Window Manager, Content Providers, Activity Manager and View System.
Giving the developer prebuilt functionalities to their applications. Where the for
example View System builds the user interface handling views and layouts.
Applications is the top layer of the android architecture and is where applications are
written and installed. Applications can be everything ranging from pre-installed
applications to third-party installations. [20]
2.2 Android application
Android applications can be written in Java, Kotlin or C++ languages and the Android
SDK tools can be used to compile code and resources into an Android package or APK
for short. The APK is an archive file containing all the contents of the application and is
the file used to install applications on the Android devices. The APK includes a
classes.dex folder with source code classes compiled in dex file format which is
understandable by Android Runtime. It also has a resources folder with strings and
images and xml-layout. The APK also includes an AndroidManifest.xml file that
contains information about the application such as the applications package name, the
components, the permissions the application requires, and the software and hardware
features the application needs. For security reasons the AndroidManifest.xml file
contains information of how the applications components can be started through
something called intent filters. There are four types of Components within Android
applications: Activities, Services, Broadcast Receivers and Content Providers. [24]
Activities represent a single screen with a user interface and is the entry point to user
interaction.
Services are general-purpose entry points for keeping applications running in the
background. It might for example be playing music in the background or fetching data
over the internet without interrupting the current user activity.
Broadcast Receivers enables the system to deliver events to applications outside of
the regular user flow. They can even deliver broadcasts to applications that are not
running. A lot of broadcasts come from the system itself such as events of screen turning
off or low battery. But it could also come from applications for example telling another
application that a photo has been downloaded and can be used by that application.
Content Providers manage a shared set of data that can be stored within the device’s
file system as well as on the web using for instance SQLite database. Upon permission
other applications can query and modify data through the content provider.
5
In order to activate activities, services and broadcast receivers Intents are used. The
intent can either be implicit or explicit. An implicit intent activates a particular type of
component while an explicit intent activates a specific component. Content providers
however are activated through a targeted request from a ContentResolver. [45], [22]
2.3 Android security implementations
There are two levels of enforcement mechanisms for protection of Android, one at the
System level and one at the Inter Component Communication (ICC) level. At the system
level we have something called Application Sandboxing where each Application is
assigned a unique user ID (UID) and is run as a separate process. So, if for instance an
application tries to read data from another application, this is prevented by the fact that
the application does not have the right user privileges to read the data. A permission
model is used on the applications, where the user decides which functions of the device
to grant to the application. This can for instance be sensitive functions like camera,
internet or position access. This is to enable the user to prevent malicious applications
from getting access to the device’s resources. [23]
At the ICC level, the AndroidManifest.xml file contains information regarding the
allowed communication that can take place between application components. For
example, if an exported attribute of a component is set to false, the component is private
and only accessible within the application it originates. [23]
Android applications are required to be signed digitally; a private key is used to sign the
applications. This key can then be used by the application developer to for example
update their application on the Google Play Store or share data between applications.
The signing mechanism is great to prevent reverse-engineered malicious versions of
applications from replacing the original version on the Play Store.
Newer versions of Android also feature file-based encryption that enables different files
to be encrypted with different keys allowing the files to be unlocked independently.
Trusted Environment Execution is also a security feature of Android in which an
isolated area of the main processor is used to perform protected operations such as
storing secret data. Verified Boot is also a security feature of Android OS where a chain
of trust starts from the hardware-protected root to the boot loader, to the boot partition
as well as other verified partitions. This is used to ensure that executed code comes from
trusted sources. [21]
OAuth 2.0 is a delegation protocol that provides authorization flows used by a lot of
Android applications and enables the applications to obtain limited access to HTTP
services by delegating the user authentication process to the service hosting the user
6
account. It also allows for third-party application access to the user account if the user
grants the application the privileges for it. An example flow of the protocol is that an
application requests authorization to access the server from a user, the user accepts the
request and the application requests an access token from the authorization server,
authenticating with the application identity and authorizing by the grant from the user.
Upon successful authentication and authorization, the server issues an access token to
the application that can now be used to make API calls to the server for a limited period
of time. [43], [44]
3 Methodology The start of the project consisted of a theory phase where a lot of information about
Android and its applications was gathered. As well as information about the thesis
project itself such as what methods to use throughout the project. This was a useful
backbone when starting the next step of the project which was threat modeling.
“Threat modeling is the use of abstractions to aid in thinking about risks.” according to
Shostack [10]. It is meant to be a helpful tool in aiding with risk identification and thus
it is not about strictly following a guide but rather to use the methods that suits your
own system and actually has some use. That is why in this project a choice was made to
combine different methods based on how they helped in identification of threats to the
Android applications. Following the five steps in Synopsis’ 5 pillars of a successful threat
model, a diagram of the Android system and its different data flows and trust
boundaries were drawn [1].
A concept called STRIDE was used, where STRIDE stands for Spoofing, Tampering,
Repudiation, Information disclosure, Denial of Service and Elevation of Privilege.
Spoofing is to make the system believe that you are someone or something that you are
not. Tampering is to modify data which is not supposed to be modified. Repudiation is
to deny or contest that you have done something, for example received an email or
virtually signed a contract. Denial of Service is when an attacker prevents a server from
providing its service by crashing it, filling its memory or making it slower. Elevation of
privilege is when a program or user gets permissions of higher privileges than originally
intended. A Separation of threats into these categories helped in coming up with
potential threats to the system. [10]
Another method to come up with threats to the system was to make use of already made
research in the field. OWASP, a non-profit foundation working to improve software
security, has a top 10 threat list for mobile applications which was really useful in
coming up with threats as well as other sources mentioned in chapter 5.2 of this report.
By combining different literature and internet articles a more thorough threat model
was created. [3]
7
Continuing with steps from the Synopsis’ article, a threat traceability matrix was created
for each possible attack found. A traceability matrix is used to examine the different
threat agents in a structured manner with the columns: threat agent, asset, attack,
attack surface, attack goal, impact and control in accordance with the Synopsis article.
Threat agent is the person or group that constitutes the threat to the system. Asset is
something that is valuable to the company that owns the application or to an attacker.
Attack is the type of attack that can be performed by the threat agent when trying to get
access to the asset. Attack surfaces are found where there are trust boundaries in the
system and show where an attacker interacts with the system to launch attacks. Attack
goal is what the attacker wants to achieve from the attack. Impact is what negative
consequences a successful attack could have and who are affected. Control is what
mitigation measures that can be taken to avoid, make it harder or at least a reduce
negative impacts of the attack. [1], [10]
The next step was the preface of the penetration testing. Before choosing which test to
start with and how much time to spend on the different tests, the threat traceability
matrix was used to determine this. It showed potential impacts of the different attacks
in combination with showing how to control the attack. If an attack showed to be both
easy to perform and had a big potential impact, the attack was given high priority for the
penetration testing meaning it could be given more time as well as be carried out earlier.
This type of ranking of the threats is sort of similar to the DREAD system where ratings
are given based on damage, reproducibility, exploitability, affected users and
discoverability [49]. Though because of time restrictions as well as the fact that most of
the possible attacks were going to be penetration tested anyway, a choice was made to
give a bit less consideration to the rankings and rather just decide which attacks were
high, medium and low priority to test.
The next step was the actual penetration testing. The methods for testing the different
attacks were highly dependent on what they were, but what they all had in common was
that they all started with a theory phase where the attacking method was studied via
literature before actually trying the attacks. Another thing the tests had in common was
a result phase where the result of the attack was written down along with a discussion
on the relevance and validity of the findings.
4 System description of Spotify The system under consideration is the Spotify application for Android. For those who
are unfamiliar with Spotify, it is an application that offers music streaming to logged in
users. The Android application authenticates requests with OAuth 2.0, which is
described in chapter 2.3 of this report [44]. By having a valid OAuth access token in the
request header, the application is able to send requests to the Spotify Web API. The
8
requests are sent based on REST principles. This means that the request contains URI
for resource identification and HTTP verbs like GET and POST for action determination.
The response data is always returned as JSON objects in Spotify’s case. Through the
response data the application is able to display track Metadata as well as play songs
from the Spotify web servers.
As for the application itself, it uses Dagger for dependency injection. It uses GSON and
Jackson for serialization and deserialization of Objects. The application also uses
comScore, Moat and Crashlytics for analytics of the application. The application uses
Firebase for handling push notifications and it uses Proguard for App obfuscation. The
application features Bluetooth functions where you can remotely control song playback
by linking your application to for example a speaker device, or a car. There are
numerous other libraries and frameworks used by the application, but these can at least
help exemplify the type of dependencies the application has.
5 Threat model
5.1 Threat model diagram and table
Below are the diagram and tables created by following the method described in chapter
3 of this report.
Figure 2 showing a generic Android applications attack diagram. Arrows indicate data flow; green stripes
indicate trust boundaries
9
Figure 2 was used to come up with the possible attacks described in the threat
traceability matrices shown below.
Table 1.1: Threat traceability matrix for Bluetooth hacking [11]
Threat agent Asset Attack surface Attacker in close proximity to the user
Sensitive information Bluetooth connection with application
Attack goal Impact Control Access confidential data, use Bluetooth functions maliciously, denial of service
Personal data leak, reputational damage, denial of service.
Be wary of using Bluetooth functions that have access to sensitive data.
Table 1.2: Threat traceability matrix for Reading of sensitive data from implicit
application Intent [6], [11]
Threat agent Asset Attack surface Malicious application Sensitive information Android device Attack goal Impact Control Access sensitive data Data leakage, personal integrity
loss, application company integrity reputation damage, lawsuits
Don not send sensitive data with implicit Intents.
Table 1.3: Threat traceability matrix for Intent injection attack [13]
Threat agent Asset Attack surface Malicious application Sensitive information, privileged
application functions Android device
Attack goal Impact Control Access sensitive data, access unauthorized functions.
Data leakage, identity theft, reputational damage,
Verify that actions and data are validated via an Intent filter for all Activities.
Table 1.4: Threat traceability matrix for Cross-site scripting attack [14], [15]
Threat agent Asset Attack surface Malicious application Sensitive information, privileged
application functions, whatever asset is obtainable through server transactions
Android device
Attack goal Impact Control Access sensitive data, session hijacking
Identity theft, data leakage, reputational damage, fraud, potential stealing of user assets connected to the application service.
Use safe APIs, sanitize input, use safe ways of displaying data.
10
Table 1.5: Threat traceability matrix for Man In the middle attack [3], [9], [11]
Threat agent Asset Attack surface Malicious user on the same network
Sensitive information, whatever asset is possible to send via internet transactions.
Client/server network
Attack goal Impact Control Read and alter client/server communication to gain information and impersonate both parties to gain other potential assets.
Application integrity damage, privacy loss, identity theft, fraud, data leakage, denial of service, potential transferring of money from client to attacker etc. Lawsuits
Encrypt messages with HTTPS communication, use pinning, use certificate transparency
Table 1.6: Threat traceability matrix for Malicious code injection through file processing
of application [11], [14]
Threat agent Asset Attack surface Careless user installing malicious files on SD card.
Sensitive information, privileged application functions
Application processing user files.
Attack goal Impact Control Gain access to user device Information theft, users giving
control of Android devices to attackers and whatever they choose to do with it, application company reputation loss. Lawsuits
Carefully handle user file processing. If using buffers, check that the input length is as expected.
Table 1.7: Threat traceability matrix for Reverse engineering attack to find sensitive data
in the source code of the application [3], [9]
Threat agent Asset Attack surface Malicious user using Android Debug Bridge with application
Sensitive data APK file of the application
Attack goal Impact Control Find sensitive data and weak points in the application. Find hidden functions and testing code.
Data leakage, intellectual property theft, reputational damage, identity theft, compromised backend servers, bridge to further attacks.
Obfuscate code using for example Proguard. Do not store sensitive data in app source code. Check that no test code is left in the final production build of the application.
Table 1.8: Threat traceability matrix for Finding sensitive information within the
device’s file system [3], [9], [11]
Threat agent Asset Attack surface Malicious user using Android Debug Bridge on Android device
Sensitive data Android Debug Bridge to access the Android device’s file system
Attack goal Impact Control Find and read/alter sensitive data
Identity theft, privacy violation, fraud, data loss, application company reputation damage, material loss, External policy violation
Do not store unnecessary data in local device storage, or at least use secure encryption.
11
Table 1.9: Threat traceability matrix for Database hacking [11], [16]
Threat agent Asset Attack surface Malicious user making server requests
Sensitive data, data giving access to company assets
Server to database of application
Attack goal Impact Control Read, delete and modify application data.
Data leakage and data privacy loss, bad reputation for the company, gaining company assets through database alterations, lawsuits.
Handle user input carefully, Configure the database to only allow the authorized user access to the appropriate data read and alterations.
Table 1.10: Threat traceability matrix for Backend server attacks [3], [9]
Threat agent Asset Attack surface Malicious user making server requests
Sensitive data, privileged functions
Server connected with application
Attack goal Impact Control Access privileged functions and sensitive data from application server
Unauthorized access to data and functions, data theft, reputational damage, lawsuits
Use secure authorization and authentication processes before allowing privileged server request to application server
Table 1.11: Threat traceability matrix for Reverse engineering to repackage applications
with malicious alterations [3], [9], [12], [8]
Threat agent Asset Attack surface Malicious user using Android Debug Bridge with application
Sensitive data, privileged functions
Android device
Attack goal Impact Control Change application behavior to gain access to sensitive data and privileged functions, as well as insert malware into applications.
Identity theft, fraud and application company integrity loss, unauthorized new features, revenue loss due to piracy
Obfuscate code using for example Proguard, use self-protection code to detect package altering. Use root detection code
Table 1.12: Threat traceability matrix for Using Android Debug Bridge shell functions to
go to internal application pages [17]
Threat agent Asset Attack surface Malicious user using Android Debug Bridge shell
Sensitive data, privileged functions
Android Debug Bridge shell session to Android device
Attack goal Impact Control Gain access to sensitive data and privileged functions through Android Debug Bridge shell interaction
Admin and premium features in the hands of an attacker, resulting in data leakage, denial of service and application company reputation damage among other things the admin page enables the attacker to do, potential for lawsuits
Implementation of root detection code, server-side token authorization
12
Table 1.13: Threat traceability matrix for Deserialization attack [18]
Threat agent Asset Attack surface Malicious application Sensitive data, device assets Android device
Attack goal Impact Control Remote code execution on the victim’s device
Company reputational damage, data theft, lawsuits, identity theft
Log deserialization exceptions, validate input, do not accept serialized input from untrusted sources, run deserialization code with limited access permissions.
5.2 Regarding the references used for the threat modeling [1] is an article provided by Synopsis which is a big and respected tech company and is used to help guide the threat modeling process of the project. [2] is a page provided by Guardsquare which is a global reference in mobile application protection and is used to find information about Proguard which among other benefits is a way to protect against reverse engineering attacks. [3] is a page provided by The Open Web Application Security Project and is well known in the cyber security circles. Its top 10 mobile risks list is used to come up with several of the possible attacks as well as mitigation procedures. It helped in coming up with reverse engineering attacks enabling things such as package modification and read of sensitive data regarding the application. It showed what impacts that could have and a bit about mitigation measures that can be taken. It also gave information regarding the man in the middle attacks, what consequences they can have, and what countermeasures that can be taken. It showed information regarding server request attacks, their impacts and mitigations. Lastly, it helped with finding information, impacts and mitigation for reading files in the file system of the phone to access sensitive data. [4], [5] are pages provided by The Open Web Application Security Project and it is well known in the cyber security circles. Their application threat modeling description is used to guide the threat modeling process of the project. [6] is a page provided by Common weakness enumeration, a community developed list of common hardware and software weakness types. This page is used to identify the implicit Intent read of sensitive data attack and helped in describing potential impacts of the attack. [7] is the official certificate transparency web page, which is a google project designed to secure flaws in the SSL communication. It is used to find information on the certificate transparency mitigation to man in the middle attacks. [8] is a page provided by the Internet Society, founded by people involved in the Internet Engineering Task Force. It is used to find information about the self-protection code used as a possible mitigation to the repackaging attacks.
13
[9] is a SlideShare page with slides from the Denim Group which is a well-respected and leading software security firm. They are used to help guide the threat modeling process as well as help find several possible attacks to the android apps. It does not dive deep into the different attacks, but it shows the possibility of, man in the middle attacks, reverse engineering attacks, finding sensitive application data in the local storage of the device, attacking the web server of the application by bypassing the mobile client and a mention of using intents to get data from other apps. [10] is a book by Adam Shostack, a leading expert on threat modeling. It is used to help guide the threat modeling process. Especially with regards to the STRIDE concept. [11] is a book by Japan Smartphone Security Forum, which is an establishment founded to create a secure environment on smartphones for both users and service providers. It is used to help find a lot of the potential attacks on the android apps. It enlightened me of the possibility of Bluetooth hacking in android, as well as reading sensitive intents data with a malicious application. It was one of the references that mentioned man in the middle attacks. It informed me of the possibility of using Android debug bridge to read, possibly sensitive data within the device’s file system. It also informed me about the possibility of malicious files being wrongfully processed. It told me about the possibilities regarding SQL-injection and database hacking and countermeasures to avoid such attacks. Lastly, it also helped when designing the diagram of the threats. [12] is an article by International Journal of Innovative Research in Advanced Engineering, a leading journal for publication of new ideas of engineers. It is used to find information regarding repacking attacks as well as general information regarding the android architecture and security. [13] is a book authored by Prashant Verma, Certified Information Systems Security Professional and Akshay Dixit, information security specialist, consultant, speaker, researcher, and entrepreneur. It was used to find and describe the intent injection attack. [14] is a report published by the Department of Electrical Engineering & Computer Science, Syracuse University. It is used to find possible injection attacks on the android apps such as cross-site scripting attacks and code injection from SD card files. It is also used to find mitigation methods for such attacks. [15] is an article published by International Journal of Computer Science and Network, an open access online peer reviewed computer science journal registered under NISCAIR India. It is used to describe and find cross-site scripting attack methods. [16] is an article provided by Appknox, started with the sole purpose of making the mobile application ecosystem more secure and safe. It is used to find attacks concerning client-side injections as well as possible impacts of such attacks. [17] is an article on LinkedIn by Tal Melamed, a cloud security evangelist. It mentioned the possibility of using the android debug bridge shell to bypass authorization screens of
14
the application and access any part of the application. The article also mentions possible mitigations to the attack. [18] is an article by the Open Web Application Security Project describing the insecure deserialization vulnerability with its potential impacts and was used to find the vulnerability for the threat matrix.
5.3 The threats applied to Spotify for Android Applying the generic application threat model to the Spotify Application, it is in fact clear that all of the attacks to some extent could be possible to execute on the application if the right mitigation controls are not in place. However, some of the attack’s potential impacts would not be as big as they might be in other Android applications. As described in chapter 3 of the report, a rating system ranging from high to low priority was given to the attacks to decide depth and order of performing the tests. Below the reasons for giving the attacks their different ratings are motivated. The Bluetooth hacking of the Spotify application gets a low priority because the attack is hard to perform since it requires Bluetooth specific hacking tools in combination with being in the Bluetooth range of the device that is to be hacked. This would probably result in a low potential impact. The attack can target the Bluetooth car remote control function of the application and would probably only result in Denial of Service or handing control of song choosing to an attacker while using Bluetooth. The reading of implicit intent with sensitive data attack gets a medium priority because the attack is easy to perform but requires the user to install a malicious application or somehow give the attacker control of their android device. Then the impacts of the attack could be somewhat big, with at least personal information being leaked. The intent injection attack also gets a medium priority for its easiness to perform but that it also requires the user to install malware or somehow give the attacker control over the android device. This is considered in combination with a possible impact of the attacker getting access to personal data that could be passwords for instance. Cross-site scripting attack gets a medium priority because it is not super easy to perform since it requires the user to install malware or click on malware links in combination with requiring the attacker to know a bit of JavaScript. The impacts of the attack could be pretty big with users getting their sessions hijacked and their personal data exposed. The man in the middle attack gets a high priority because of its easiness to perform with the user only needing to be on the same network as the attacker, for example a cafe with free WIFI. This combined with the impact of possible user credentials and session tokens being revealed as well as a possibility to impersonate both the user and the server makes for possibly huge consequences. The file processing code injection attack gets a low priority because it is very hard to perform such attacks, requiring the attacker to know how to implement shell code in
15
media files whilst avoiding malware detection. This combined with the fact that the user has to install malware files on the device and open them in the application, which in the Spotify application only involves profile picture uploading. Where the chance of the user having malware inside their own photos goes down even further. The impact if such an attack is successful however is pretty big where the attacker could for instance take control of the user's device. Reverse engineering attack to find sensitive data within the application code is given a high priority because it is very easy to perform at least some form of attack on the system if the proper mitigation measures have not been taken. The attack only requires an android phone with the Spotify application installed and a computer with the right reverse engineering tools installed. The potential impact of the attack is huge as well where the attacker could potentially find weaknesses in the backend servers or find secret API keys or developer passwords and features. Finding sensitive data within the device’s file system is given high priority to test with the Spotify application installed. This is because it is relatively easy to get access to the inner files only requiring a rooted Android device with Spotify installed and a computer that can take a look at the file system using for instance Android Studio. The potential impacts of the attack are big where for example secret API keys, and passwords could be leaked. Database hacking attack on the application is given a high priority because it is relatively easy to attack, requiring the attacker to know what database URLs are used and some basic commands to use them. The attack only requires a computer connected to the internet once the URLs of the databases are known. This combined with the fact that the potential impact of the attack is big where data can be tampered with and sensitive data such as passwords could be stolen makes the attack important to test. Backend server attacks are given a medium priority since they are a bit hard to attack, requiring knowledge of the backend system and how requests are made. The attack is also a bit out of the scope of the study of the Android application since it involves servers being used by desktop versions along with IOS versions as well. So, it could rather be a matter of finding out if the application is somehow compromising the security of the backend servers. This is already to some extent covered by the reverse engineering attacks in combination with the man in the middle attacks. Since they help in revealing how the requests work. The impact of infiltrating the backend servers of Spotify could however be huge, since it could affect the integrity of Spotify across all platforms and lead to data leakage and modification for all its users. Repacking attacks are given high priority for the Spotify application since it is relatively easy to do, requiring an android device with Spotify and reverse engineering tools as well as some basic knowledge of how Android applications work. The impact of the reverse engineering attacks could be big since they could result in revenue loss from piracy for example giving people free premium versions. It could also result in sensitive data leak from the application.
16
The accessing of inner application pages through ADB shell attack is given a medium priority since it is easy to do the attack only requiring a device with Spotify installed and a computer with ADB installed, but the impact of the attack is not huge since it most likely involves the attacker getting access to premium pages unpaid for. There could however be a small risk that the developers left testing pages within the source code that could lead to sensitive data leakage or give unauthorized features to the attacker. The deserialization attack gets a low priority, the impact of the attack could be severe with remote code execution on the victim’s device being possible but the attack is hard to execute, requiring the victim to install a malicious application on their device as well as requiring the attacker to know a lot of theory to make the attack successful.
5.4 Motivation for choice of attacks to test and their testing depth A choice was made to make a thorough test on one application instead of briefly checking a lot of applications since this could be more meaningful in the result it has. That is why almost all of the attacks were tried, where exceptions were made for the Bluetooth attack, the file processing attack and the deserialization attack which were neglected. The reason for this was that all of them got a low priority rating from the previous subchapter. This was because they were time and or resource demanding, where the budget for both already was limited. The high priority attacks were performed before the medium priority once as well as with a higher depth.
6 Penetration testing
6.1 Reverse engineering attack to find sensitive data in the application
code
BACKGROUND
All applications on Android are to some extent subject to reverse engineering. The
application files are stored in an APK on Android devices. This APK can be unzipped
with a number of different tools on a computer. There is a classes.dex file which
contains dalvik byte code, readable by the Android device, but not readable for humans.
The dex file can however be decompiled into something called smali code using a choice
of tools on a computer. Smali code is more readable for humans and is an assembler for
the dex format. The smali code is still quite hard to comprehend, so there are tools for
converting dex files into jar files, which in combination with using tools for decompiling
the jar files into plain text java. All this being done, the code still will not be perfect, and
you would not be able to execute it, the code is however pretty readable which works
great for our purposes. [27]
There are ways to protect the APK file from reverse engineering attacks and that is done
through obfuscation tools such as Proguard. Obfuscating the code makes it harder to
read, this is done by changing names of methods and classes and fields into random
17
letters. The obfuscation as such will not make it impossible to read and follow along how
the application works, but it makes it a lot more time consuming and difficult to find out
how it works. [26]
METHOD
The reverse engineering process started with downloading the Spotify application to the
Android device and then copying its APK file to a computer. A tool called Apktool was
then used to decode the resources of the APK file. In order to get the java source code
from the dex file, a tool called Jadx was used.
Once the code was reverse engineered it was time to start analyzing the code. To begin
with the AndroidManifest.xml file was analyzed. A special focus on trying to find keys
and other secrets were given. A look at what permissions were granted to the application
was also taken to see what type of potential access a hacker could get if a successful
penetration was to be made. This was followed by looking at the resources folder, giving
special attention to the strings.xml file where hardcoded strings of the application are
stored. A search for keys and other secrets were made here as well.
At this moment it was time to look at the actual source code of Spotify. The folders were
given different amounts of attention depending on if they actually had to do with Spotify
or if they were just imported libraries. They were also given higher attention if their
names and classes had more relevance in a security aspect. For example, a class such as
QuickLogin seems much more relevant to look at than a class like
LyricsFullscreenHeaderView. A special look out was made for classes such as testing
classes or admin classes and anything like that. As for looking at the classes themselves,
as had been done in the previous files a search for keys and other secrets were made.
Then the classes’ methods were analyzed to try to find out how they work and what
other classes’ methods they make use of. Weak spots in authorization and encryption
controls were also looked for. [28]
RESULTS
From the analyses of the source code and resources of the application there were not a
lot of weaknesses found. What was found however was an API key in the
AndroidManifest.xml file:
<meta-data android:name="com.crashlytics.ApiKey" android:value="ed79a89851fe4ae8eb60f37284a088b1055997d8"/>
And in the strings.xml file the following things were found:
<string name="default_web_client_id">494597445014-tfb24qacapieae13b1k4efe7p14b737q.apps.googleusercontent.com</string>
18
<string name="firebase_database_url">https://pushka-notifications.firebaseio.com</string> <string name="gcm_defaultSenderId">494597445014</string> <string name="google_api_key">AIzaSyDqQSJmMHjaXI_aFg7GWB-U2y1hk_qbFcc</string> <string name="google_crash_reporting_api_key">AIzaSyDqQSJmMHjaXI_aFg7GWB-U2y1hk_qbFcc</string>
As for the source code of the application it was clear that an obfuscation tool was in use.
The names of a lot of classes and methods were given random letters. This made the
code very hard to follow. It was possible to see that a REST interface was implemented
with requests being made to the Spotify APIs and responses sent via JSON objects. This
communication type was implemented for authorization as well as for media streaming
and searching. This means that a lot of the security aspects are outsourced to the Spotify
servers.
It could also be concluded that the source file of the application contained a huge
number of classes (over 30 000 files including the folders.) This is of course counting
imported libraries that the application uses. Out of the files looked at however (100+),
no real weaknesses were found.
DISCUSSION
The applications files did contain API keys, these keys however do not seem to be
harmful to include, since they are mainly concerned with crash analytics. The database
URL included could potentially be harmful depending on the security configuration it
uses but is not in of itself a security issue. This means that the system withstood the
reverse engineering attack to find sensitive data in the source files but because of the
huge number of files within the application only a select number of files were explored.
This means that the result does not imply that the application is completely safe from
such an attack. But it does mean that given a serious attempt with regards to searching
relevant files, nothing important was revealed. The complexity of reading the obfuscated
code could also be a weak link in the result given, because an attacker might have a
better understanding of the system at hand and could potentially find some weakness
not found in this testing.
6.2 Reverse engineering attack to make package alterations
BACKGROUND
There are many ideas behind making package alterations, these could for instance be to
get access to functions that are otherwise only available to premium users, or it could be
to install malware hidden inside the application and then trick users into downloading
the Spotify looking application with hidden malicious intentions.
19
As described in chapter 6.1’s background it is possible to reverse engineer Android
applications with a set of tools. With reverse engineered code available one can make
changes to existing files and add new ones as well. Using tools on a computer you can
compile the reverse engineered files back into an APK. This APK can then be signed with
other tools available making it possible to install the application on the Android device.
[29]
Since this is a big security issue there are ways to try to prevent this such as root
detection code that can check if the device is rooted. A self-protection method can be
used that randomly splits repackage detection code into several blocks which are then
directly inserted into the applications’ byte code. This method can thus detect
modifications to the code. [8], [30]
METHOD
The same steps taken in 6.1 can be made to get the reverse engineered files of the
application in this step. The strings.xml file was modified in order to see if the
application was able to detect such minor changes like changing a string name. The next
test was to test altering java code within source files, the last test was to add new maps
and new files. For every test once the code was altered the APK was rebuilt using
Apktool, and then signed with a key using jarsigner. Before being installed on the
Android device.
RESULTS
The result of the testing was that changes to string names were not detected but the
impacts were nothing but aesthetic as the name of things displayed in the UI was
altered. As for both trying to alter java source code and trying to add files and folders to
the application, an error was given when trying to build the APK:
Robins-MacBook-Air:Repackage robin$ apktool b com.spotify.music-1.apk-decompiled/ -o
com.spotify.music-1.apk
I: Using Apktool 2.4.1
I: Checking whether sources has changed...
I: Smaling smali folder into classes.dex...
W: Unknown file type, ignoring: com.spotify.music-1.apk-decompiled/smali/.DS_Store
W: Unknown file type, ignoring: com.spotify.music-1.apk-decompiled/smali/com/.DS_Store
W: Unknown file type, ignoring: com.spotify.music-1.apk-decompiled/smali/com/moat/.DS_Store
W: Unknown file type, ignoring: com.spotify.music-1.apk-
decompiled/smali/com/moat/analytics/.DS_Store
W: Unknown file type, ignoring: com.spotify.music-1.apk-decompiled/smali/com/spotify/.DS_Store
W: Unknown file type, ignoring: com.spotify.music-1.apk-
decompiled/smali/com/spotify/music/.DS_Store
20
W: Unknown file type, ignoring: com.spotify.music-1.apk-
decompiled/smali/com/spotify/signup/.DS_Store
W: Unknown file type, ignoring: com.spotify.music-1.apk-
decompiled/smali/com/spotify/signup/api/.DS_Store
W: Unknown file type, ignoring: com.spotify.music-1.apk-
decompiled/smali/com/spotify/signup/api/services/.DS_Store
W: Unknown file type, ignoring: com.spotify.music-1.apk-decompiled/smali/com/malware/.DS_Store
Exception in thread "main" org.jf.util.ExceptionWithContext: Exception occurred while writing
code_item for method Lcom/comscore/android/vce/b;->a([Ljava/lang/String;)V
at org.jf.dexlib2.writer.DexWriter.writeDebugAndCodeItems(DexWriter.java:917)
at org.jf.dexlib2.writer.DexWriter.writeTo(DexWriter.java:341)
at org.jf.dexlib2.writer.DexWriter.writeTo(DexWriter.java:297)
at brut.androlib.src.SmaliBuilder.build(SmaliBuilder.java:61)
at brut.androlib.src.SmaliBuilder.build(SmaliBuilder.java:36)
at brut.androlib.Androlib.buildSourcesSmali(Androlib.java:418)
at brut.androlib.Androlib.buildSources(Androlib.java:349)
at brut.androlib.Androlib.build(Androlib.java:301)
at brut.androlib.Androlib.build(Androlib.java:268)
at brut.apktool.Main.cmdBuild(Main.java:251)
at brut.apktool.Main.main(Main.java:79)
Caused by: org.jf.util.ExceptionWithContext: Error while writing instruction at code offset 0x6
at org.jf.dexlib2.writer.DexWriter.writeCodeItem(DexWriter.java:1190)
at org.jf.dexlib2.writer.DexWriter.writeDebugAndCodeItems(DexWriter.java:913)
... 10 more
Caused by: org.jf.util.ExceptionWithContext: Unsigned short value out of range: 65538
at org.jf.dexlib2.writer.DexDataWriter.writeUshort(DexDataWriter.java:116)
at org.jf.dexlib2.writer.InstructionWriter.write(InstructionWriter.java:356)
at org.jf.dexlib2.writer.DexWriter.writeCodeItem(DexWriter.java:1150)
... 11 more
The build error has to do with an exceeding of the maximum number of methods within
the application: 65536 [50]. Which can be seen by the error: org.jf.util.ExceptionWithContext: Unsigned short value out of range: 65538
This means that adding methods to the application is not possible without removing
already existing ones or enabling something called Multidexing through the Gradle
Build which requires access to the project files and not just the APK files.
DISCUSSION
The result indicates that package modification is possible, but to actually make the
changes useful to an attacker you have to alter the application methods. Since the
application already is at the maximum number of methods this requires you to change
existing methods and or replace them, which makes it much harder to carry out the
attack. The attack might still be possible despite this, but at least it should be deterring a
lot of attackers from trying. Further testing could be done where methods are modified
in ways that does not destroy the normal flow of the application while at the same time
introducing malicious activities into it.
21
6.3 Man in the middle attack
BACKGROUND
Man in the middle attacks are done by the attacker inserting itself in the middle of the
network where the user communicates with a server. This enables the attacker to look at
the conversation as well as tamper with the requests from the user and replies from the
server. [31]
There are different ways to prevent this type of attack. One example is using HTTPS
instead of HTTP where the data being sent is encrypted using for example TLS.
(Transport Layer Security) A typical usage scenario of TLS is having the server
configured with a certificate containing a public key and a corresponding private key.
Via a handshake procedure with the client, the server proves its validity using the
private key to sign its certificate with public key cryptography. The servers are usually
configured with well-known issuers’ certificates called Certificate Authorities (CAs). The
client then has a set of trusted CAs used to verify that the server has a certificate issued
by a CA known to the platform. There are in fact two types of certificates on an Android
device, user and system installed. It is possible to configure network security on the
application and determine if the application should trust user installed certificates or
not, as well as basing the trust on different domains. [32]
METHOD
Burp suite was used as a proxy server to intercept the traffic of the application client and
server. The settings of the Android device were changed so that it used the proxy server
at the IP address of the testing computer, and both were set to use port 8080. Testing
was made to try and intercept traffic from client/server communication. After the initial
test a certificate file was then downloaded from the Burp suite program and installed on
the Android device as a trusted certificate. With the certificate installed another traffic
interception was made when communication between client and server of the
application.
RESULTS
When trying to intercept traffic without installing the certificate of the proxy server, the
traffic data is not accessible, however with the certificate installed among trusted ones.
The data is accessible, and you can see what type of request is being made and what
response is given. However, there does not seem to be any sensitive data being exposed.
22
Figure 3 showing the results of the traffic interception
The POST request from figure 3 above is probably used for authenticating a user and
since the data being sent is sensitive, the request data is encrypted. From the result we
can conclude that the application uses HTTPS communication and probably has a
network configuration where it only trusts system installed CAs for sensitive requests to
certain domains. This means that the attacker would need to somehow use a proxy
server that has a certificate installed as a system trusted CA on the victim’s device.
DISCUSSION
The result shows that there are mitigations taken to prevent man in the middle attacks
on the Spotify Application for Android. The result does not guarantee that the
application always is safe from traffic interception, since the user could somehow
happen to be using a rooted device where it is possible to install your own system
trusted certificates and have the attacker ´s proxy certificate installed. Though it
probably means that Spotify is not held responsible for any impacts of the attack.
6.4 Looking at the inner files of the Android device
BACKGROUND
Applications store data locally on the Android device, included in this data is sensitive
information such as usernames and passwords. While the data is usually stored in a
23
data/data folder in the applications file system which cannot be accessed without root
access there are several ways of bypassing this protection scheme. It is therefore
important that the data is encrypted.
Another problem is usually the shared preferences files intended for storing things like
user preferences that can survive a restart of the application. These files can contain
key/value pairs, and sometimes developers assume this to be a safe place and insert
sensitive API keys among other sensitive information here. [33]
METHOD
Since the data of the application cannot be accessed on a normal Android device, an
attempt was made to root the device. The rooting attempts were unsuccessful for some
reason, so rather than trying for another time with another rooting method, another
method was tried. As it turned out, a method existed for accessing the data without
requiring root access. The method was to use the techniques in chapter 6.2 to repackage
the application, this time adding a debug flag in the AndroidManifest.xml file thus
enabling debug mode of the application before reinstalling the application on the device.
In the debug mode of an application, the data/data folders are accessible through an
ADB shell session of the device. This meant that it was now possible to access this folder
for the Spotify application.
After creating a test user account on the application with inputted and saved credentials,
the folders and files inside data/data were downloaded to the computer.
Some of the files were easily opened with text editors, like the shared preferences. The
folders also contained database files which were opened with the program DB Browser
for SQLite. The files were searched for API keys and other sensitive information that
might be included, along with a search for user credentials.
RESULTS
There was not anything sensitive stored in the shared preferences, except for the
username of the user and some client sender id for client cast analytics data: <map>
<string name="client_sender_id">e39e4b23-75cc-483d-b7d8-76ed8d4e32e8</string>
</map>
As well as a Crashlytics id:
<string
name="crashlytics_partner_id">00b1ee2564b8a81333d0f1f95c3c826056d9460aa8986856a2d7de</st
ring>
24
As for the database files, the account_info_db contained username in clear text and a
link to profile image of the user, possible to open without any credentials required.
There was however no password stored in the database. It was also possible to see some
user action history in cache files, such as recently played playlists:
"spotify:user:[email protected]:playlist:2MpssZFujoLoEEyP0gSkA9","collectionLink":null,
"name":"Veronica Maggio – Fiender är tråkigt
DISCUSSION
If we are looking at the attack where the user of the application owns the device and
tries to get API keys and other sensitive information regarding the application, there is
not much to be found. The ids that are found are probably not useful for attacking
purposes anyway since they are concerned with analytics data. Looking at the possibility
of an attack against the device owner through the app data however there is at least
username, profile picture and some activity history to be gained. One can however argue
that these being exposed is the least bit of worry for a user that has let an attacker get
access to their device, either through physically obtaining it or accessing it in a shell
session.
This does not guarantee that there is not anything useful for an attacker in the app data
of the device, since things can be missed when going through several lines of code and
even though search functions were used to try to find keys, ids and passwords, there are
still chances of missing important things. It does however show that the developers have
given thought as to what they put in the app data files and it seems as though the
application can withstand this type of attack.
6.5 Database attack
BACKGROUND
There are several choices of cloud databases for Android applications to use as well as
the possibility of using your own cloud database. One of the most common databases for
Android applications is Google's Firebase. The Firebase platform includes 17 products
used by more than 1.5 million applications. Among these there is the Cloud Firestore
which is a NoSQL real-time document-oriented database. There is also Firebase Cloud
Messaging which is used for messages and notifications for Android applications. [34]
Since a lot of sensitive data is stored in the databases, a big focus on security has to be
made. The Firebase platforms come with its own security implementations and how
these are used can be configured in security rules for the developer that implements
Firebase to their application. There are options to determine who are allowed to read
and write and upon which conditions. A lot of application developers have made reading
25
and writing allowed for everyone to make the testing of the database faster and easier,
there are some that forgets to change this when the application is released. While the
Firebase services are safe to use, they can be configured incorrectly to be penetrable
anyway. [35]
METHOD
Using the method from 6.1 to reverse engineer the application, it was found that the
application uses Firebase for push-notifications and the URL to the database was in fact
found:
<string name="firebase_database_url">https://pushka-notifications.firebaseio.com</string>
By trying to access the database in a web browser using: https://pushka-notifications.firebaseio.com/.json The entire database is dumped using the: .json at the end of the URL if the read operation is set to true without conditions. This method has been seen in a previous database attack carried out by Muhammad Khizer Javed [51]. Another approach was also taken to test the database security similar to the attack made by Emmanuel Ortiguela [52], where a curl command is used to try to make requests to the database: curl -X GET "https://firestore.googleapis.com/v1/projects/pushka-
notifications/databases/(default)/
RESULTS The result of trying the https://pushka-notifications.firebaseio.com/.json URL in a browser was the following response: { "error" : "Permission denied" }
The result from trying the curl command was: Robins-MacBook-Air:~ robin$ curl -X GET "https://firestore.googleapis.com/v1/projects/pushka-
notifications/databases/(default)/"
{
"error": {
"code": 401,
"message": "Request is missing required authentication credential. Expected OAuth 2 access token,
login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-
in/web/devconsole-project.",
"status": "UNAUTHENTICATED"
}
}
This means that the database uses proper security configurations where a user needs to
be authenticated for access and this means that the security responsibility is in the
hands of Firebase. The application code did not reveal any other cloud databases being
26
used. The rest of the databases used are part of the Spotify API which is penetration
tested in chapter 6.10.
DISCUSSION
The results show that the Firebase database used by the application has been configured
correctly and it is not possible to retrieve or post data on it. This means that even though
the URL of the database is visible within the application code, there is not a way of
exploiting it, unless the attacker for some reason got their hands on a valid login cookie
or authentication credential some other way. As for Spotify backend databases used by
the application there are not tests done in this penetration test so without further testing
done in chapter 6.10, it cannot yet be confirmed to withstand attacks.
6.6 Intent injection attack
BACKGROUND
Android applications use Intents to start Activities, Services and Broadcast Receivers. In
the AndroidManifest.xml used Activities, Services and Broadcast Receivers are declared,
if the exported attribute is set to true, the component can be started by other possibly
malicious applications. For security reasons an intent filter can be set to limit the forms
of actions that can be taken, what type of data that can be sent and what category the
intent should be in. [36]
The activity manager can be used in an Android Debug Bridge shell to start application
components by specifying an Intent. An attacker can use this for an intent injection
attack where for example malicious code is injected into the application through the
application component being called. To prevent an intent injection attack, the exported
attribute can be set to false, thus only allowing internal components of the application to
start the given component. If, however you have to allow external applications abilities
to start your application components it is important to sanitize the input data to make
sure it is safe as well as limiting the actions that can be taken with the above-mentioned
intent-filter. [37]
METHOD
The first step in the attack was to use the method in chapter 6.1 to reverse engineer the
application. Then the AndroidManifest.xml was checked for Components that were
exported. All 23 exported components’ intent-filters were checked as to what type of
actions they allowed and using ADB shell on a computer connected with the Android
device via USB.
27
am start -n com.spotify.music/component_name -e data was used to try to start the
exported components with different data depending on what was specified in their
respective java source files.
The next step was using the method in chapter 6.2 to repackage the
AndroidManifest.xml where the exported attribute of interesting components were
changed to true. The application was then reinstalled and in a shell session with the
device am start -n com.spotify.music/component_name -e data was tried on these
components as well.
RESULTS
All exported components included an intent-filter with specified actions that could take
place when calling the component. The intent injections resulted in the app crashing or
in nothing happening at all except for the QuickLoginActivity which was exported to
begin with without the need for repackaging. With the command:
am start -n com.spotify.music/com.spotify.loginflow/QuickLoginActivity -e username [email protected] -e password ********* The user was logged in to the application without needing to type anything on the
Android device.
DISCUSSION
The result shows that there are restrictions as to what can be sent with the intents, while
the result showed that it was not possible to start any of the components except for one,
it does not guarantee that an attacker would not be able to do it by including some
required input parameters missed in this attacking attempt.
As for the QuickLoginActivity it is not possible to send any malicious code through it
since the input is validated in the Activity code, it might however be possible to use the
type of command used to start the Activity to brute force password combinations with
wordlists. This being said it is already a problem for desktop versions of Spotify with
tools like Spotify Cracker v1 available [53].
6.7 Cross-site scripting attack
BACKGROUND
If you send a crafted intent to Android applications, you can execute malicious
JavaScript if JavaScript is enabled in the component you are calling. This type of attack
is often called Cross-application scripting. [38]
For applications in android to be vulnerable to this type of attack they need to have
exported components that use WebKit with JavaScriptEnabled(true). There are still
28
ways to protect applications that do have all the above-mentioned attributes. By using
intent-filters to limit what URLs that are accepted as well as having input validation in
the component classes these types of attacks can be prevented. It is not only possible to
send JavaScripts or a redirect to an http URL, you can also enable file-URL access to be
able to access files from the Android device via sending Intents. All of these possibilities
need to be prevented from attackers. [39]
Logcat is a command line tool that dumps a log of system messages including stack
traces with error messages of the android device. [40]
METHOD
The first step was to use the method in chapter 6.1 to reverse engineer the application.
Then the AndroidManifest.xml was looked at to see what components are exported.
Looking at the classes of these components the use of WebKit and
JavaScriptEnabled(true) was searched for. Once a class was found that had the above-
mentioned attributes the ADB shell was used on the device to try to inject code into the
component. First of an attempt to input JavaScript was made:
am start -n com.spotify.music/component_name -d “javascript:alert(1);” Secondly inputting a URL link: am start -n com.spotify.music/component_name -d “https://evilpage.com” Lastly inputting a file url: am start -n com.spotify.music/component_name -d “file:///sdcard/contacts/secretContact” After the injection attempts were done, the logcat of the Android device was looked at to see what errors the injection attempts gave. Also, a look at the class code was made to see if input was validated as well as a look at the AndroidManifest.xml if the component had an intent-filter with data specifications.
RESULTS
Out of all 23 exported components, only AuthorizationActivity included WebKit and had
JavaScript enabled. The following commands were tried:
am start -n com.spotify.music/com.spotify.mobile.android.sso.AuthorizationActivity -d “javascript:alert(1);” am start -n com.spotify.music/com.spotify.mobile.android.sso.AuthorizationActivity -d “https://evilpage.com” am start -n com.spotify.music/com.spotify.mobile.android.sso.AuthorizationActivity -d “file:///sdcard/contacts/secretContact” All commands resulted in the following error found in Logcat of the device: Caused by: java.lang.AssertionError: The in-app protocol has not been set
W/System.err( 8610): at com.spotify.mobile.android.sso.AuthorizationActivity.o(SourceFile:400)
This means that the attacks were unsuccessful. Looking at the AuthorizationActivity class it is clear that input validation is done: Intent intent = getIntent();
29
String c = hhz.c(intent); if ("1".equals(c)) { hhq = new hhu(); } else if ("sonos-v1".equals(c)) { hhq = new hhs(); } else if ("com.spotify.sso.action.START_GOOGLE_AUTH_FLOW_V1".equals(intent.getAction())) { hhq = new hhr(); } else if (intent.getDataString() != null && hhz.a(intent.getDataString())) { hhq = new hht(); }
In the AndroidManifest.xml there is data specification in the intent filter of the
component as well restricting what urls can be used: <data android:host="accounts.spotify.com"/> <data android:scheme="https"/> <data android:pathPrefix="/inapp-authorize"/>
Meaning that the application component only accepts URLs beginning with
https://accounts.spotify.com/inapp-authorize
DISCUSSION
The result shows that measures have been taken to prevent Cross-site scripting attacks
to the application and that only a single class has a potential vulnerability to it. That
class has validation methods for its input data. The application clearly withstood the
attack and unless some class used WebKit out of the 23 exported ones that was not
found, the application should be considered safe in regard to cross-site scripting attacks.
6.8 Reading of implicit Intent with sensitive data
BACKGROUND
A malicious application can register itself via intent-filter in the AndroidManifest.xml
file to receive implicit intents that were meant for other applications, this could result in
the malicious application receiving sensitive data such as authorization codes and is
called Intent hijacking [54].This is the reason why it is unwise to send sensitive data via
implicit intents. Instead explicit intents should be used for such confidential operations.
Looking at a Java code example [36], we have: Intent sendIntent = new Intent();
sendIntent.setAction(Intent.ACTION_SEND);
sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage);
sendIntent.setType("text/plain");
This is code for starting an implicit intent with a text message. Notice that no receiving
class is specified.
On the other hand, we the code from the same webpage: Intent downloadIntent = new Intent(this, DownloadService.class);
downloadIntent.setData(Uri.parse(fileUrl));
startService(downloadIntent);
30
This is an example of an explicit intent where a class has been specified for receiving the
intent.
METHOD
Using the method in chapter 6.1 the application was reverse engineered and the
AndroidManifest.xml was looked at. A search for components that might contain
sensitive data was made. Once these components were found, their source code was
analyzed to see if it contained any intent sending. If the code included intents being
sent, a check was made whether or not the intent sent was implicit or explicit. Any
implicit intent sent would then be checked to see if it contained any sensitive
information.
RESULTS
Out of the 30+ classes checked that sounded like they could potentially have sensitive
data, some of them sent out intents and none of them were implicit intents. This meant
that there was no use in trying to attack them with a malicious application since they
would not send any data to that application anyway.
DISCUSSION
Because of the big number of classes in the application and the time given to the attack
test, only a select number of classes were analyzed. This means that while the
application withstood the attack for these handpicked classes, it is not guaranteed that it
would do so for every class in the application. This test more so shows that it is likely
that the application is not vulnerable to the attack than that it is guaranteed.
6.9 Using ADB shell to explore internal application pages.
BACKGROUND
As described in chapter 2 of this report, Activities are single screen user interfaces and
they can be activated through intents. In the AndroidManifest.xml file you can set an
exported attribute as true in order to be able to call the component outside of the
application it belongs. By using the Activity Manager (AM) over an Android Debug
Bridge (ADB) shell session with the Android device, intents can be sent to try to start
activities from the application. Since this is a possibility you should not leave any testing
or admin pages on the application when released to the public. You should also
preferably have session/token management for accessing data from the servers of the
application. [17]
31
METHOD
The first step was to use the method in chapter 6.1 to reverse engineer the application.
After that a look was taken on the AndroidManifest.xml to see what Activities were used
by the Spotify application. Names like test or admin were searched for as well as other
relevant sounding names. Some of the Activities were already exported while other
activities could be exported through the repackaging method in 6.2 when a new
application was installed where these activities were exported as well. For all activities
tested the ADB shell was used on the device and the command: am start -n
com.spotify.music/Activity_Name to invoke the activity to start. The logcat was looked
at for seeing possible errors linked to the starting of the Activities.
RESULTS
There were no Activities found that were there for testing or admin purposes. There
were however some activities that had interesting names. Out of these activities some
were just normal activities that you are allowed to access anyway within the application
and trying to open some other of them actually caused the application to crash. No
unprivileged operations were performed from this attack.
DISCUSSION
The result indicates that the attack was unsuccessful in regard to performing
unprivileged operations or gaining access to testing or admin pages. The test did
however not go through every single activity, and guarantees cannot be made that the
neglected activities will not give the attacker something. They were neglected however
because of time and the fact that their names did not suggest that they would be
dangerous or unallowed to access. The test did have cases where the application
crashed, this could be used by an attacker to do a Denial of Service attack. The attacker
could create a malicious application which constantly made calls to the activity that
causes the application to crash, meaning that the application would be unusable. This
could be useful for competing companies since it would make the customer choose them
instead. This type of attack does require the user to install malware and stopping this is
something that should be handled by the operating system rather than the application
itself, but measures could have been taken to avoid the crash.
6.10 Backend server attacks
BACKGROUND
Using a proxy server on the application you can see what requests and replies are made
between client and server. This information combined with looking at the source files of
the application for secret API keys or other things that might compromise the backend
32
servers, could possibly enable an attacker to make privileged server requests among
other things. [41]
As can be seen in chapter 4 of this report the application makes calls to Spotify backend
servers using authentication tokens. Requiring authentication when making calls to the
Spotify API means that attackers are prevented from getting unauthorized access to the
servers.
METHOD
Using the method in chapter 6.3 the calls that the application makes to the backend
servers are revealed. Using the curl command in a terminal window, attempts were
made to make calls to the URLs used by the application. Using the methods in chapter
6.1 and 6.4 the application was searched to see if it revealed any compromising
information regarding access to the backend servers.
RESULTS
No information that could compromise the backend servers was found when using the
methods from chapter 6.1 and 6.4. When trying to make calls to the servers every
attempt failed due to being unauthorized to make the request. For example:
curl https://api.spotify.com/v1 gives {
"error": {
"status": 401,
"message": "No token provided"
}
}
DISCUSSION
Looking at developer pages of Spotify [55], you can see that other developers are allowed
to make calls to their APIs using authorization tokens from logging in a user to their
Spotify account. So, there is no secret regarding the calls that the application makes, and
they are in fact meant to be used by other applications. The API calls are also used by
desktop versions as well and therefore making further attempts to attack these servers
falls a bit out of scope of this project. The focus of the attack was rather on what could be
revealed through the application code, and nothing useful in attacking the backend
servers was found. This does not guarantee the code is free from backend compromising
information, since every line of code was not searched. The result does however show
that it is not easy to find any exploitable information looking through the application
files.
33
7 Ethics and sustainability Since a bug bounty type of project was chosen, and due to the fact that the Spotify team
even have their own bug bounty program it is actually allowed for people to try to
penetrate their application, provided that guidelines were followed. One of such
guidelines was to use your own accounts for the testing, as to not compromise other
people's privacy. Another guideline was to not use automated testing without consulting
with them first since they can be very loud for Spotify's detection system. [42]
The guidelines mentioned above was followed, and the principle of responsible
disclosure [56], was going to be followed in case of any exploits being found. In this
manner the project actually is ethically sound and with a goal that is ultimately to make
the application more secure and even have the research act as help for other
application’s security, the impact of the project should be considered good.
Looking at the environmental impacts of the project, the research was done with eBooks
and internet articles. In comparison with physical books, no paper or shipping of the
book was needed. The computer and android device that was used for the testing were
used devices hence, no new devices had to be produced for the project. This means that
the direct environmental impact of the project is very low. As for Spotify, the plastic
production has gone way down since the selling of CDs did so. Though, studies done by
a team from the University of Glasgow in the UK and the University of Oslo [57], show
that the environmental impact may have gone up anyways due to the energy resources
required for streaming the music being so high. Helping Spotify with their security,
could mean helping them expand which could actually be bad for the environment. The
choice of application to review the security of could hence have environmental impacts
indirectly and choosing eco-friendly companies could help bring down the
environmental impacts.
8 Results
The result of all the penetration testing was that no exploits worthy of reporting were
found. The testing showed that mitigation measures had been taken to avoid every
attack scenario mentioned in the threat model of this report. While hardcoded API keys,
listening history and a database URL was found within the code, it was no real value
getting them to an attacker. There were ways for malicious applications to make Denial
of Service attacks against the Spotify application by calling components that cause the
application to crash. Though stopping malicious applications like this is at least in part
the responsibility of the operating system. In intent injection attacks it was possible to
login to Spotify through an ADB shell in a terminal, while this could be a problem for
34
brute force attacks, that problem already exists for the desktop version of Spotify
anyway.
9 Discussion
As can be seen from the results of penetration testing the Spotify application for
Android, the application is very secure. The tests are however not definitive proof of the
application being able to withstand these attacks, since further testing could have been
made in every category. To give an example, the reverse engineering attack could have
been given more time to understand the system as well as try to find weaknesses in the
code.
Reviewing the security of Android applications is not a one-man job, and claims are not
made to convince the reader that the application is impenetrable. Rather the project
shows a procedure that can be taken when reviewing the safety of an application. This
procedure can just as well be taken to review other Android applications adjusting
attack focus and depth depending on the respective applications risks. The reason that
the rewards program exists in the first place is to motivate a lot of people to try to find
weaknesses in the application and together contribute to making it safe.
10 Conclusions
While penetration tests were made to try to find exploits in the application, the end goal
never revolved around actually finding exploits since the application has a big security
team behind it as well all bounty hunters from the reward program already finding these
types of exploits. If the goal was to actually find exploits in an Android application, a
better bet would have been to look at less popular applications with a lot of weaknesses
yet to be revealed. The impact however of finding those exploits is not near as big as
finding them in popular applications with a lot more users.
The testing results do show how serious the Spotify team is when it comes to security
and can act as a template for further research into the Spotify application as well as
other applications on the Google Play Store.
35
References
[1] Synopsys Editorial Team. “The 5 pillars of a successful threat model” URL: https://www.synopsys.com/blogs/software-security/5-pillars-successful-threat-model/ [2] Guard square. “Proguard” URL: https://www.guardsquare.com/en/products/proguard [3] OWASP. “OWASP Mobile top 10” URL: https://owasp.org/www-project-mobile-top-10/ [4] OWASP. “OWASP Application threat modeling” URL: https://owasp.org/www-community/Application_Threat_Modeling# [5] OWASP. “OWASP Simplifying threat modeling” URL: https://2011.appsecusa.org/p/simplifyingthreatmodeling.pdf [6] Common Weakness Enumeration. “Common weakness enumeration” URL: https://cwe.mitre.org/data/definitions/927.html [7] Certificate Transparency. “Certificate transparency” URL: https://www.certificate-transparency.org/ [8] Internet Society. “Self-protection code prevent app repackaging” URL: https://www.internetsociety.org/resources/doc/2017/protecting-android-apps-from-repackaging-by-self-protection-code/ [9] Denim group. “Developing secure mobile applications” URL: https://www.slideshare.net/denimgroup/developing-secure-mobile-applications-17732256 [10] Threat modeling, designing for security, Adam Shostack (2014) [11] Android Application Secure Design/Secure Coding Guidebook, Japan Smartphone Security Association (2019) [12] A Comprehensive Study on Security issues in Android Mobile Phone — Scope and Challenges, International Journal of Innovative Research in Advanced Engineering (2016) [13] Mobile Device Exploitation Cookbook, Prashant Verma, Akshay Dixit (2016) [14] X. Jin, X. Hu, K. Ying, W. Du, H. Yin, G. N. Peri. “Code Injection Attacks on HTML5-based Mobile Apps: Characterization, Detection and Mitigation” URL: http://www.cis.syr.edu/~wedu/Research/paper/code_injection_ccs2014.pdf [15] B. A. Bache. “Cross-site Scripting Attacks on Android WebView” URL: https://www.researchgate.net/publication/236455748_Cross-site_Scripting_Attacks_on_Android_WebView [16] P. Panda. “Understanding OWASP Top 10 Mobile: Client Side Injection” URL: https://www.appknox.com/blog/understanding-owasp-top-10-mobile-client-side-injection [17] T. Melamed. “Hacking Android Apps Through Exposed Components” URL: https://www.linkedin.com/pulse/hacking-android-apps-through-exposed-components-tal-melamed/ [18] OWASP. “A8:2017-Insecure Deserialization” URL: https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A8-Insecure_Deserialization [19] Android Developers. “App Manifest Overview” URL: https://developer.android.com/guide/topics/manifest/manifest-intro [20] D. Nautiyal. “Android System Architecture” URL: https://www.geeksforgeeks.org/android-system-architecture/
36
[21] S. Lahoti. “What role does Linux play in securing Android devices?” URL: https://hub.packtpub.com/what-role-does-linux-play-in-securing-android-devices/ [22] Android Developers. “Application Fundamentals” URL:
https://developer.android.com/guide/components/fundamentals
[23] Android Developers. “Android Security Features” URL:
https://source.android.com/security/features
[24] Android Developers. “Analyze your build with APK Analyzer” URL:
https://developer.android.com/studio/build/apk-analyzer
[25] M. Rouse. “Android OS” URL:
https://searchmobilecomputing.techtarget.com/definition/Android-OS
[26] DLT Labs. “Introduction to Code Obfuscation” URL: https://medium.com/better-programming/code-obfuscation-introduction-to-code-obfuscation-part-1-93a6797349b0 [27] Curls. “Reverse engineering and modifying an Android game (.apk) — CTF” URL: https://medium.com/swlh/reverse-engineering-and-modifying-an-android-game-apk-ctf-c617151b874c [28] J. Damian. “What to Look for When Reverse Engineering Android Apps” URL: https://www.nowsecure.com/blog/2020/02/26/what-to-look-for-when-reverse-engineering-android-apps/ [29] W. Du. “Android Repackaging Attack Lab” URL: http://www.cis.syr.edu/~wedu/seed/Labs_16.04/Mobile/Android_Repackaging/Android_Repackaging.pdf [30] Guardsquare. “Protecting Android applications and SDKs against reverse engineering and hacking” URL: https://www.guardsquare.com/en/products/dexguard [31] Imperva. “Man in the middle (MITM) attack” URL: https://www.imperva.com/learn/application-security/man-in-the-middle-attack-mitm/ [32] M. Dolan. “Android Security: SSL Pinning” URL: https://medium.com/@appmattus/android-security-ssl-pinning-1db8acb6621e [33] Srinivas. “Insecure Local Storage: Shared Preferences” URL: https://resources.infosecinstitute.com/android-hacking-security-part-9-insecure-local-storage-shared-preferences/ [34] D. Winder. “4,000 Android Apps Expose Millions Of Passwords, Phone Numbers And Messages” URL: https://www.forbes.com/sites/daveywinder/2020/05/12/revealed-4000-android-apps-expose-millions-of-passwords-phone-numbers-and-messages/#8e7cdc1438d2 [35] Firebase. “Firebase Security Rules” URL: https://firebase.google.com/docs/rules [36] Android Developers. “Intents and Intent Filters” URL: https://developer.android.com/guide/components/intents-filters [37] Srinivas. “Android Hacking and Security, Part 3: Exploiting Broadcast Receivers” URL: https://resources.infosecinstitute.com/android-hacking-security-part-3-exploiting-broadcast-receivers/ [38] AndroidVulnerabilities. “Browser Cross-App Scripting” URL: https://androidvulnerabilities.org/vulnerabilities/Browser_Cross-App_Scripting [39] E. Yalon. “Android WebView: Secure Coding Practices” URL:
37
https://www.checkmarx.com/2017/11/16/android-webview-secure-coding-practices/ [40] Android Developers. “Logcat command-line tool” URL: https://developer.android.com/studio/command-line/logcat [41] Hacking Android, Srinivasa Rao Kotipalli, Mohammed A. Imran (2016)
[42] HackerOne. “Spotify - Bug Bounty Program | HackerOne” URL:
https://hackerone.com/spotify
[43] M. Anicas. ”An Introduction to OAuth 2” URL:
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
[44] J. Richer. “User Authentication with OAuth 2.0” URL: https://oauth.net/articles/authentication/ [45] W. Enck, M. Ongtang, P. McDaniel. “Understanding Android Security” URL: https://www.researchgate.net/publication/224378192_Understanding_Android_Security [46] J. Clement. “Annual number of app downloads from the Google Play Store worldwide from 2016 to 2019” URL: https://www.statista.com/statistics/734332/google-play-app-installs-per-year/ [47] C. Cimpanu. “Google adds all Android apps with +100m installs to its bug bounty program” URL: https://www.zdnet.com/article/google-adds-all-android-apps-with-100m-installs-to-its-bug-bounty-program/ [48] A. Spadafora. “Google boosts bug bounties for Play Store apps” URL: https://www.techradar.com/uk/news/google-ups-play-store-bug-bounties [49] D. Czagan. “Qualitative Risk Analysis with the DREAD Model” URL: https://resources.infosecinstitute.com/qualitative-risk-analysis-dread-model/ [50] Android Developers. “Enable multidex for apps with over 64K methods” URL: https://developer.android.com/studio/build/multidex [51] M. K. Javed. “Exploiting Insecure Firebase Database” URL:
https://blog.securitybreached.org/2020/02/04/exploiting-insecure-firebase-database-
bugbounty/
[52] HackerOne. “Firebase Firestore insecure database” URL:
https://hackerone.com/reports/731724
[53] T. Armerding. “Is your Spotify password up to scratch?” URL: https://nakedsecurity.sophos.com/2018/01/04/is-your-spotify-password-up-to-
scratch/
[54] The MITRE Corporation. “Android Intent Hijacking” URL:
https://attack.mitre.org/techniques/T1416/
[55] Android Developers. “Web API Tutorial” URL:
https://developer.spotify.com/documentation/web-api/quick-start/
[56] HackerOne. ”Responsible Disclosure Limits Risk” URL:
https://www.hackerone.com/responsible-disclosure-overview
[57] B. Pedersen. ”The environmental impact of streaming music with Spotify and co.”
URL: https://www.dpa-international.com/topic/environmental-impact-streaming-
music-spotify-co-urn%3Anewsml%3Adpa.com%3A20090101%3A190524-99-365820
TRITA-EECS-EX-2020:475
www.kth.se