THE PENNSYLVANIA STATE UNIVERSITY SCHREYER HONORS COLLEGE

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

ANDROID LOCATION PERMISSIONS AND HOW THEY AFFECT THE PRIVACY OF USERS

DOVILE DROZDOVAITE Fall 2020

A thesis submitted in partial fulfillment of the requirements for a baccalaureate degree in Computer Engineering with honors in Computer Engineering

Reviewed and approved* by the following:

Trent Jaeger Professor of Computer Science & Engineering Thesis Supervisor

John Sampson Assistant Professor of Computer Science & Engineering Honors Adviser

* Signatures are on file in the Schreyer Honors College.

Abstract

It is not rare for a user to be requested permissions while using an application. However, many users are still in the dark as to understanding what happens when they accept the permissions the application requests. In this paper, we will be highlighting Android vulnerabilities used to abuse permission assignment for continuous sensors involved with location based services (LBSs) and GPS location data. Such vulnerabilities include user privacy awareness, ride-hailing services (RHS), side-channel attacks, and white-box and black-box attacks. We will then evaluate these vulnerabilities on the application AbuserGPS, then review and propose different defense strategies to combat these vulnerabilities within the operating system such as the Location-Privacy Preserving Mechanisms (LPPMs), the ASM framework, and MATRIX.

i Table of Contents

List of Figures…………………………………………………………………………………...iii ​ Acknowledgements……………………………………………………………………………...iv ​

Chapter 1: Introduction………………………………………………………………………....1 ​ Chapter 2: Android Background……………………………………………………………….3 ​ Chapter 3: Android Vulnerabilities…………………………………………………………….8 ​ 3.1 Description of Vulnerabilities……………………………………………………….8 ​ 3.2 Vulnerability Study AbuserGPS……....………...………………………………...11 ​ Chapter 4: Evaluation………………………………………………………………………….15 ​ 4.1 Research on Android Security Mechanisms……….……………………….……..15 ​ 4.2 Proposed Security Mechanisms………………………………………...………….18 ​ 4.3 Candidate Security Experiments…………………………………………………..23 ​ 4.4 Android 11 Location Privacy……………………………………………………....24 ​ Chapter 5: Conclusion………………………………………………………………………….27 ​ References……………………………………………………………………………………….28 ​

ii

List of Figures

Figure 1: AOSP’s directory structure…………………………………………………………….3 ​ Figure 2: getLastKnownLocation function in LocationManger………………………………….5 ​ Figure 3: Establishing location permissions for AbuserGP………………………..……………11 ​ Figure 4: User’s point of view when accepting permission request from AbuserGPS ​ application………………………………………………………………………………………..12 Figure 5: onCreate function which continuously requests location……...……………………...13 ​ Figure 6: Location Data being received by AbuserGPS………………………………………...13 ​ Figure 7: Modified onLocationChanged function in AbuserGPS………………………………20 ​ Figure 8: Location data received by modified AbuserGPS……………………………………..20 ​ Figure 9: getLastKnownLocation in LocationManagerService………………………………....22 ​ Figure 10: Modified _getLastKnownLocationLocked in LocationManagerService…..………..22 ​

iii

Acknowledgments

I want to thank Professor Trent Jaeger for his guidance throughout the entire research process as well as the invaluable advice he provided. I would also like to thank Yu Tsung Lee, a graduate student at Penn State University, for sharing his knowledge on the involved concepts and providing valuable feedback. I would also like to thank both of my parents, Valerijus Drozdovas and Vilma Drozdovas, for supporting me mentally and financially throughout my education. Your inspiring words always motivated me to push myself harder. Finally, I would like to thank my friends who supported me throughout the process, ensuring that I always took care of myself throughout this process as well as shared knowledge on subjects that they were knowledgeable in. Thank you for keeping me sane throughout this whole process!

iv Chapter 1: Introduction

Android is currently the most popular operating system deployed for mobile devices. With over 2.5 billion monthly active Android devices [1], Android has become one of the most common interfaces for users to interact with digital services, specifically mobile applications. Most modern day Android devices are equipped with a variety of sophisticated sensors. Although these sensors improve the user’s interaction with mobile applications, they can also pose significant threats to the user’s privacy. As many applications value their security and privacy, Android as an OS needs to be able to ensure that privacy is ensured to both users as well as the developers. In order to ensure this privacy to all parties, Android is based on a multi-party consent model. In other words, “an action should only happen if all involved parties consent to it” [2]. ​ ​ The parties involved are the platform, user, and developer. If either the platform, user, or developer do not consent to a specific action, the action cannot be completed. This ensures that no application has permission to perform an operation that would impact other applications, the operating system, or the user. The developer must explicitly request in the application that they are requesting a specific permission in the Android Manifest file, or AndroidManifest.xml [3]. Then, the user will be prompted to either allow the permission request to follow through or deny the request. In this paper, we will mainly be focusing on location-based permissions. There are two different types of location access. The first type of location access is foreground location and the second type of location access is background location. Foreground location is used when an application only needs to share or receive location information only once or for some defined amount of time [4]. This feature is particularly useful for navigation applications or messaging applications, when a user may need to share their current location. Background location is used if an application is constantly sharing a location with other users or if the application is using the Geofencing API, which compares the user’s current location to the user’s proximity to specific locations [4]. This feature is particularly useful with a family location sharing application or for specific IoT applications. However, when requesting this

1 permission in the application’s manifest file, the developer will need to be specific on what kind of location permissions the developer is requesting. There are three different types of location permissions that may be deemed necessary to define in the application’s manifest file depending on the type of location access the application requires. These three types of location permissions are ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, and ACCESS_BACKGROUND_LOCATION. ACCESS_COARSE_LOCATION will provide the user’s location to within roughly a city block. ACCESS_FINE_LOCATION will provide a more accurate location compared to ACCESS_COARSE_LOCATION. One of these two types of location permissions must be defined when using foreground location, depending on the usage of the location data. However, if the application is intending to run using background location access, the developer will also need to request the ACCESS_BACKGROUND_PERMISSION permission within the application’s manifest file. Requesting this permission will not give you the location access though, you will still need to request either ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION [4]. In this paper, we will be highlighting Android vulnerabilities used to abuse permission assignment for continuous sensors, specifically in this case, sensors involved with location based services (LBSs) and GPS location data. We will also be providing a defense strategy that most Google Play Store applications will comply with, as well as reviewing other existing defense strategies, in order to prevent such vulnerabilities. There is a complementary security feature provided by Google called Google Play Protect (GPP), which is Google’s built-in malware protect for Android. This security feature is backed by Google’s machine learning algorithms, so it is continuously improving [5]. This feature is out of scope for this paper. However, it is important to point out that Google Play does require that new apps and app updates target a recent Android API level, allowing Android to remove APIs which can be abused or that have had security issues [6]. In the following, we will first define the AOSP (Android Open Source Project) structure as well as the Android security and privacy principles and the basis of the Android Security model. Then, we will review different Android vulnerabilities which are used to abuse permission assignment for continuous sensors. Finally, I will speak on a possible defense strategy as well by manipulating an application titled AbuserGPS.

2 Chapter 2: Android Background

Before we can introduce the Android vulnerabilities, it is important to understand the AOSP structure, Android’s privacy and security principles, as well as the Android security model.

AOSP Structure

The Android Open Source Project, or AOSP, is an “open source operating system for mobile devices and a corresponding open source project led by Google” [7]. This open source project allows developers to create a custom variant of the Android OS, while ensuring that devices are still meeting compatibility requirements and therefore ensuring a healthy and stable environment for users. However, when you first download the AOSP, you will find that there are multiple directories, as observed below in Figure 1. In this section, I will be going over the most important directories in the AOSP and which directory is most important when focusing on LBSs, in alphabetic order.

Fig. 1: AOSP’s directory structure

3

The first directory is known as Bionic [8]. Bionic is the C-runtime for Android and contains the source for the C runtime library, math, as well as other core runtime libraries. It is essentially Android’s small and custom C library for the Android platform. Next directory is Bootable [8], which contains the boot and startup related code. The next directory is Build [8], which is compiled of the build system implementation, as well as all of the core makefile templates. It also holds the envsetup.sh script, which sets up the environment for building Android devices. External is the directory which contains source code for all of the external open source projects (SQList, Freetype, webkit, etc.). One of the most important directories that will be mentioned from the AOSP structure correlating to LBSs is the Frameworks directory [8]. It is also essential to Android, as it contains the sources to the framework. This includes key services such as the System Server with the Package and Activity Managers. We will come back to this directory, as it contains important files such as LocationManger.java, LocationProvider.java, and LocationListener.java. The directory Out [8] is where build output is placed after running make on AOSP. There is also a directory titled Packages [8], which holds the source code for default applications such as contacts, browser, etc. Another important folder is the System [8] folder, for that holds the source code files for the core Android system. This includes the source code for the init process as well as the init.rc script which provides dynamic configuration for the platform. Finally, we have the tools directory, which simply contains various IDE tools [8]. In the Android OS, the PackageManager service, or PM, keeps track of Android Permissions. We can use this service to check if certain permissions have been granted to a given package. It makes sense that the PackageManager service would be located in the Frameworks folder in the AOSP directory, as the Frameworks directory also contains interesting services such as the LocationManger, MediaRecorder, ActivityManager, WindowManager, as well as the InputManager. However, the one we will primarily focus on in the AOSP structure is the LocationManager.java.

4

Fig. 2: getLastKnownLocation function in LocationManager

Within LocationManger.java, there is a function known getLastKnownLocation. The purpose of this function is to return the last known location for the parameter provider, as can be observed in Figure 2. This function is essential in allowing Android mobile devices to obtain GPS information in an application. We will see this function in action in the AbuserGPS application.

Android’s Privacy and Security Principles

Android has assumed a few basic privacy and security principles which can be considered a contract between multiple parties: “Actors control access to the data they create” [2]. Any actor that creates a data item ​ should be given control over how this specific data item is represented. When we say this, we mean the technical form of controlling the data item. This does not mean that legally the actor can imply ownership on data. “Consent is informed and meaningful” [2]. Actors that consent to any action must be ​ aware of what the action is and must have a way to allow or deny consent of said action. Although this may be viewed from the users’ perspective, it is also essential that the developers are considered in this principle. That said, the way that this principle is enforced will vary depending on if we are looking at the user or developer. Consent decision should be enforced instead of self-policed. “Safe by design/default” [2]. Default uses of components or services on an operating ​ ​ system should always protect security and privacy assumptions, even at the cost of some use

5 cases. Although there is no overall solution to make a system safe by design, this is a guideline principle for new and already existing interfaces. “Defense in depth” [2]. A security system is not sufficient enough if an attacker can ​ accomplish their intended goals without having to bypass the security model of the operating system. Therefore, the primary goal of any security system should be to enforce its security model. In terms of the Android OS, this means that if a single assumption is violated or a single implementation bug is found, the approach should not immediately fail, even if the mobile device is not up to date. The goal in this is to make vulnerabilities difficult for the attacker to exploit or force the attacker to need more vulnerabilities in the operating system in order to accomplish their goals.

Android Security Model

Android’s security and privacy team released a paper titled The Android Platform ​ Security Model. Specifically they discuss the security model which has primarily influenced the ​ Android platform’s security design:

1. “Three party consent” [2]. No action should be allowed to go through without the ​ agreement of all three main parties: the user, platform, and developer. If one party does not consent to an action, the action should be terminated. Since files are the main focus of objects to protect, the default control on these files will depend on their location as well as the party who created these files: ● Data in shared storage is controlled by users. ● Data in private application directories and application virtual address space is controlled by applications. ● Data located in special system locations are controlled by the platform. However, an important piece of information to point out is that even if one party has most of the control over a data item, that one party still may only act on the data item if the other two parties consent to the action. 2. “Open ecosystem access” [2]. Both the users and developers have access to an open ecosystem and therefore are not limited to a specific application store. This allows for an

6 app-to-app communication to exist and be explicitly supported. Therefore, instead of the platform creating platform APIs for every workflow, developers are free to create their own APIs for other applications. 3. “Security is a compatibility requirement” [2]. The security model is part of the Android ​ specification, which means it must follow the Compatibility Definition Document (CDD) [9]. This is enforced by the Compatibility (CTS), Vendor (VTS), and other tests. If a device does not conform to CDD or pass the CTS, the device cannot be considered Android. 4. “Factory reset restores the device to a safe state” [2]. If an attacker is able to bypass the security model and achieve their intended goal, there must be a way to return the device to its original state and wipe/reformat the writable data partitions. Therefore, the factory reset will return the Android device to a state without downgrading the version of the operating system and leaving it with a state that only depends on system code. 5. “Applications are security principals” [2]. In the context of the logged-in user account, the main difference between the traditional OS and the Android OS is that Android applications are not fully authorized agents for user actions.

Overall, although it may seem that the Android security model is restricting users compared to other traditional operating systems, this actually aids the user as the user cannot be tricked into giving access to data controlled by other applications.

7 Chapter 3: Android Vulnerabilities

Researchers have spent a long time focusing on privacy concerns based on location based attacks. This is reflected in the majority of Americans, with 81% of adults feeling as if they have little/no control over the data companies collect [10]. Americans may feel this way due to location data being used in the secondary location-data market for the purpose of targeted advertising and marketing, otherwise known as “surveillance capitalism”. There have also been cases where location data has been misused by applications for other purposes than intended. In this chapter, we will be reviewing Android vulnerabilities and different location-based attacks based on these vulnerabilities.

3.1 Description of Vulnerabilities

User Privacy Awareness

Before we can consider other vulnerabilities in the Android operating system, we must consider how aware Android users are of various malicious attacks. A study done by Mohammed M. Alana from the Khawarizmi International College proved that users lack awareness in regards to the privacy of their data. Only 35.71% of Android users in the study claimed that they read all the permissions required by all the applications they install, while 11.42% of respondents never read the permissions, with the rest of the respondents falling in the middle [11]. This is very dangerous behavior which unfortunately we can see users falling into. When users do not bother to read about all the permissions they install, they may be allowing malicious software to gain access to private information.

Sensitive Data Leakage in RHS

Over the past few years, Ride-Hailing Services (RHS) have become more popular as a means of transportation for millions of users using Android as well as iOS. However, RHSes

8 usually collect a significant amount of data from drivers and riders, such as their GPS location, car plates, credit card information, and other important personal information. The functionality of a RHS application requires riders to open the application, allow the application to track the rider’s location, as well as provide payment information and other private information of the rider. From there, the rider may request a ride from the driver. If the driver accepts said request, the user will receive information about the driver, such as their location, driver’s license, and other personal information of the driver. However, Uber, a RHS application, has come under fire for its collection of location data. This is not the first time Uber has gotten in trouble for its collection of location data. In 2017, the FTC pursued a UDAP enforcement action against Uber for its collection of location data, even when the application was not being used and for the use of this location data [12]. The FTC called this continuous geolocation tracking of all riders and drivers the “God View” feature of the Uber application software. This feature also allowed employees access to this tracking information, even if users were not using the Uber application at the time [13]. Uber then publicized that they were taking action to limit and monitor employee access to location data, but eventually this was abandoned by Uber [12]. However, this does not mean that Uber or other RHSes are doing enough to ensure riders and drivers’ location data remains private. Reviewing RHS web APIs, it has been determined that the API implementing the nearby cars feature as well as containing private information about the users is poorly protected [14]. Therefore, by using data acquisition, data aggregation, and data analysis, researchers have been able to track drivers’ daily routines, discover drivers' employment status as well as their preference to a RHS, and obtain business information from the RHS about a specific location [14]. Overall, we can observe a multitude of location permission vulnerabilities with the source being RHS software applications.

Side-Channel Attacks

Just like humans can give away secrets involuntarily through their body language, computers can give away secrets through physical components of the device. A side channel attack is a type of attack in which the attacker collects information on how a device reacts to certain operations and then uses that information to reverse engineer the device’s cryptography

9 system [20]. This can also be applied to the sensors involved in tracking locations, such as the gyroscope, accelerometer, and magnetometer. An example of this type of an attack is a user downloading a seemingly harmless application. During this time, the application collects sensor data from the gyroscope, accelerometer, and magnetometer while providing the victim with another service to disguise the collection of this data. However, the attack then takes place when the user begins to drive. From there, the sensor data is recorded and uploaded to a server which can then derive information up to the route that was taken [21]. Researchers were able to model this exact problem, which indicates that in most cities, a significant number of users are vulnerable to their location being tracked by innocently-disguised applications [21]. This can be extremely dangerous and leave Android in a vulnerable position in which users are left unaware of malicious applications gaining knowledge on their location data.

White-Box and Black-Box Attacks

Many applications publicly track and store their users’ locations. Many companies claim that they use the location data to help advertisers and that users remain anonymous in the use of this data. However, the way in which location data is used may not be as private as users are led to believe. The New York Times found that at least 75 companies receive anonymous, precise location data from users who allow location permissions for their applications and multiple of these companies claim to track up to 200 million mobile devices in the United States [23]. From there, if anyone has access to the raw location data, they could use this information to perform a white-box or black-box attack and determine sensitive information, such as the users’ identity, their home, as well as other regular behaviors they partake in [15, 23]. In both white-box and black-box attacks, the adversary has access to the users’ location data [15]. However, only in white-box attacks the adversary also has knowledge of the protection mechanisms [15]. Without any defenses to avoid these types of attacks, this data can be used by the adversary to track the behavior of the user, which can then track stationary data points and therefore find out sensitive information of the user such as their home and work location [15]. Therefore, allowing applications to track and store data indefinitely can lead to users’ privacy becoming compromised.

10

3.2 Vulnerability Study AbuserGPS

In the previous section, we defined multiple vulnerabilities found within the Android operating system. In this section, we will observe an example of some of these vulnerabilities in an application titled AbuserGPS. The application AbuserGPS shows the user an UI in which it appears to be seemingly harmless. From there, the application will request location permissions from the user and if the user consents to the request, the application will have the ability to abuse these location permissions without the user knowing. This application is run on Android 9.0, but since the majority of users still use Android 9.0 operation or older versions [25], this version will still be relevant to the majority of Android users. In the AbuserGPS application, we establish the permissions that will be required within the application’s manifest file as seen in Figure 3 below, specifically ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, and ACCESS_BACKGROUND_LOCATION. From there, we must run the initialization process, in which the user opens the AbuserGPS application. Once the user presses the button “Foreground Location”, the application must request the user’s permission to gain access to the mobile device’s location, as seen in Figure 4 below. If the user consents to AbuserGPS’s request to gain location data, one will see data as provided in Figure 6.

Fig. 3: Establishing location permissions for AbuserGPS

11

Fig. 4: User’s point of view when accepting permission request from AbuserGPS application

Once the AbuserGPS application gains access to the location data, the application will continuously pull location data in the background location access, as well as access fine location in the foreground location access by using the function onCreate, as seen in Figure 5. As we can see in Figure 6, once the location data has been set, we can obtain the GPS location, which contains the longitude as well as the latitude of the mobile device. However, there are a few vulnerabilities in the AbuserGPS application which an attacker may be able to take advantage of.

12

Fig. 5: onCreate function which continuously requests location

Fig. 6: Location Data being received by AbuserGPS

When AbuserGPS requests the user’s consent to access location data, the user is not made aware what type of location access the application is requesting. This can lead to applications appearing to only use location data when said application is in use, but actually be running when the app is not visible on the user’s screen, such as the privacy scandal involving Uber [12, 13, 14]. When applications are not held accountable to informing users on what they are consenting to, this may lead to attackers abusing user’s permissions.

13 Another vulnerability which can be observed in AbuserGPS is the lack of a defined amount of time for the location access to be running for. Although there are limitations to how often the background location can access data [28], these types of limitations do not relate to the foreground location access. This can lead to an application reading data for extensive amounts of time at a constant rate. If an application is able to read multiple location data points it provides an opportunity for attackers to implement either black-box or white-box attacks on the user [15, 23]. Allowing applications to constantly read location may lead to users being at risk of attackers who intended to pinpoint certain location data such as the user’s home or work. One final vulnerability worth mentioning in the Android 9.0 operating system is the lack of a permissions auto-reset on applications which use application’s sensitive permissions. A study done by Mohammed M. Alana from the Khawarizmi International College shows that a shocking 68.61% do not know how many applications installed on their device have access to their most private data [11]. This is a major concern as malicious applications can take advantage of users who are not tracking their sensitive permissions, and can abuse these permissions without the user being aware of these events.

14 Chapter 4: Evaluation

There has been a lot of work and research done in terms of finding possible solutions to improving these vulnerabilities in the Android operating system. Examples of such work are the Android Security Modules (ASM) framework [17], MATRIX [18], as well as other various Location-Privacy Preserving Mechanisms (LPPMs). In this chapter, we will be evaluating vulnerabilities and reviewing possible and already existing ways of improving these Android vulnerabilities as well as looking into steps that the new Android operating system has taken to ensure user’s location privacy.

4.1 Research on Android Security Mechanisms

ASM Framework

The Android Security Modules (ASM) framework provides a set of authorization hooks in order to build new reference monitors for Android security [17]. Reference monitors refers to a continuous and fully-testable module which controls all software access to data objects and devices [19]. This specific framework works with the Android operating system in order to benefit overall security. However, since this paper is solely focusing on vulnerability in the Android operating system’s location permissions, we will focus on ASM’s impact on location permissions security. The reference monitors within the ASM framework are established as ASM apps and are developed in the same way that other Android applications are developed [17]. This ASM app will then start up the ASM app service component during the boot process and register reference monitor interface hooks, for which it will be able to receive callbacks to [17]. There are five different hook types which ASM provides a reference monitor interface for in the Android operating system:

15 1. Lifecycle Hooks [17]. Provides a hook for lifecycle events in the Activity Manager ​ Service (AMS) and the Package Manager Service (PMS). This includes resolving intents, starting activities and services, binding to services, dynamic registration of broadcast receivers, and receiving broadcast intents. 2. OS Service Hooks [17]. Provides mediation for Android OS APIs which implement ​ functionality for service components defined as system services such as location. ASM uses Android’s AppOps subsystem for the authorization hooks of many of the OS service hooks. 3. Content Provider Hooks [17]. Observes the content provider components which are ​ providing relational database interface in the purposes of sharing information with other applications. Functions included here are insert, update, delete, and query. 4. Third-Party Hooks [17]. ASM applications can also be applied to third-party Android ​ applications and can extend enforcement into these applications. These hooks are identified using the hook name as well as the package name of the application using the authorization hook. The ASM application then interprets data received from the callbacks’ interface and returns allow, deny, or allow with modifications. 5. LSM Hooks [17]. Although not used as often, the LSM hooks place authorization hooks ​ in the Linux kernel so that ASM applications can mediate objects such as files and network sockets.

The Android Security Modules framework is unique from other similar reference monitor interfaces as it addresses the Android OS APIs. This allows for the ASM applications to enforce security requirements for system services such as the location service. Such enforcement makes it difficult for adversaries to exploit vulnerabilities as the authorization hooks monitor applications and behaviors to ensure they follow requirements.

Location-Privacy Preserving Mechanisms

There are many Location-Privacy Preserving Mechanisms (LPPM) created by researchers in the hopes of making vulnerabilities caused by sensitive data points less susceptible to an attacker. Specifically, there are LPPMs such as Spatial Cloaking, Noise, and Rounding. Spatial

16 Cloaking targets specific sensitive location data and deletes coordinates near the sensitive location data (such as the user’s home) [16]. Noise refers to Gaussian Noise, which provides noise to each GPS coordinate [16]. This LPPM could be possibly used for randomized ​ discretization, which works against white-box attacks by adding a Gaussian noise to each location data and replacing each location data with the closest cluster of data [26]. Lastly, Rounding refers to reducing accuracy of location data by taking that data point and snapping the latitude and longitude to the nearest point on a square grid [16]. These three types of LPPMs are useful when it comes to preventing malicious applications from identifying sensitive locations, otherwise known as a black-box attack. However, in order to avoid black-box attacks, or a white-box attack in which the attacker is aware of the protection mechanisms, we need another mechanism, specifically agility maneuvers [15]. There are three different agility maneuvers which can be used to defend users against white-box attacks. These three agility maneuvers are known as Random Obfuscation, Spatial Distribution, and Temporal Distribution [15]. Random Obfuscation is a type of maneuver in which the focus is primarily on the rate of change for system configurations [15]. From there, the maneuver selects one type of protection mechanism from the available mechanisms once the sensing data becomes stationary for a prolonged period of time once again [15]. By doing so, the attacker has a more difficult time guessing the protection mechanism at use and therefore is less likely to be successful in a white-box attack. The second agility maneuver known as Spatial Distribution focuses specifically on the diversity in the space of readings [15]. This maneuver will uniformly distribute data points in the space of readings and does so by generating artificial data as new or modified data points once the user becomes stationary [15]. This type of maneuver is another great way to throw an attacker as they then will have more trouble determining a sensitive location. Therefore, the user’s sensitive location, such as their home, can stay hidden as other location data will confuse the attacker. Lastly, the third agility maneuver is Temporal Distribution [15]. Temporal Distribution is aimed on the attacker/malicious application which is constantly reading the user’s location [15]. Specifically, this maneuver focuses on uniformly redistributing data points in the space of the readings by generating artificial data location points whenever the location sensors are not producing new data for a short period of time [15]. This is similar to the effect we see with

17 Spatial Distribution, however, time becomes essential in this maneuver in ensuring attackers are unable to tell real readings from the synthetic ones. Overall, these three different maneuvers, implemented with the protection mechanisms have been proven useful in preventing black-box and white-box attacks. Once those three maneuvers were tested, white-box attacks went from succeeding 56.92% of the time to 2.68% success [15]. Therefore, these maneuvers and LPPMs implemented would be able to protect users from becoming victims of black-box and white-box attacks.

MATRIX

We have now reviewed possible defense strategies from the developer and platform point-of-view. However, we can also provide users with information regarding their sensitive location data. MATRIX is a system which provides users control and visibility over their sensors [18]. This is done by implementing a PrivoScope service which monitors and analyzes application patterns for access location and sensor APIs [18]. From there, the user is more capable of making a privacy-informed decision about providing synthetic data to applications that use MATRIX or overall uninstalling or disabling the application [18]. Once the user has made a decision about an application, they can use the implemented Synthetic Location Service to dynamically sandbox applications on the user’s device, resulting in the application receiving obscure or synthetic location data [18]. This system allows users to be in control of their applications and make better informed decisions about which applications to give consent to sensitive location data.

4.2 Proposed Security Mechanisms

AbuserGPS Modification

In Chapter 3, we highlighted a variety of vulnerabilities within the application AbuserGPS. These vulnerabilities included the user being unaware of which location access type is being used, the lack of a defined time for location access and storage of location data, and the

18 lack of a permissions auto-reset on applications. In this section, we will be demonstrating some of the proposed security mechanisms on the application AbuserGPS. The first security mechanism we implemented on the application AbuserGPS is restricting the amount of times location can be updated for a duration of time. In this example, the duration time set was every ten seconds. This means that every ten seconds, the location data is updated, instead of being allowed to update as often as every second. We implemented this by creating a value named current which takes the local time’s second. This allows us to create a timer which will be able to control the updated values for the released location data. From there, I threw a security exception if the ten seconds had not passed and simply did not update the location. We can see this implemented in Figure 7 with the value current being set and the security exception being thrown. From there, the catch ensures latitude and longitude location data remain the same. This can also be seen in the orange square in Figure 8, in which we can observe in the other log messages there is no change in location except for when the ten seconds have passed. Although this is not exactly the same behavior as the LPPM known as Spatial Cloaking [16], this method would still delete certain location data if the user is moving, making tracking a user and logging their location data more difficult. The second security mechanism we were able to implement on the AbuserGPS application was the rounding of latitude and longitude values. This can be seen implemented in the two lines after the if statement in the try section of the function shown in Figure 7. I rounded the location value to the thousandth decimal as this is the recommended decimal value for when privacy is a concern in terms of sharing location data [24]. This type of protection mechanism is similar to the LPPM known as Rounding [16], as it takes the location latitude and longitude and gives the application a latitude and longitude which is close to the actual location data, without providing too much information to the application. We can observe the Rounding in action in the modified AbuserGPS application in Figure 8, in which both the latitude and longitude readings are rounding to the nearest thousandth decimal.

19

Fig. 7: Modified onLocationChanged function in AbuserGPS

Fig. 8: Location data received by modified AbuserGPS

AOSP Conceptual Implementation

As mentioned before, AOSP, or the Android Open Source Project is an “open source operating system for mobile devices and a corresponding open source project led by Google” [7]. The AOSP allows developers and researchers to emulate the Android operating system on their own Android-compatible mobile devices. Although I was unable to get AOSP to run successfully on my computer, I will be demonstrating an implementation that can be placed in AOSP to provide a defense mechanism against vulnerabilities in the Android operating system. The LocationManager in AOSP is the default API which is available for all Android SDK. Within this API, location information is accessed by calls such as getLastKnownLocation,

20 which returns the location data from the last known location as shown above in Figure 2. If location data is needed immediately, applications are then to use this method instead of other methods such as requestSingleUpdate that take a longer amount of time. The MATRIX system that was described above uses the LocationManager API, specifically the function getLastKnownLocation [18]. The system specifically audits all the location and sensor accesses and then updates the information reported to an application should context permit this to occur [18]. However, there is also another area in which we can observe the application context when an application is accessing location data. This service is known as the LocationManagerService. This privileged service’s purpose is to validate the application’s access to the location permission by checking its requested permissions, as you can see in the function getLastKnownLocation from this service in Figure 9. Once that request is validated, the service will generate an event and log all relevant data [18]. MATRIX uses this service to then call the PrivoScopeManager, which will then forward the event to the PrivoScopeService and if package name in the event is the same as the package name of the application making the request, the event is then added to the service’s database [18]. We can see a similar log event occur in Figure 10, in which we added a line once we are sure that getLastKnownLocation will not trigger any exceptions. From there the PrivoScopeService sends the event to a Notification service which updates the notification bar for the user to observe [18]. Finally, the PrivoScopeManager will well expose a requestAuditEvents method that other applications on the device can register for [18]. Depending on whether or not the event was added to the database successfully, the addAuditEvent method will return a boolean value to the LocationManager API [18]. Once all these steps are completed, the user will have the ability to view and control the location and sensor access based on applications through the MATRIX system. This system allows users to be aware of the events occurring within the applications on their mobile, strengthening the previous vulnerability we defined earlier.

21

Fig. 9: getLastKnownLocation in LocationManagerService

Fig. 10: Demonstration of modified _getLastKnownLocationLocked in LocationManagerService, not compiled

22 4.3 Candidate Security Experiments

Unfortunately, due to the COVID pandemic that is currently facing America, we were unable to run a user study. However, when it is safe to interact with others once more, this proposed experiment with users will test users’ ability to make the right decision as well as if programs would comply with security and privacy policies. This experiment would require a field-based user study, in which we would observe the ​ participants’ behaviors as well as the reaction of the application limitations. Our hypotheses for this experiment will be that although the modified version of the Android OS will provide more overhead, it will also secure more vulnerabilities left open in the stock Android OS. Within this experiment, we would break the participants into two different groups. The first group will use a mobile device with a stock Android OS version 9.0 using only install-time permissions. The second group will use a modified version of the Android OS implementing the Android privacy mechanisms described in section 4.1. Prior to the experiment, all participants will be informed that attacks targeting location permissions may occur during the experiment [27]. The experiment would use one application, which would be running our test application. The test application would appear to use location data to show the weather while also attempting to abuse location-based sensors. From there, the users will be asked to complete two tasks. The first experimental task users will be asked to complete is download and open the application. The second experimental task requires users to move to a different location and check that the application has updated the weather forecast depending on the new area they are in. In order to ensure the tasks are not security biased, the user will simply be asked to download and open the application and use the application for a week. Therefore, there is no reason for the participant to raise suspicions from the subjects. The first experimental task can open the user to a sensitive data leakage as the user only recognizes the location access from the foreground location access type. This may lead to wrongful collection of data within the background. However, this can only occur if the user provides initial consent of location permission access to the application. When users attempt the second task, they will have already either denied or accepted permissions for the adversary application. Therefore, the application will be able to either be able

23 to track and store sensitive location data or not depending on the actions taken by the participant. If the user allows for the application to receive data, this may lead to a black-box or white-box attack, and lead to sensitive location data being collected by the adversary.

4.4 Android 11 Location Privacy

On September 8th, 2020, Android released its eleventh major Android operating system release [22]. With this release, Android 11 is planning on building on the earlier versions of Android and provide new features to ensure user’s security as well as provide increased transparency and control in permissions [22]. Although this Android OS release has not yet been released to the public, Android 11 has been released for developers to review new privacy features as well as test their applications. In this section, we will be highlighting a few key privacy features which will be taking effect in Android 11. There are three new privacy features involving location permissions taking effect in the new Android operating system. The first feature is one-time permissions [22]. One-time permissions will allow users to grant temporary access to the permissions location, microphone, and camera [22]. This will provide users with some more control over setting a defined period for an application to use privacy-related permissions. The second privacy feature concerns background location access [22]. Specifically, Android 11 will now change how users are able to grant background location permission to applications. Applications will have to request foreground and background permissions in separate calls when requesting permissions from the user [22]. Another privacy feature will include applications needing to explain their reasonings for using background location if necessary [22]. Doing so will secure vulnerabilities in the Android operating system as now it will become more difficult for applications to misuse background location data for purposes other than ones the application states. Lastly, foreground services in Android 11 will also be changing how it accesses location, camera, and microphone data [22]. However, if the application starts while the application is running in the background, foreground services cannot access location, camera, or microphone [22]. This feature is rather similar to the second privacy feature mentioned besides the initial start of the application.

24 Overall, these new privacy features in Android 11 will allow Android’s operating system to keep users’ privacy involving sensitive permissions secure by closing currently-existing vulnerabilities in the current Android operating system.

25 Chapter 5: Conclusion

In this paper, we have introduced the background of the Android operating system, such as the Android Open Source Project (AOSP), Android’s security and privacy principles, as well as the Android’s security model. From there, we identified current Android vulnerabilities, such as user privacy awareness, sensitive data leakage from Ride-Hailing Services (RHS), side channel attacks, and white-box and black-box based attacks. Next, we were also able to propose existing defenses and how to implement them such as the Location-Privacy Preserving Mechanisms (LPPMs), the ASM framework, and MATRIX. Lastly, we reviewed the new statement Android released about the new operating system that will be taking effect in the future: Android 11.

26 References

[1] Protalinski, E. (2019, May 7). Android passes 2.5 billion monthly active devices. Retrieved from https://venturebeat.com/2019/05/07/android-passes-2-5-billion-monthly-active-devices/

[2] René Mayrhofer, Jeffrey Vander Stoep, Chad Brubaker, and Nick Kralevich. The Android Platform Security Model. arXiv preprint arXiv:1904.05572, 2019.

[3] App Manifest Overview  :   Android Developers. (2020, August 26). Retrieved from https://developer.android.com/guide/topics/manifest/manifest-intro

[4] Request location permissions  :   Android Developers. (2020, October 09). Retrieved from https://developer.android.com/training/location/permissions

[5] Google Play Protect. (n.d.). Retrieved from https://www.android.com/play-protect/

[6] Cunningham, E. (2017, December 19). Improving app security and performance on Google Play for years to come. Retrieved from https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.ht ml

[7] Android Open Source Project. (n.d.). Retrieved from https://source.android.com/

[8] How to understand the directory structure of android root tree? (2015, October 12). Retrieved from https://stackoverflow.com/questions/9046572/how-to-understand-the-directory-structure-of-andr oid-root-tree

[9] Android Open Source Project. (n.d.). Retrieved from https://source.android.com/compatibility/cdd

27

[10] Auxier, B., Rainie, L., Anderson, M., Perrin, A., Kumar, M., & Turner, E. (2019, November 15). Americans and Privacy: Concerned, Confused and Feeling Lack of Control Over Their Personal Information. Retrieved from https://www.pewresearch.org/internet/2019/11/15/americans-and-privacy-concerned-confused-a nd-feeling-lack-of-control-over-their-personal-information/

[11] Alani, M. M. (2017). Android Users Privacy Awareness Survey. International Journal of Interactive Mobile Technologies (iJIM), 11(3), 130-144.

[12] Boshell, P. M. (2019, March 25). The Power of Place: Geolocation Tracking and Privacy. Retrieved from https://businesslawtoday.org/2019/03/power-place-geolocation-tracking-privacy/

[13] Complaint at 3, In re Uber Tech., Inc., File No. 1523054 (FTC Feb. 2017).

[14] Q. Zhao, C. Zuo, G. Pellegrino, and L. Zhiqiang, “Geo-locating drivers: A study of sensitive data leakage in ride-hailing services.,” in Annual Network and Distributed System Security symposium, February 2019 (NDSS 2019), 2019.

[15] G. Petracca, L. M. Marvel, A. Swami, and T. Jaeger, “Agility maneuvers to mitigate inference attacks on sensed location data,” in IEEE Military Communications Conference, MILCOM 2016

[16] J. Krumm. Inference Attacks on Location Tracks, PERVASIVE, 2007.

[17] S. Heuser, A. Sadeghi, A. Nadkarni and W. Enck, “ASM: A Programmable Interface for Extending Android Security.,” In Proc. USENIX security, 2014.

[18] Narain, S. and Noubir, G., “Mitigating location privacy attacks on mobile devices using dynamic app sandboxing.” In: Proceedings of the 19th Privacy Enhancing Technologies Symposium (PETS) (2019)

28

[19] Definition of reference monitor. (n.d.). Retrieved from https://www.pcmag.com/encyclopedia/term/reference-monitor

[20] Rouse, M. (2019, May 08). Side-channel attack. Retrieved from https://searchsecurity.techtarget.com/definition/side-channel-attack

[21] S. Narain, T. D. Vo-Huu, K. Block and G. Noubir, "Inferring user routes and locations using zero-permission mobile sensors", Proc. IEEE Symp. Security Privacy (S P), 2016.

[22] Privacy in Android 11. (2020, September 08). Retrieved from https://developer.android.com/about/versions/11/privacy

[23] Valentino-devries, J., Singer, N., Keller, M. H., & Krolik, A. (2018, December 10). Your Apps Know Where You Were Last Night, and They're Not Keeping It Secret. Retrieved from https://www.nytimes.com/interactive/2018/12/10/business/location-data-privacy-apps.html?mtrr ef=www.google.com

[24] Bornemann, J. (2016, April 27). Deciding how many decimal places to include when reporting latitude and longitude. Retrieved from https://gisjames.wordpress.com/2016/04/27/deciding-how-many-decimal-places-to-include-when -reporting-latitude-and-longitude/

[25] Liu, S. (2020, July 06). Android OS platform version market share 2013-2020. Retrieved from https://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices-with-a ndroid-os/

[26] Y. Zhang and P. Liang. Defending against whitebox adversarial attacks via randomized discretization. In Artificial Intelligence and Statistics (AISTATS), 2019.

29 [27] G. Petracca, A.-A. Reineh, Y. Sun, J. Grossklags, and T. Jaeger, “Aware: Preventing abuse of privacy-sensitive sensors via operation bindings,” 2017.

[28] Background Location Limits : Android Developers. (2020, October 20). Retrieved from https://developer.android.com/about/versions/oreo/background-location-limits

30 Dovile Drozdovaite

Education and Honors: The Pennsylvania State University, University Park, PA. Graduation: December 2020 Schreyer Honors College Bachelor of Science in Computer Engineering *Dean’s List: Fall 2017/Spring 2018/Fall 2018/Fall 2019 ​ Member of Sigma Alpha Pi National Leadership and Success Honor Society. Events Attended HackPSU(Spring 2019 - Fall 2020). 24-hour hackathon at Penn State University where students can learn to code or compete to build something ​ from scratch. CodePSU(Spring 2019). Largest competitive programming competition at Penn State. My team participated in most difficult category, advanced. ​ Skills: Github Link. https://github.com/dovdroz ​ ​ Programming Languages. Python, Java, C, C#, HTML, Kotlin, ASP.NET, SQL, Verilog. ​ Speaking Languages. Fluent in English and Lithuanian. Can hold a conversation in French. ​ Software. Visual Studio, IntelliJ, Sublime, Microsoft Office, Android Studio. ​ Tools. Dynatrace Appmon, Microsoft SQL Server Management Studio, Virtual User Generator, Loadrunner Analysis, Microsoft SQL Server ​ Integration Services, Selenium.

Engineering Internships/Work Experience: KCF Technologies. State College, PA. May-August 2020. Software Engineering Intern ● Designed dashboard application using .NET framework in Bootstrap ● Worked on solo project titled SmartDiagnostics Edge: an edge for customers to view data pertaining to machines server which collects data from BaseStations using MQTT and an ● Worked with team members using TypeScript React to create API containing information about the BaseStations. application, pushed 2 new components to Azure Repo ● Presented SmartDiagnostics Edge to CEO and ~100 employees Comcast Spotlight. Wayne, PA. May-August 2019. Spotlight Software Engineering Intern ● Worked with two teams: performance testing team and development ● Created MVC dashboard application using .NET framework which and support team reads JIRA SPEG tickets from database using SQL and SSIS and ● Experienced working in a SAFe environment creates date filter for tickets using Visual Studio (C#, HTML) ● Created performance testing test plan and participated in revision ● Took over scrum master role for two days ● Created performance testing scripts using Virtual User Generator in C language and handled data with SQL ● Participated in fourth Program Increment (PI) planning for both trains ● Ran load tests of ~1200 users using HPE ALM Performance Center ● Presented development and support team’s objectives for the first ● Created reports for performance testing test results and presented train in next PI in front of ~100 senior engineers and managers information ● Shadowed team members using Selenium for test automation and ● Observed server’s health during performance test using Dynatrace Visual Studio/SQL Database for Spotlight application AppMon

Leadership Experience: Association of Women in Computing at Pennsylvania State University: Treasurer and Member of the Executive Board. May 2019 to August 2020. Manage financial accounting for organization, develop budget for AWC’s trip to the ​ ​ Grace Hopper Convention, report to executive board and sponsoring companies, involved with decision making relating to the future direction of the chapter. Mentor with Penn State Engineering’s Mentor Collective. May 2019 to August 2020. As a mentor, I share my ​ experiences with incoming students while guiding them to their goals. I am leading 3 mentees within the organization.

Activities and Related Philanthropy: Association of Women in Computing, PSU. 2018 to present. Member, treasurer and executive board member of PSU ​ ​ ​ ​ branch that promotes the advancement of women in technical fields and provides networking opportunities for all members. Professional Management Association, PSU. 2018 to 2019. Member of PMA which combines project management ​ ​ experience and managerial education to produce effective leaders HackPSU, PSU. 2019 to present. Member of HackPSU’s education team which runs the largest hackathon at Penn State University ​ ​ with over 900 students in attendance