Assessing the Security of Android Dating Apps
Värdering av säkerheten i dating- appar för Android
HAMPUS HAUFFMAN ADAM MEYER
KTH ROYAL INSTITUTE OF TECHNOLOGY
SCHOOL OF ENGINEERING SCIENCES IN CHEMISTRY, BIOTECHNOLOGY AND HEALTH
Android Dating Apps
HAMPUS HAUFFMAN, ADAM MEYER
Degree Programme in Computer Engineering Date: June 7, 2020
Supervisor: Shahid Raza Examiner: Ibrahim Orhan
School of Engineering Sciences in Chemistry, Biotechnology and Health
Swedish title: Värdering av säkerheten i dating-appar för Android
Abstract
Dating apps are continuously becoming a larger part of the social media mar- ket. Like any social media app, dating apps utilize a large amount of personal data. This thesis analyzes two dating apps and how they handle personal infor- mation from a security and privacy standpoint. This was done by conceptual- izing a threat model and then validating the threat through penetration testing on both of the apps in an attempt to find security vulnerabilities. This analysis proves that there is a substantial difference in whether or not app developers take security seriously or not. It was found that in one of the two apps analyzed, gaining access to personal data was particularly more trivial than expected, as TLS or other encryption were not implemented and server-side authorization was lacking in important app features like the one-to-one user chat.
Keywords – Penetration testing, ethical hacking, dating apps, Android, reverse engineering, threat modeling, risk rating
iv
Sammanfattning
Dating-appar blir kontinuerligt en större del av moderna sociala medier. Likt andra sociala medier utnyttjar dating-appar en stor mängd personlig informa- tion för att skapa relevanta matchningar med andra användare. Detta arbete analyserar två dating-appar och hur de hanterar känsliga personuppgifter med hänsyn till informationssäkerhet. Detta uppnåddes genom skapandet av en hot- modell (Threat Model) som senare validerades genom penetrationstestning av respektive app i ett försök att finna säkerhetssårbarheter. Sammanfattningsvis visar arbetet att det finns en tydlig skillnad mellan att utvecklare tar säker- het på allvar och att det underprioriteras. I en av de två apparna var tillgång till personliga data mycket enklare än vad som förväntades då appen saknade kryptering av trafik och var bristfällig i auktorisering av användare, speciellt i funktioner som en-till-en chatten.
1 Introduction 1
1.1 Problem Definition . . . 2
1.2 Objective . . . 2
1.3 Limitations . . . 2
1.3.1 Attack Surfaces . . . 3
2 Background and Related Works 4 2.1 Security Threats and Risk . . . 4
2.2 Threat Modeling . . . 5
2.2.1 The STRIDE Method . . . 5
2.2.2 Risk Assessment . . . 6
2.3 The Android Platform . . . 7
2.3.1 Android Security Mechanisms . . . 7
2.3.2 The Google Play Store . . . 8
2.4 Online Dating Apps . . . 9
2.4.1 Dating App #1 . . . 9
2.4.2 Dating App #2 . . . 9
2.5 Publishing Security Concerns . . . 9
2.6 Related Works . . . 10
3 Method 13 3.1 Threat Model . . . 13
3.1.1 Identifying Assets . . . 14
3.1.2 Finding Threats . . . 15
3.1.3 Risk Rating . . . 18
4 Results 22 4.1 Reverse Engineering the Apps . . . 22
4.1.1 Reverse Engineering App #2 . . . 24
v
vi CONTENTS
4.1.2 Reverse Engineering App #1 . . . 24
4.2 Tampering with API Requests . . . 25
4.2.1 Tampering with API Requests in App #2 . . . 25
4.2.2 Tampering with API Requests in App #1 . . . 26
4.3 Disclosure of Chat Messages . . . 27
4.3.1 Disclosure of Chat Messages in App #2 . . . 27
4.3.2 Disclosure of Chat Messages in App #1 . . . 28
4.4 Spoofing User Identity . . . 28
4.4.1 Spoofing User Identity in App #2 . . . 28
4.4.2 Spoofing User Identity in App #1 . . . 29
5 Discussion 30 5.1 Interpretations . . . 31
5.2 Implications . . . 31
5.3 Limitations . . . 31
5.4 Recommendations . . . 32
6 Conclusions 34 Bibliography 36 A HTTP Communication 38 A.1 HTTP Response When Fetching Chat Messages in App #2 . . 38 A.2 Proof-of-Concept Script for Fetching Chat Messages in App #2 39
Introduction
As an increasing number of people are using online dating applications (apps), more and more personal data is being transmitted and stored by the companies developing the apps. To compete on a saturated market of these apps, devel- opers are focusing on extra functionality and ease of use such as user cloud storage or in-app messaging. This, however, raises the important question of how security and privacy are handled for user data. Apps in the dating app market are differentiated not only by their features but also by their number of downloads and active users. By examining two dating apps with different levels of popularity and production a light can be shed on how security and privacy is handled in Android dating apps regarding different scenarios and attack surfaces.
The main objective of this report will be to assess the security of two Android dating apps by performing an initial threat modeling phase on each targeted app followed by penetration testing of the most crucial attack surfaces for the apps, respectively. By doing this on more than one dating app it will further highlight how security and privacy is handled in different scenarios, finan- cially and socially. The first app in question is one of a higher standard and downloaded by millions of users. The second app has a significantly smaller user base with a smaller budget, especially in regards to security. Both the apps are from the Google Play Store, written in either Java or Kotlin and are used on Android devices.
1
2 CHAPTER 1. INTRODUCTION
1.1 Problem Definition
Mobile applications can be permitted to collect a large amount of personal in- formation such as physical location or other personal data that is required in dating apps, for example, users current location, sexual orientation and sexual preferences. One might therefore expect mobile apps to have more robust secu- rity measures than web-based implementations. However Qin, et al. [1] have shown in their work assessing the security of specifically online dating apps, that many popular dating apps have had the recurring vulnerability of fully disclosing victims’ location. This information could, in worst-case scenarios, easily be taken advantage of by cyber-stalkers but is already a major violation of user privacy. A paper by Patsakis, et al. [2], similar to the work by Qin, also shows recurring threats to private user data in dating apps. Patsakis’ work shows that many popular apps unintentionally disclose sensitive information such as sexual orientation, preferences, emails, the degree of interaction be- tween users and more. In accordance with the conclusions of Patsakis’ work, it is important to disclose security vulnerabilities to inform and engage the public in cyber security and privacy matters but also in order to question pro- gramming practices in place for dating apps. Is it possible to comprehensively assess the security of Android dating apps through penetration testing?
1.2 Objective
The main objective of the project is to assess some general aspects of the secu- rity of Android dating apps and to convincingly demonstrate whether the sys- tem is secure or not through threat modeling, followed by a series of penetra- tion tests on chosen attack surfaces to validate the threat model. The category in question is online dating apps and the project will focus on the Android plat- form. Through threat modeling, a systematic process for identifying threats and potential attacks is set in place. A threat model identifies relevant attack surfaces to then be validated by attempting to find vulnerabilities through pen- etration testing. Not finding vulnerabilities after these steps can also attest to a sufficient implementation of security in the targeted system.
1.3 Limitations
This project will only focus on the Android platform and the Google Play Store given that it is one of the largest mobile application markets and its largest
competitor, Apple, has a more closed off platform and a more restricted mar- ketplace for app developers security-wise. Another delimiter for this project is the chosen scope in which to search for possible vulnerabilities as a fully qualified security audit would be too large of a project withing the given time frame.
For identifying and validating threats on a more technical level, the project depends heavily on the decompiled source code for each of the dating apps.
The source code can be statically analyzed in an attempt to find errors made by the developers. This also aims to show some contrast between a good and a bad app (security-wise) by showing their different implementations of core security principles. A completely comprehensive analysis of even one app would however be impossible for a team of two people within the timespan of a bachelor thesis. Time being a limiting factor, finding entry points and utilizing the threat model for efficient analysis is crucial.
1.3.1 Attack Surfaces
The attack surfaces to be subjected to penetration testing will be chosen through threat modeling and risk rating. For a fair assessment of chosen dating apps, the threat modeling scope and methods must be comprehensive. Therefore, risk analysis for each threat will be used to also factor in likelihood and con- sequence. Only those threats that are most likely to occur and have the most critical consequences can then be chosen for validation through penetration testing, making for a more qualitative assessment.
Denial of Service attacks will be viewed as out of scope for the penetration testing section of this project as there is usually no way to legally validate threats for this in a production environment not owned by the testers. Also, mitigation techniques are usually very complicated and therefore it is assumed they are of a lesser priority for developers. They will still be examined but to a lesser extent than other aspects of security and user privacy.
With these limitations in mind it will still be possible to conduct a comprehen- sive assessment of the security in two Android dating apps. In the next chapter important terms and concepts regarding Android app security threat modeling and risk analysis are explained.
Chapter 2
Background and Related Works
This chapter presents fundamental aspects of threat modeling and risk analysis important to the field of information security. It also covers important parts of the Android platform and its security features. Finally, different previous works in the field of threat modeling and dating app security are presented to give the reader an overview of what is possible and what is not in this field of security research.
2.1 Security Threats and Risk
Having a clear understanding of the terms and concepts that this study explores is vital for a comprehensive analysis of mobile applications. We choose to de- fine the most used terminology as follows. A threat in regards to cyber security is an exploitable vulnerability that attackers with malicious intent can use to their advantage to cause damage or gain unauthorized privileges and/or data.
A model is defined here as a tool for conceptualizing or generalizing a sys- tem in order to gain an overview, while still abstracting over technical details.
Risk can be described as the odds or chance of a vulnerability being exploited.
Risk assessment is an essential step in threat modeling. There are multiple methodologies developed for risk assessment and threat modeling. DREAD is a methodology developed for risk assessment and will be described more in detail later in this chapter. Bug Bounty programs are well-defined guide- lines for hacking, set up by the developers of a service or app, that security researchers can follow to find vulnerabilities often with a small monetary re- ward as an incentive.
4
2.2 Threat Modeling
The literature review by Xiong and Lagerström has identified different ways of defining threat modeling in the cyber security arena [3]. Their results in part refer to Uzunov and Fernandez who define threat modeling as “a process that can be used to analyze potential attacks or threats” [4]. Also mentioned is the definition by Bedi, et al. who describes it as “a structured way to secure software design, which involves understanding an adversary’s goal in attacking a system based on the system’s assets of interest” [5].
Threat modeling is also well-described, in a more practical sense, in Threat Modeling - Design by Security, by Shostack, as a method for identifying threats to gain a better understanding of what can and is likely to go wrong in a sys- tem [6]. Understanding what could go wrong can be done with building blocks like the STRIDE mnemonic (spoofing, tampering with data, repudiation, in- formation disclosure, denial of service and elevation of privilege) and attack libraries. Shostack further explains, more practically, how the process of threat modeling can be built by answering four questions:
• What is being built/has been built?
• What can go wrong?
• What should be done to preempt these threats?
• Has the analysis been sufficiently thorough?
Shostack uses these four questions as a four-step framework to cover the core aspects of threat modeling for software. [6]
2.2.1 The STRIDE Method
STRIDE stands for Spoofing, Tampering with data, Repudiation, Information disclosure, Denial of service and Elevation of privilege. It can be used as a mnemonic device for identifying what can go wrong in regards to application security.
Spoofing of Identity or Files
Spoofing identity could happen when an actor attempts to gain access to the system through pretending to be someone they are not. In an application this would mean pretending to be another user in the application. It could also be possible to spoof files in a system. For example, if an actor can upload image
6 CHAPTER 2. BACKGROUND AND RELATED WORKS
files to a system it could be possible to in some way upload a file that can later execute some malicious payload as the system assumes the file is only an image, or other media type, and opens it regardless.
Tampering with Data
Tampering with data in a mobile app could mean modifying requests or pack- ets being transmitted over the Internet or other internal network.
Repudiation
Repudiation is an actor denying that something they have done has happened.
Repudiation in mobile apps could be for example, an actor denying that an in-app purchase has been made resulting in a mistaken refund of any made payment.
Information Disclosure
Information disclosure is the exposure of any system-stored information to an unauthorized actor.
Denial of Service
Denial of service (DoS) attacks are designed to dismantle the overall service of the target app/system, by slowing it down or making it unstable in some way.
Elevation of Privilege
Elevation of privilege is the process of finding some way of gaining privilege to access technical capabilities otherwise restricted for normal users. For an app, this could mean getting past restricted access to a business logic server or database.
2.2.2 Risk Assessment
The level of risk for a threat can be calculated with the following equation:
Risk = Likelihood ∗ Impact
This model is one of the core principles of security risk assessment and is the base of many rating systems. The need for a rating system that extends
this model is derived from the fact that a qualitative assessment of risk can be subjective.
The DREAD Ranking System
The DREAD ranking system is created by Microsoft1and has been used in their Security Development Lifecycle (SDL)2. DREAD is an acronym that stands for:
• Damage – how bad would an attack be?
• Reproducibility – how easy is it to reproduce the attack?
• Exploitability – how much work is it to launch the attack?
• Affected users – how many people will be impacted?
• Discoverability – how easy is it to discover the threat?
2.3 The Android Platform
Android is an operating system for mobile devices based on a Linux kernel.
Most Android applications are written in Java or Kotlin. Any code in these lan- guages is compiled to Java bytecode which is a set of instructions for the Java Virtual Machine (JVM). The bytecode is then further compiled into Dalvik Executable Code (DEX bytecode) which is executed in The Android Runtime (ART) or DALVIK runtime (for older versions of Android). Android appli- cations are packaged in the APK file format. APK is a compressed file-type similar to the ZIP format, with the suffix “.apk". This archive is similar to a Java jar file in the way that it holds all code but also non-code resources, such as images or configuration files, for the application. The non-code resources are mostly the resource files for the Android app, which contain, among other things, configuration settings, device permission settings and values such as static strings of text that the app uses. [7]
2.3.1 Android Security Mechanisms
There are two main security mechanisms at the Linux layer in Android: the Portable Operating System Interface (POSIX) users, and file access. Since, in
1Microsoft Threat Modeling (DREAD): https://docs.microsoft.com/en-us/previous- versions/msp-n-p/ff648644(v=pandp.10)?redirectedfrom=MSDN
2Microsoft SDL: https://www.microsoft.com/en-us/securityengineering/sdl
8 CHAPTER 2. BACKGROUND AND RELATED WORKS
an Android system, each app is contained in its own archive (.apk file) each archive is simply assigned its own unique POSIX user ID. Two different pack- ages can therefore not access/run each other’s code. Files utilize the permis- sions system already implemented in Linux. Each file has a set of mode bits that can be set to authorize reading, writing and execution of that file. Mode bits can set authorization mode for the user ID of the owner of the file, the POSIX group the user is affiliated with and all other users, respectively.
Above the operating system layer, the runtime environment itself also has se- curity mechanisms in place that are inherited both from Linux but also from the main application language, Java. The runtime environment is built on the concept of a memory management unit (MMU) which ensures that processes are separated into different address spaces in virtual memory. This too is an inherited feature from Linux and further ensures that processes and, in An- droid’s case, different apps can not read from/write to each other’s memory.
The use of Java in Android ensures type-safety, which prevents undesired in- put being written to memory, often the case in buffer-overflow attacks. Other systems programming languages, such as C, allow for casting of variables to other types without any checking, which can lead to variables overflowing into other parts of memory.
In regards to more Android-specific security mechanisms there is an Android permissions system allowing for apps to access different device hardware fea- tures. With over 100 different permissions, Android apps can request access to the device’s camera, phone features (dialing voice calls, SMS, etc.), position services (GPS) and more. Furthermore, Integrity and authenticity of down- loaded apps is handled by a signing mechanism at the APK level. By signing the .apk file with a private key and enclosing a public key and a valid certifi- cate, the app’s integrity can be validated and authenticated as “same-origin”
across other apps on the device. [7]
2.3.2 The Google Play Store
The Google Play Store is a centralized marketplace created by Google where Android users are able to download and install packaged Android apps to their devices. According to Statista surveys, as of December 2019, there were an estimated 2.800.000 apps available in total3 and an estimated 84,3 billion
3https://www.statista.com/statistics/266210/number-of-available-applications-in-the- google-play-store/
counted downloads that year alone.4
2.4 Online Dating Apps
There are many online dating apps in the market that all share a similar goal, create a platform for people to interact and in some way profit from this, whether this be from ads, selling user data or in-app purchases. These apps require a full stack solution in which data needs to be stored in the device, at servers and be sent to other users. Making this secure for the Android platform is achievable5, especially with the guidelines and security features in available Android development guidelines6.
2.4.1 Dating App #1
App #1 is one of the largest dating apps for the Android platform according to the number of downloads in the Google Play Store. The app has a Bug Bounty program which provides clear guidelines for performing security research and disclosing any found vulnerabilities regarding the app itself, and the backend services it communicates with.
2.4.2 Dating App #2
App #2 has over 1000 downloads, according to Google Play Store. The app is connected to the same database as other very similar dating apps made from the same company. The second app allows for matches like any other dating app, has in app purchases and keeps information regarding you in a profile page.
2.5 Publishing Security Concerns
By publishing security concerns in dating apps it is intended to illustrate the security risks that must be taken into consideration when not only developing an app but also using one. Demonstrating the lack of security in an Android app will solidify the hypothesis that developers for mobile applications have
4https://www.statista.com/statistics/734332/google-play-app-installs-per-year/
5Android Security Development: https://developer.android.com/training/articles/security- tips
6Android Security Best Practices: https://developer.android.com/topic/security/best- practices
10 CHAPTER 2. BACKGROUND AND RELATED WORKS
not yet reached an acceptable baseline approach for handling security and pri- vacy issues. In a talk given at the security conference DEF CON7, Stephan Huber and Siegfried Rasthofer showed their results from researching Android apps for monitoring children or other family members. Researching 19 apps of varying popularity and production/design quality, their team found over 37 vulnerabilities8 proving there is undoubtedly reason for concern in regards to user privacy in this domain of apps. Publishing findings in security research is important, especially in Huber and Rasthofer’s case, as it informs the pub- lic and the apps’ users of the importance of cybersecurity and online privacy.
Through the Google Play Security Reward Program, companies have reached out to security researchers and offer rewards or “bounties” for any found bugs or vulnerabilities. As Google states in the program description, “The goal of the program is to identify and mitigate vulnerabilities in apps on Google Play, and keep Android users, developers and the Google Play ecosystem safe.”9. By following the guidelines set up by Google and the individual app develop- ers it is possible to responsibly disclose vulnerabilities to the companies while staying inside the legal boundaries of security research and ethical hacking.
Google paid an estimated 800,000 USD in rewards to Google Play Store se- curity researchers in 201910.
2.6 Related Works
There are many relevant projects that have analyzed security and privacy con- cerns in dating apps. Although the most popular dating apps generally follow some semblance of security standard it is clear that many of them are lacking in some way, often resulting in malicious actors gaining access to or produc- ing fine grain personal information [2]. In Analysis of privacy and security Patsakis and his team made a list of some of the biggest dating apps and sum- marized potential areas lacking in security for each app [2]. This often came in the form of pictures being sent over HTTP, URLs containing personal infor- mation or data such as location not being obfuscated. Qin, et al., showed, in the paper Playing Hide and Seek with Mobile Dating Applications, a way of gaining location data from obfuscated location data [1]. By analyzing the ap- proximate location returned from a profile and triangulating the data returned by spoofing the adversaries location he proved that even obfuscated data can
7https://www.youtube.com/watch?reload=9&v=e9PdX-NmCSg&feature=youtu.be
8https://team-sik.org/trent_portfolio/in-security-of-tracking-apps/
9https://www.google.com/about/appsecurity/play-rewards/
10https://www.cnet.com/news/google-paid-out-6-5m-in-bug-bounties-over-2019/
be used to gain personal information. Shetty, et al., showed that many pop- ular dating apps were susceptible to Man-in-the-Middle (MITM) attacks [8].
Although it has become more trivial that most popular dating apps implement secure communication techniques such as Secure Sockets Layer and Trans- port Layer Security (SSL/TLS) they can still be implemented insufficiently.
Shetty’s work presented an adversary model that gave a systematic, interdis- ciplinary approach to assessing the security of dating apps. The work’s con- clusions include data showing that five out of seven of the analyzed apps were seen to have, in some way, violated data confidentiality, integrity and avail- ability. The authors believed that the lacking security was due to a lack of concern for advanced security mechanisms.
These previous works related to privacy and security in mobile dating apps all have results proving that there was much work to be done in this area at the time of their writing [1][2][8]. This thesis can complement the results of those papers with data from the present day and through similar, interdisciplinary methods.
As threat modeling is seen as a preferable method of comprehensive security analysis for comprehensive results previous works regarding this are relevant to this paper. A systematic literature review was conducted by Xiong and Lagerström on the subject threat modeling and its definition in the field of cy- ber security [3]. Among their findings they described how the field is diverse and the wide range of research is lacking in a common ground. They also con- cluded that threat modeling is often more effective when automated as this is in general less error prone. As shown in a systematic review by Kong, et al., there are many different ways to classify automated testing of Android appli- cations but few ways to benchmark the different methods, making it difficult to choose the proper class of testing for a given situation [9]. The literature review by Xiong and Lagerström demonstrates how threat modeling can be used for security analysis at a larger scale but it also shows how threat model- ing can be used in penetration testing processes. That is, how it can help ethical hackers and security specialists to systematically organize their efforts to help ensure that they identify vulnerabilities efficiently and effectively. The value that can be extracted from threat modeling extends over a variety of situations and industries, one being that of mobile dating applications.
With this in mind it was chosen to conduct this project with a more qualita- tive approach, as the major limiting factor for this bachelor thesis is time. A qualitative security assessment was done by Seifert and Reza [10] similar to this project but instead focusing on Cyber-Physical systems architectures in
12 CHAPTER 2. BACKGROUND AND RELATED WORKS
the healthcare industry. Threats were identified using the STRIDE method and then rated using the DREAD risk rating system developed by Microsoft.
Sifert and Reza’s project gave comprehensive results in regards to security vul- nerabilities, with a more qualitative, hands-on approach. Related to STRIDE and DREAD, several thesis projects conducted at KTH under supervision of Johnson and Lagerström use these methods for threat modeling as a qualitative approach for penetration testing of IoT devices [11][12].
In this chapter core concepts were introduced such as threat modeling and its relevance for risk assessment, what STRIDE and DREAD are, the dating apps that will be analyzed and the importance of publishing security concerns in a public paper. In the next chapter the methods chosen and implemented for security assessment in this project will be explained and motivated.
Method
The methodology used in this project is based on a literature study and a qual- itative assessment using threat modeling and a risk scoring system. The threat model is then used as a structured foundation when testing for vulnerabilities in the target apps. In order for results to be comprehensive in the limitations of this work, threats will be rated and prioritized using a risk analysis scoring system. The threats with the overall highest risk severity will be given a higher priority for validation through penetration testing. As highlighted in the study by Xiong and Lagerström, threat modeling is a method used to secure the soft- ware development process but can also be used to analyze already established systems [3]. The STRIDE method will be used for finding threats as this has proven successful for other similar works and is a known industry standard [10][11][12][13]. Similarly, the DREAD risk rating tool developed by Mi- crosoft1is chosen for its comprehensive scoring system and proven success in previous works [10][11][12].
3.1 Threat Model
The created threat model is heavily based on Shostack’s four step framework [14]. The four steps correspond to the four following questions:
1. What has been built?
2. What are the threats?
1https://docs.microsoft.com/en-us/windows-hardware/drivers/driversecurity/threat- modeling-for-drivers
13
14 CHAPTER 3. METHOD
3. What mitigations are expected for the found threats?
4. Is the developed threat model comprehensive enough?
The threat model identifies a general approach, describes the definition of the dating apps, defines the confines of what will be analyzed, establishes what can go wrong in these apps using STRIDE and lastly goes through some of the potential attack surfaces that need to be analyzed. Using this well defined systematic approach to reverse engineer and analyze the app it is possible to compare threat assessment in the different apps to a higher degree.
3.1.1 Identifying Assets
The apps chosen for the project have a similar user experience and the same general architecture. Figure 3.1 shows a simplified overview of the most cru- cial security assets for these two dating apps.
App #1
The first app was chosen because it is considered one of the most used dating apps on the market and hopefully relies on well thought out security regarding personal information and data. The app allows “matches” (two different users
“liking” each other’s profiles) and chatting with other people. The app also allows paid premium features such as looking at other peoples profiles with- out notifications being sent and seeing which people wanted to match with you.
App #2
The second app looked at is a worst case scenario. It has over 1000 downloads and was specifically picked since it might be a good source for demonstrating lack of security as it seems to have a smaller budget. It is much like any dating app as it includes the possibility to “match” and chat with other users and has paid premium features which in this case includes the possibility to look at other peoples profiles without notifications being sent to the person being observed.
API Services
Both of the target apps interact with some backend service, allowing for scal- ability and connecting users across heterogeneous platforms.
Figure 3.1: Overview of communications architecture in dating apps.
Network Communication
The connection to any backend service is usually established using HTTP/HTTPS with some kind of “RESTful”2 implementation. Data like login credentials, authorization tokens, user messages and other profile information is transmit- ted over this connection.
Database
Both of the apps’ backend services, in their turn, interact with a database to persist user information, user credentials, logs and other important data. As mentioned previously, Figure 3.1 shows a simplified overview of these as- sets.
3.1.2 Finding Threats
The STRIDE method was used for identifying threats in this threat model.
Described here are the possible threats that exist for the examined dating apps.
They are mentioned in the order of the STRIDE method’s categories.
Spoofing
Spoofing in one of these dating apps would mean data being accessed by an unauthorized third party by pretending to be a legitimate app user. This would
2RESTful APIs: https://restfulapi.net/
16 CHAPTER 3. METHOD
be achieved through an adversary using other users’ access tokens, finding their login credentials in an insecure database or by general access to an in- secure database. Spoofing could also mean uploading a file that is masked as something it is not. In the case of both apps it is possible to upload files to a chat. If this file could somehow be carrying a malicious payload it could be possible to execute code remotely, either on an application server or another client application. As both of the apps communicate with some API using the HTTP protocol, the client itself could be spoofed and requests could be sent from any HTTP client.
Tampering
One likely and intriguing threat for tampering in these dating apps would be gaining access to confidential files and data on the server. This would be achieved through poor encryption of server requests or lacking server-side au- thorization rules. An attacker could change information in requests to create, read or alter data they are not meant to have access to. This could also be de- scribed as tampering with server requests Tampering on the client side could also be achieved by fuzzing, in which unnatural values would be sent into fields which might not be validated correctly.
Repudiation
In dating apps there are often premium features that can be purchased. The main threat here would be an attacker “purchasing” said features without mak- ing a payment, by denying that the purchase was made. Getting in-app credits that can be used to purchase premium features could also be exploited through repudiation. These “currencies” are often stored in the app’s own database and this might lead to an attacker being able to gain currency while denying any purchase was made. Accessing open profile pictures without it being as- sociated with a profile is another form of repudiation. Although similar effects could be achieved with say a robot pretending to be a fake user, getting this data without a legal person claiming access to it would still be disallowed by most dating app companies and should therefore be prevented.
Information Disclosure
The main threat under information disclosure is the public disclosure of users’
personal information. If this data does not have the user’s consent to be shared
publicly it could fall under GDPR violations and therefore be illegal3. Data and messages from private chats are assumed by users to be private with only the sender and recipient being authorized to see them. An attacker could try to gain access to information like text messages and other multimedia being sent between two users.
Denial of Service
For dating apps denial of service attacks would mean targeting the shared back- end services, but as stated previously in the limitations of this project, denial of service threats will not be tested. Though it is difficult to analyze this without testing, it could be assumed that it is possible to target the backend services for the apps with some denial of service attack as these are usually difficult to mitigate and under prioritized.
Elevation of Privilege
The main avenues for elevation of privilege for these dating apps would be get- ting admin-level access to the backend service of the app or activating client- side premium features without it being authorized on the server.
The resulting threats found using the STRIDE method can be listed more sim- ply as follows:
1. Spoofing
(a) Spoofing user identity (b) File upload Spoofing (c) API Client spoofing 2. Tampering
(a) Tampering with API requests (b) Tampering with client input 3. Repudiation
(a) Denying in-app purchases
(b) Viewing profiles without an associated account
3GDPR: https://www.datainspektionen.se/other-lang/in-english/the-general-data- protection-regulation-gdpr/
18 CHAPTER 3. METHOD
4. Information Disclosure
(a) Public disclosure of personal user information (b) Disclosure of chat messages and other multimedia (c) Disclosure of user credentials
5. Denial of Service
(a) Denial of service to backend services 6. Elevation of Privilege
(a) Admin privileges on the backend (b) Client-side premium features
3.1.3 Risk Rating
Using Microsoft’s own example of a scoring of three levels in each category, we will be able to prioritize each threat using a scoring system of three levels per risk category. There are five risk categories each with their own letter in the mnemonic, D.R.E.A.D.
• Damage – how bad would an attack be?
• Reproducibility – how easy is it to reproduce the attack?
• Exploitability – how much work is it to launch the attack?
• Affected users – how many people will be impacted?
• Discoverability – how easy is it to discover the threat?4
Each DREAD risk category is rated a value from one to three. To create some general guidelines for each risk category the diagram in Figure 3.2 shows a description of each level for each category.
Risk and required prioritization of each scoring result can be evaluated in the following categories:
• 5-8 – Low overall risk score
• 9-12 – Medium overall risk score
4Microsoft DREAD: https://docs.microsoft.com/en-us/previous-versions/msp-n- p/ff648644(v=pandp.10)?redirectedfrom=MSDN
Rating Level
Risk Category 1 - Low 2 - Medium/High 3 - High/Critical
Damage Potential
Could leak some information not meant for public/non-users.
Could leak sensitive personal information.
Adversary gains control over much of the system.
Large breach of information confidentiality.
Reproducibility
Hard or impossible to reproduce, even with knowledge of the vulnerability.
Reproducible in similar scenarios. Requires some timing window or race
condition. Always reproducible.
Exploitability
Advanced setup and or tools required.
Some setup required such as decompiling the APK.
Little to no setup to exploit.
Affected Users
Very small number of affected users for example
one user and their match. A group of people affected. Most of the users affected.
Discoverability
Hard to discover and requires a lot of work and experience.
Discoverable by people of some experience.
Very small amount of knowledge and effort required.
Figure 3.2: DREAD Risk Rating Level Descriptions
• 13-15 – High overall risk score
In Figure 3.3 results from the DREAD risk rating performed are shown for each threat.
Damage Potential
Through the DREAD risk rating on these chosen dating apps some threat cate- gories scored higher in damage potential than others. Spoofing of files scored high since this could potentially lead to some malicious code being disguised as a normal file upload. Any category which might lead to sensitive infor- mation being disclosed was seen as having a high damage potential as this is clearly illegal as stipulated by GDPR. The threat of denial of service to the respective apps’ backend services also scored high on damage potential as, depending on the scale of such an attack, it could mean an adversary com- pletely shutting down all services leading to large financial loss for each of the apps. Admin privileges on the backend would indirectly mean that a lot of information could be accessed and or removed. It would also mean that dan- gerous malware or spyware could be installed, meaning an adversary gaining full control over the system.
Reproducibility
Any threats related to API requests are seen as highly reproducible and have therefore scored highly for this risk in DREAD. If the threat is exploited simply by editing an HTTP request to a server this is seen as reproducible.
20 CHAPTER 3. METHOD
Risk Threat
Damage
Potential Reproducibility Exploitability
Affected
Users Discoverability Total
1.a 2 3 2 3 1 11
1.b 3 2 1 3 1 10
1.c 1 2 2 1 2 8
2.a 2 3 2 3 3 13
2.b 2 1 1 2 1 7
3.a 1 1 1 1 1 5
3.b 1 3 2 2 2 10
4.a 3 2 2 3 1 11
4.b 3 3 2 3 2 13
4.c 3 3 2 2 1 11
5.a 3 1 1 3 3 11
6.a 3 1 1 1 1 7
6.b 1 3 3 1 2 10
Figure 3.3: DREAD Rating Results Exploitability
As almost all threats require some intermediate level setup, all threats are rel- atively similar in their rankings in this category. In general threats regarding changing some request parameters or changing client-side configuration are regarded as more exploitable.
Affected Users
Threats affecting most or all users are regarded as having a high score. Threats affecting a very small amount of users such as one or two users are regarded as having a low score.
Discoverability
Though this category heavily varies depending on implementation, it should be noted that HTTP traffic can be intercepted and if not encrypted, can be an- alyzed and tampered with. This would of course increase the score in discov- erability. Denial of Service attacks are regarded as more discoverable.
Throughout the scoring process discoverability was scored relatively low as the threats identified are regarded as having non-trivial exploits. As seen in the results from the DREAD scoring, the two highest scoring threats were 2.a, Tampering with API requests and 4.b, Disclosure of chat messages and other multimedia. To further summarize these results, it should be noted that threats regarding API communication and API user authentication and authorization
scored the highest in the DREAD system used. Threats regarding disclosure of personal information and data also scored at least medium in DREAD and are seen to be heavily linked to the underlying API services.
Chapter 4 Results
In the Method chapter a threat model and an associated risk ranking were pre- sented. These were used as guidelines for prioritizing vulnerabilities to test for. This chapter starts by breaking down the APK files for each app to see how they work in general and how they interact with their respective backend services. This will be followed by penetration testing of the highest ranking threats in the threat model developed in the method of this project. The high- est ranking threats, as seen in Figure 3.3 from the previous chapter, were 2.a (Tampering with API requests), 4.b (Disclosure of chat messages), and 1.a (Spoofing user identity).
4.1 Reverse Engineering the Apps
Static analysis was done by reverse engineering a downloaded APK file. The APK was downloaded through Androids APK API by using an online APK downloader1. Once downloaded the next step was to acquire the source code.
By utilizing one of the plethora of available tools for decompiling dex code (android byte code) it was possible to get SMALI files and decompiled Java code. SMALI is a human-readable descriptive representation of dex byte code.
This representation can be compiled to make the same APK file. Decompiled code does not however store variable names and is more complicated to parse and effectively edit. One tool used for this task is NinjaDroid2. This com- bines many of the available tools required to get important meta data, strings
1https://apk.support/apk-downloader
2NinjaDroid: https://github.com/rovellipaolo/NinjaDroid
22
and code from APK through the use of dex2jar3 and Apktool4. The tool is best described as it is on the NinjaDroids Github page, “NinjaDroid uses a modified version of the Androguard AXMLParser (by Anthony Desnos) to- gether with a series of other Python scripts (by Paolo Rovelli) based on aapt, keytool [...]”5. NinjaDroid allows access to the decompiled files (.dex), trans- lated jar file, APK info, digital certificate, All URLs and hard coded strings in the dex files, JSON and HTML report files and much more. Jadx6is a tool that takes the decompiling features of NinjaDroid a step further by also gen- erating a simulated version of Java source code for the app being decompiled.
This was used alongside NinjaDroid throughout the penetration testing phase.
The following command was used on a downloaded APK file to extract and decompile its contents:
python3 ninjadroid.py /path/to/your/package.apk \ --extract /output/path/
The file hierarchy of the decompiled APK file is as follows:
Contents/
AndroidManifest.xml apktool.yml
CERT.RSA classes/
resources/
sources/
classes2.dex classes.dex date.jar files.txt original/
res/
values/
strings.xml smali/
"smali code"
smali_classes2/
unknown/
3dex2jar: https://github.com/pxb1988/dex2jar
4Apktool: https://ibotpeaches.github.io/Apktool/
5NinjaDroid: https://github.com/rovellipaolo/NinjaDroid
6Jadx: https://github.com/skylot/jadx
24 CHAPTER 4. RESULTS
Android APKs have a unique file structure that must be taken into consider- ation when reverse engineering, as represented here (non-decompiled source):
APK contents
AndroidManifest.xml META-INF
Certificates Classes.dex lib/
assets/
The AndroidManifest.xml stores information about granted device permissions, existing Activities, Broadcast Receivers and Intent Filters used by Activities.
This can be used to see the general structure of the app. Reversing and analyz- ing each of these apps will hopefully show a difference in security and display how security can or should not be thought of.
4.1.1 Reverse Engineering App #2
Jadx and NinjaDroid were used to reverse engineer the APK-file for App #2.
Jadx was used to unpack the APK-file and convert the dex code to SMALI and eventually generate Java source code. On App #2 it was possible to deob- fuscate much of the code. The converted code in App #2 could then be ana- lyzed to view app logic such as, how API requests are handled, what backend services are used and how different activities communicate with each other.
Knowing which URLs and services app #2 were using meant moving on to analyze its HTTP packets through use of an Android emulator was a natural next step.
4.1.2 Reverse Engineering App #1
Like app #2, it was possible to extract the contents of App #1 using Jadx and to generate Java source code from its contents. In the Java package “com.<app-
#1>.android” there was a package named “dexguardutils”, implying that Dex- Guard was implemented in the app’s build process. DexGuard is a tool that provides code obfuscation of classes, fields and methods in Java, Kotlin or other cross-platform languages for Android development7. As suspected, most
7DexGuard: https://www.guardsquare.com/en/products/dexguard
of the code in App #1 had been obfuscated. Upon further inspection in “An- droidManifest.xml” it was found that most of the Android activity classes had obfuscated names and classes found in the decompiled source code had ob- fuscated contents. DexGuard also provides runtime protection, in the form of detection of debugging tools and emulators, meaning that this app could not be installed on an Android emulator in the same way App #2 was.
4.2 Tampering with API Requests
Both of the apps have backend services which require HTTP/HTTPS requests to get a hold of relevant persisted data and orchestrate interaction between clients. When developing this kind of backend controller, oversights can be made in what might be accessed and how it is accessed which may lead to insecure data and security vulnerabilities. To be more specific, one of the most interesting facets here is how server-side authorization is handled. As dating apps heavily rely on user-to-user interactions it is assumed that these apps would use encrypted traffic by using HTTP with Transport Layer Secu- rity (TLS). HTTPS is in itself not a sufficient mitigation mechanism against request tampering but does pave the way for implementing some kind of dig- ital signature scheme which in its turn can be used against request tampering.
With that said, TLS is better than nothing and a strong tool for mitigation against tampering with API requests. Encrypted data is in practice far more difficult to blindly tamper with in order to somehow get unwanted behavior from a service, especially within the time limitations of this project.
4.2.1 Tampering with API Requests in App #2
After decompiling App #2 using NinjaDroid all static strings can be found in a single XML document under the directory path “resources/values/strings.xml”.
Here all the URLs for managing chats, matches and other functionality like premium features were found. These URLs did not communicate over TLS and therefore presented a possibility for weakness in the app. To inspect the behav- ior of communication with the app’s backend service it was possible to start the app in an Android device emulator and intercept communication through a proxy. The command-line tool adb was used to install an apk to an emulated device and Burp Suite was used as a proxy8. By intercepting requests from the app to the backend service it was possible to view all parameters, tokens,
8Burp Suite: https://portswigger.net/burp
26 CHAPTER 4. RESULTS
Figure 4.1: Example of HTTP request interception in Burp Suite proxy.
user-IDs in clear-text. This is shown in an example in Figure 4.1. As threat 4.b was one of the most critical threats in the developed threat model, this was also explored in tampering. It was possible in App #2 to change parameters in API requests to gain access to confidential information. The most confidential information disclosed is in this case one-to-one chats between users, which is described more in detail in section 4.3. Also explored by tampering with requests was the threat of spoofing another user in a request to the server. This is further described in section 4.4.
4.2.2 Tampering with API Requests in App #1
In order to use a proxy for capturing packets sent from the app to backend ser- vices an emulated device is required, as in the case of App #2 which was not possible as tools from DexGuard were implemented for App #1. To circum- vent the protection of DexGuard for App #1 the analyzing tools needed to be used from an outside source. A man-in-the-middle attack was attempted by setting up a public access point for an App #1 host device to connect to and communicate via. Traffic over this connection could then be analyzed using Wireshark9. From here there are different alternatives to sniff traffic from an- other device on an open connection. It is possible to set up a network interface in monitor mode and intercept all traffic over the connection or target a spe- cific device with an ARP spoofing attack to trick the target device and Internet gateway respectively that a specific device should be the recipient of all sent data. An ARP spoofing attack was chosen in this particular case to capture traffic to and from a specific Android device running App #1. Upon capturing some traffic from actions and switching between all the different activities in the app it could quickly be concluded that all traffic appeared to be encrypted using TLS. This is in contradiction to Patsakis findings in Analysis of Privacy
9Wireshark: https://www.wireshark.org/
and Security Exposure in Mobile Dating Applications [2]. However this anal- ysis is done five years later so improvements in security are to be expected. In practice it would not be possible to find any API tampering exploits for this app in this project due to this security mitigation.
4.3 Disclosure of Chat Messages
One of the core features of dating apps is a chat of some kind. Dating app users are often given the chance to chat with other users they match with. Of course, it is expected that this chat remains a private one-to-one chat between the matched users. HTTPS would here be an obvious mitigation mechanism, but it is also important to have a robust system for server-side user authoriza- tion in place.
4.3.1 Disclosure of Chat Messages in App #2
In App #2 it was possible to alter the request for fetching a chat conversation at the endpoint “/api/v2/method/chat.get.inc.php”. By setting the HTTP re- quest parameter, chatId to any valid ID (an integer) representing an existing conversation between two users, the full conversation between these users is returned in the HTTP response. As a logged in user, i.e. correct values as- signed to userId and accessToken, it was possible to gain access to all chat text messages and images regardless if this user had previously been a part of the conversation or not. An example request could appear as follows:
curl ’http://****.com/****/chat.php’ \ -X POST \
-d chatFromUserId=4021 \ -d accountId=4021 \
-d chatToUserId=3351 \ -d chatId=5 \
-d accessToken=’****48d’
This request (using the command-line tool Curl) received an HTTP response body fully presented in Appendix A.1. The response body lists all messages and images sent in the conversation between two users with the chat ID 5. A script was made as a proof of concept to access all messages available from private chat conversations (see Appendix A.2). One-on-one chats between
28 CHAPTER 4. RESULTS
dating app users are normally expected to be private but in this instance there was no authorization of the user requesting a chat leaving the chats almost completely public on the Internet.
4.3.2 Disclosure of Chat Messages in App #1
For chats in App #1 all traffic was sent using HTTPS. All backend service re- quests were made over HTTPS and no endpoint URLs were found in the source for the app due to obfuscation from DexGuard. As a partial workaround it was possible to see some of the chat functionality in the web implementation of the app. In the web app it was possible to see for example, how chat messages are fetched and updated, but access tokens for these were securely encrypted and HTTPS and digital signatures stopped any attempts of intercepting and alter- ing requests.
4.4 Spoofing User Identity
It is important that users feel safe to expose their own identity in dating apps.
Users’ real identities are strongly linked to their dating profiles as they are encouraged to share a large amount of information about themselves in order to not be mistaken for a bot and to appeal to other users. If it is possible to spoof an access token or gain access to a user’s account in some way this can be used maliciously to steal their identity or access confidential information stored in the app.
4.4.1 Spoofing User Identity in App #2
In App #2 user identity was handled using a permanent user ID and an access token generated at login. These two parameters were then sent in all HTTP requests to the backend server. The two parameters however are not used to authorize access to certain parts of the app rather the mere existence of these parameters is only used to check whether a user is allowed to make any requests at all (like a “isLoggedIn” flag). This means that if a user can get a hold of the user ID for another user they can simply request all friends and chat messages for this user without any actual token required. All that is needed for this to be exploited is to sniff traffic of the targeted user or simply enumerate over all app users and their IDs in requests with a script similar to the proof-of-concept script used for testing of threat 4.b
4.4.2 Spoofing User Identity in App #1
To use App #1 and view other profiles a user is at signup required to supply a valid profile image followed by a second verification image. In this verifi- cation image, the user is required to take a new image (not publicly posted) making some specific hand gesture to verify that they are the same person in the profile image. The profile image appears to also be run through some im- age search engine, like Google10, to verify that this image is an original or at least, used by the same person in other social media. To add to this, as the app had implemented TLS encryption for communication with backend services and obfuscated source code it was not possible to find information regarding implementation of access tokens and server-side authorization in regards to spoofing user identity.
10https://images.google.com/
Chapter 5 Discussion
The results from the previous chapter imply that security can be easily over- looked and in such cases apps risk disclosing data that is meant to be kept private. In order to value user privacy and personal integrity in the very per- sonal interaction that is online dating it is important to prioritize security in app development. An app that values user privacy will also arguably be more trusted by users.
According to Xiong and Lagerström, threat modeling with a more quantita- tive, automated assessment of security proved more successful in general [3].
The goal of this project was to try to comprehensively assess the security of Android dating apps but doing so at a higher level of abstraction and utiliz- ing automated assessment tools might challenge the given time constraints.
Instead, using a more qualitative approach to threat modeling was used in or- der to at a lower level, approach the targets as security researchers and have a better chance of reaching more comprehensive results at this level of research.
Also, other tools exist for risk rating such as CVSS1and the OWASP Risk Rat- ing Methodology2but DREAD was chosen as there are many previous works that have successfully used DREAD. If this project were to be repeated, taking other risk assessment methods into consideration and looking at other intrigu- ing gateways for security vulnerabilities would be a good first step. Analyzing the two different apps in even more detail side by side would also prove useful as it might give even more insight as to what exactly the differences are for such a large security difference to exist between the two apps.
1CVSS: https://nvd.nist.gov/vuln-metrics/cvss
2OWASP Risk Rating: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology
30
5.1 Interpretations
The initial literary study along with threat analysis and penetration testing would imply that security is indeed lacking in areas where it might be con- sidered vital for dating apps. We also see that threat modeling while best done manually is very time consuming, this is in accordance with Xiong and Lager- ströms findings [3]. It could also be argued that the existence of a bug bounty program would incentivize the apps developers to take security more seriously.
This was demonstrated as App #1 was more secure and had a bug bounty pro- gram. It is also important to note that a bug bounty program would most likely result in the easier vulnerabilities being resolved relatively quickly. The secu- rity of dating apps seems to have improved when compared to previous studies in this area of security research.
5.2 Implications
Sharing information regarding security in dating apps might bring more peo- ple to the realization that even apps which one would think rely on secure communication can in fact be very lacking. Those with malicious intent could easily take advantage of insecure connections. As a worst case scenario, in countries where homosexuality or other sexual preferences can be punished by law, disclosing this information could be severe for a targeted user. Also implied by the results is the gross invasion of privacy that can be exploited when gaining access to private chat messages.
5.3 Limitations
This work aimed to analyze more than one app to provide a comparison of what security looks like when taken more seriously and when it is overlooked.
While a broader, more quantitative study could provide a higher degree of confidence in results, it could be argued that the limitations faced in this study would limit the comprehensiveness in the security analysis of a more quanti- tative work. Also, assessing a larger amount of apps would very likely provide more intriguing results with more security flaws, but analyzing apps this way is time consuming and with the project being restricted to about ten weeks, time has been a very limiting factor. Although most of the more popular apps seem to take security in consideration as a major part of development it seems that a lot of the smaller apps, like App #2 are lacking in this regard. App #1 was
32 CHAPTER 5. DISCUSSION
analyzed to the best of the participants abilities though as Xiong and Lager- ström recommended [3], automated methods of testing are a promising avenue that was underprioritized during this study due to time limitations. More time could also be put into deobfuscating code, though this is probably a project in and of its own. Although no vulnerabilities were found it is unlikely that App #1 is entirely secure. Also out of scope for this project was research- ing how App #1 handles positioning data. This was mostly overlooked due to the fact that App #2 does not appear to have implemented any form of geo- positioning.
5.4 Recommendations
As mentioned in limitations, one factor is the lack of quantity of apps tested.
A more in depth analysis of each threat in regards to a wider variety of apps could yield more vulnerabilities and present more results. It is however impor- tant to also reflect on what security mitigation techniques proved successful in preventing penetration testing attempts. The threat model created for these dating apps is not necessarily only usable for dating apps and could be used on similar apps that gather a lot of personal data and use one on one commu- nication. Examples of similar apps would be online doctor or social media apps. As mentioned before, mobile apps and especially dating apps have the ability to gather a large amount of personal data. Identifying what that data is and how the vulnerable data could be maliciously used should be done as a preventative measure and to illustrate the dangers of insecure communica- tions and storage. Developers should further understand the consequences of underprioritized security and some best practices for secure development are important to establish.
A common ground and baseline approach for how to handle privacy and se- curity in mobile dating apps is crucial for this market to be sustainable. From an ethical standpoint, personal data is not to be taken lightly. Not only can it have large economical impact on companies with large userbases but also have large social consequences for users if personal data is leaked, especially in the case of leaks of login credentials such as in the LinkedIn breach in 20123. Upon such a leak many passwords are directly linked to email addresses and can often be used to access accounts on other platforms. It was decided to not disclose the real names of the analyzed apps as in the case of App #2 many
3LinkedIn Breach: https://fortune.com/2016/05/18/linkedin-data-breach-email- password/
critical threats to user privacy were found. An ethical choice to keep these apps names hidden was made in order to protect the privacy of the app’s users upon publishing this work. As this project has had to meet certain criteria, one aspect that has not been touched on is the environmental effect of this project.
Chapter 6
Conclusions
The main goal of this project was to comprehensively assess the security of two Android dating apps. Through penetration testing based on a threat model, vulnerabilities could be identified and later communicated to the app develop- ers, but also secure parts of the apps were identified and evaluated. Threat modeling is showing up more and more in app development as the impor- tance of secure data continues to grow. There is however a lack of common ground for how this should be implemented and therefore at the moment must be adapted to the situation at hand. It is however clear that threat modeling in- deed has its use and can be very useful when estimating threats and assessing potential vulnerabilities whether the process is automated or made on a per project basis.
For dating apps it is clearly important to have secure communications between users and robust server side authorization, as opposed to the implementations of these aspects in App #2. Simple security implementations and very basic measures can be taken to substantially decrease risks of threats being found and exploited. App #1 is proven to have far more dedication to security with simple mitigations such as TLS implemented for communication and more complicated solutions in the form of code obfuscation with DexGuard and scrambled image URLs. The protocols and tools used by App #1 was enough to hinder the participants of this report from finding any security risks. The fact that App #1 has set in place a bug bounty program for hackers and secu- rity researchers to disclose their findings directly to the developers has likely had a positive effect on the overall security of the app. For continued work in this field, it would be interesting to see more work done using automated
34
approaches to validating identified threats. It could be argued from the results of this paper that a more automated approach could yield results with even a higher quantity of targeted apps.
