Explanation of sections and fields on research results.

1) Device Details

In this section, device details like manufacturer, model, product and version are listed.

Pre-installed Applications

In this section, pre-installed that is collected from device listed. However, it should be noted that some users stopped uploading process before completed, in some devices, we could not collect all pre-installed applications.

2) Application Details

In this section, we listed detailed analysis results for each application. We grouped this result into 7 different sections: Application Metadata, Manifest Attributes, Application Permissions, Exported Components, Third Party Libraries, Tracker SDKs and Cloud Services. These sections may contain data about following topics:

2.1) Application Metadata

This section contains some metadata information about application. This information is obtained both from device while collecting application and using static analysis methods.

First Install Time: This information is received from device using our application (Pre-app Collector). It shows that when the application is first installed to the device.

Last Update Time: This information is received from device using our application (Pre-app Collector). It shows that when the application is updated.

MD5 Hash: MD5 hash of the apk file.

Package Name: Package name of the application.

Version Code: A positive integer used as an internal version number. This number is used only to determine whether one version is more recent than another, with higher numbers indicating more recent versions.

Version Name: A string used as the version number shown to users. This setting can be specified as a raw string or as a reference to a string resource.

Target SDK Version: Specifies the API level on which the app is designed to run. In some cases, this allows the app to use manifest elements or behaviors defined in the target API level, rather than being restricted to using only those defined for the minimum API level.

Minimum SDK Version: The minimum version of the Android platform on which the app will run, specified by the platform's API level identifier.

Certicate Info: This section contains multiple values about the certificate that is used to sign application.

Certificate Identifier: The purpose of this information to show which organization, company or people signed this application. It is optained from analysis of certificate issuer field.

2.2) Manifest Attributes

This section contains information about some important manifest attributes like sharedUserId, allowBackup, debuggable and usesClearTextTraffic.

sharedUserId: The name of a Linux user ID that will be shared with other apps. By default, Android assigns each app its own unique user ID. However, if this attribute is set to the same value for two or more apps, they will all share the same ID — provided that their certificate sets are identical. Apps with the same user ID can access each other's data and, if desired, run in the same process.

allowBackup: Whether to allow the application to participate in the backup and restore infrastructure. If this attribute is set to false, no backup or restore of the application will ever be performed, even by a full-system backup that would otherwise cause all application data to be saved via adb. The default value of this attribute is true.

debuggable: Whether or not the application can be debugged, even when running on a device in user mode — "true" if it can be, and "false" if not. The default value is "false".

usesClearTextTraffic: Indicates whether the app intends to use cleartext network traffic, such as cleartext HTTP. The default value for apps that target API level 27 or lower is "true". Apps that target API level 28 or higher default to "false".

2.3) Application Permissions

This section contains list of all permissions and third permissions that application declared. Third party permissions are extracted using Androguard.

Permissions: In Android, application developers have to declare permissions to fulfill any functionality and access restricted resources. In this field, all of the permissions that are declared by appliation is listed.

Third Party (Custom) Permissions: In Android, app developers can use the security features provided by Android to define their own permissions. By defining custom permissions, an app can share its resources and capabilities with other apps.

2.4) Exported Components

Android apps mainly have 4 different components: Activity, Service, Content Provider, Broadcast Receiver. In this section, app components that are exported and can be used by other applications with or without permission are listed.

Activity: An activity is the entry point for interacting with the user. It represents a single screen with a user interface.

Service: A service is a general-purpose entry point for keeping an app running in the background for all kinds of reasons. It is a component that runs in the background to perform long-running operations or to perform work for remote processes.

Content Provider: A content provider manages a shared set of app data that you can store in the file system, in a SQLite database, on the web, or on any other persistent storage location that your app can access. Through the content provider, other apps can query or modify the data if the content provider allows it.

Broadcast Receiver: A broadcast receiver is a component that enables the system to deliver events to the app outside of a regular user flow, allowing the app to respond to system-wide broadcast announcements. Because broadcast receivers are another well-defined entry into the app, the system can deliver broadcasts even to apps that aren't currently running.

2.5) Third Party Libraries

Using Third Party Libraries like SDKs saves a lot of time of the app developers. However, these libraries may affect user's security and privacy due to vulnerabilities, hidden functionalities. Also, they are commonly used by advertising and tracking services. In this section, TPLs that are used by application are listed. This information is extracted from applications by using state of art tool LibRadar.

2.6) Tracker SDKs

Application developers take advantage of Tracker SDKs for various purposes like advertising, location tracking, crash reporting etc. To fulfill their functionality, these SDKs mostly violate user's privacy. Thus, in this section Trackers SDKs which are detected using exodus-privacy tool are listed.

Name: Name of the Tracker SDK.

Tracker Groups: List of tracker groups that states the purpose of tracking service. This field include of Analytic, Advertisement, Profiling, Location, Identification, Crash Reporters.

Permissions: List of permissions that application declared.

2.7) Cloud Services

In scope of this research, cloud services like Google Maps API, Amazon AWS S3 Buckets, Google Firebase Database and OAuth are analyzed.

Google Maps API: This API service presents Google Maps Data-base to developers to search and embed its functionalities to applications. Until 2018, this service was free and developers can use it as they wish.
As a result of our analysis, we detected some embedded Google Maps API keys. Then, we automatically tested these keys using gmapapiscanner(https://github.com/ozguralp/gmapsapiscanner/) tool and listed impact, information and POC about these keys.

Amazon AWS S3 Buckets: Amazon Web Services (AWS) is acloud computing platform that is widely used by mobile appli-cation developers and companies. Because it is the most com-mon used cloud platform among cloud platforms, it drawsattackers attention more than other platforms. Mobile applica-tions especially utilize Amazon Simple Storage Service (S3) whichis subsidiary service of AWS to store various objects.
In scope of our research, we detected plenty of S3 buckets, AWSaccess key IDs and AWS secret access keys by using apkleaks tooland manual reverse engineering of apk files. We found a number ofkey pairs which are required to access Amazon S3 buckets program-matically. We tested these key pairs to see if any of them are stillvalid and can be used to access companies’ S3 buckets.

Google Firebase Database: Google offers developers and com-panies a cloud based database to store their data as JSON.This database which is named as Firebase Realtime Database canbe used via SDK and has some key capabilities like realtime syn-chronization, offline response management, multiple database scal-ability, direct access from client devices such as mobile deviceor web browser. To utilize this database, developers should cre-ate a database from Firebase console
We detected some embedded Firebase Database URLs inside apk files. After that, we tested these URLs if they are configured correctly. As a result, we found that some of the Firebase Databases are readable and writable without any authentication.

OAuth: Android applications use OAuth 2.0 to access differentAPIs or services of various companies. To authenticate on them, ap-plication developers use client_id and client_secret values. Becauseof that these values especially client_secret should be protected.
We observed some applications store OAuth valuesthat are belongs to services such as Google, AOL, Outlook, Office365, Yahoo, Microsoft and mail.ru as clear text. Thus, attackers cansteal these values and authenticate with them to APIs or servicesand cause sensitive data leakage and unauthorized access to listedprivate services.

3) Interesting Results

In this section, we listed some interesting results that effect user's security and privacy more than other informations.

Application Certificate Identifiers: As part of research, we grouped applications using the information from certificate's issuer field. We also marked groups that contains more than one application with red colour. This information can be used to understand ecosystem of the applications in device.

Third Party Permissions with Applications: In this field, third party permissions with applications that declared them are listed. Again, we marked permissions that are declared by more than one application with red colour. Using information which applications are related with each other can be learnt.

Pre-installed Applications: In this field, we listed only most relevant and critical information about user's security and privacy for people who want brief information about our research. This information contains application metadata, trackers SDKs, and cloud services.

Applications with Same Shared User IdIn this field, we listed application with same sharedUserId values. These applications can access each other resources and can share data with each other. This situation can cause security and privacy flaws.

4) Device Scores

We developed an immature scoring system to evaluate devices in terms of various analysis results. Thus, we aim to understand devices' effect on user security and privacy. In this system, we groupped findings according to applicability, user's awareness about finding, how hard to exploit finding etc. In below, we seperated results in 4 different groups.

Low Level Findings

Number of system applications: In this context, we detected system apps by looking "android.uid.system" on sharedUserId. We calculated score with following equation:

score1 = (Number of applications that run as system on the device / Number of applications on the device) * 0.25

Medium Level Findings

Number of exported application components without permission:

score2 = (Number of exported application components without permission / Number of applications on the device) * 0.50

Number of applications that have allowBackup enabled:

score3 = (Number of applications that have allowBackup enabled / Number of applications on the device) * 0.50

Number of applications that are not signed by manufacturer/vendor:

score4 = (Number of applications that are not signed by manufacturer/vendor / Number of applications on the device) * 0.50

Number of applications that are not updated for more than 2 years:

score5 = (Number of applications that are not updated for more than 2 years / Number of applications on the device) * 0.50

High Level Findings

Number of dangerous permissions:

score6 = (Number of dangerous permissions / Number of applications on the device) * 0.75

Number of applications that have usesClearTextTraffic enabled:

score7 = (Number of applications that have usesClearTextTraffic enabled / Number of applications on the device) * 0.75

Number of applications that have debuggable enabled:

score8 = (Number of applications that have debuggable enabled / Number of applications on the device) * 0.75

Critical Level Findings

Number of tracker SDK and number of trackers which are not in crash reporting group:

score9 = (Number of tracker SDK and number of trackers which are not in crash reporting group) * 1.00

Number of vulnerabilities in cloud services:

score10 = (Number of vulnerabilities in cloud services) * 1.00