Linköpings universitet SE–581 83 Linköping
Linköping University | Department of Electrical Engineering
Master’s thesis, 30 ECTS | Computer Science and Engineering
2021 | LiTH-ISY-EX--21/5368--SE
Secure IPC to enable highly
sen-sitive communication in a
smart-phone environment with a BYOD
setup
Säker IPC som möjliggör kommunikation av känslig data i en
smartphone-miljö med en BYOD uppsättning
Daniel Holmberg
Supervisor : Christoffer Hindlycke Examiner : Jan-Åke Larsson
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Över-föring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och till-gängligheten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet än-dras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
Abstract
The constantly increasing amount of shared data worldwide demands a continuously im-proved understanding of current smartphone security vulnerabilities and limitations to ensure secure communication. Securing sensitive enterprise data on a Bring Your Own Device (BYOD) setup can be quite challenging. Allowing multiple applications to commu-nicate through Inter-process Communication (IPC) in a shared environment can induce a wide range of security vulnerabilities if not implemented adequately. In this thesis, multi-ple different IPC mechanisms have been investigated and applied with respect to confiden-tiality, integrity, and availability (CIA-triad) of a system including an Android application and a server, to enable a secure Single Sign-On (SSO) solution. Relevant threats were iden-tified that could highlight vulnerabilities related to the use of IPC mechanisms provided by the Android OS such as AIDL, Messenger, Content Provider, and Broadcast Receiver. A Proof-of-Concept (POC) system for each IPC mechanism was developed and implemented with targeted mitigation techniques (MT) and best practices to ensure a high level of con-formity with the CIA-triad. Additionally, each IPC mechanism was evaluated through a set of functional tests, a Grey-box penetration testing approach, and a performance analysis of the execution time and the total Lines-of-Code (LOC) required. The results shows that there are indeed different ways of achieving secure communication on the Android OS and thereby enabling a secure SSO solution by ensuring the inclusion of related MTs to prevent critical security vulnerabilities. Also, the IPC mechanism with the highest performance in relation to execution time and LOC is shown to be AIDL.
Acknowledgments
I would like to thank Sectra Communications AB for making this work possible. Special thanks to Christoffer Lauri and Jerry Falkcrona for their invaluable insights and supervision. I would also like to send special thanks to this thesis initiator Fredrik Wern for his enthusiasm and support.
I would like to thank Christoffer Hindlycke at the department of electrical engineering at Linköping University for his robust guidance and supervision throughout this process.
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures viii
List of Tables x 1 Introduction 1 1.1 Motivation . . . 1 1.2 Aim . . . 1 1.3 Research questions . . . 1 1.4 Delimitation . . . 2 2 Security in Android 3 2.1 Architecture . . . 3 2.2 Linux Kernel . . . 4 2.3 Application sandbox . . . 4 2.4 Permissions framework . . . 5 2.4.1 Install-time permissions . . . 5 2.4.2 Runtime permissions . . . 5 2.4.3 Special permissions . . . 6 2.5 App components . . . 6 2.5.1 Activity . . . 6 2.5.2 Service . . . 6 2.5.3 Broadcast Receiver . . . 7 2.5.4 Content Provider . . . 8
2.6 Bring Your Own Device . . . 8
2.7 Best practices . . . 9 3 IPC mechanisms 11 3.1 Covert channels . . . 11 3.1.1 Timing channels . . . 12 3.1.2 Storage channels . . . 12 3.2 Overt channels . . . 12 3.2.1 Intents . . . 12 3.2.1.1 Implicit Intent . . . 12 3.2.1.2 Explicit Intent . . . 13 3.2.2 Broadcast Receiver . . . 13 3.2.3 Content Provider . . . 13
3.2.4.1 Binder . . . 14
3.2.4.2 AIDL . . . 14
3.2.4.3 Messenger . . . 15
3.3 Threats . . . 15
3.3.1 Activity Hijacking . . . 15
3.3.2 Malicious Activity Launch . . . 15
3.3.3 Broadcast Hijacking . . . 15
3.3.4 Malicious Broadcast Injection . . . 15
3.3.5 Service Hijacking . . . 16
3.3.6 Malicious Service Launch . . . 16
3.3.7 Content Provider Hijacking . . . 16
3.3.8 Identical Custom Permission . . . 16
3.4 Security testing . . . 16 3.4.1 Penetration testing . . . 17 3.4.1.1 Drozer . . . 18 3.5 Related work . . . 19 4 Method 21 4.1 Implementation . . . 21
4.1.1 System Requirements Analysis . . . 22
4.1.1.1 Security requirements . . . 22 4.1.2 Mitigating threats . . . 23 4.2 Evaluation . . . 23 4.2.1 Functional testing . . . 23 4.2.2 Penetration testing . . . 24 4.2.3 Performance analysis . . . 25 4.2.3.1 Execution Time . . . 25 4.2.3.2 Lines of Code . . . 26 5 Results 27 5.1 Implementation . . . 27 5.1.1 Broadcast Receiver . . . 27 5.1.2 Content Provider . . . 28 5.1.3 AIDL . . . 29 5.1.4 Messenger . . . 29 5.1.5 Mitigating threats . . . 30 5.2 Evaluation . . . 31 5.2.1 Functional testing . . . 31 5.2.2 Penetration testing . . . 33 5.2.3 Performance analysis . . . 42 5.2.3.1 Execution time . . . 42 5.2.3.2 Lines of Code . . . 42 6 Discussion 44 6.1 Method . . . 44 6.1.1 Implementation . . . 44 6.1.2 Evaluation . . . 45 6.1.3 Source criticism . . . 46 6.2 Results . . . 46 6.2.1 Implementation . . . 46 6.2.2 Evaluation . . . 46
7 Conclusion 49
7.1 Future work . . . 50
Bibliography 51 8 Appendix 55 8.1 Android Security - Best practices . . . 55
8.1.1 Signature-based permission in AndroidManifest.xml . . . 55
8.1.2 Disallowing access to local content provider in AndroidManifest.xml . . 55
8.1.3 Using Intent to defer permission . . . 56
8.2 Application states . . . 56
8.3 Installing Drozer . . . 62
8.4 Repackaging Drozer Agent application . . . 63
8.5 Execution Time . . . 65
List of Figures
2.1 The Android OS stack. . . 4
3.1 The four phases of penetration testing. . . 17
3.2 The Drozer framework. . . 18
5.1 Broadcast Receiver mechanism in its SSO solution. . . 28
5.2 Content Provider mechanism in its SSO solution. . . 28
5.3 AIDL mechanism in its SSO solution. . . 29
5.4 Messenger mechanism in its SSO solution. . . 30
5.5 Test report for functional tests on Broadcast Receiver IPC mechanism. . . 32
5.6 Test report for functional tests on Content Provider IPC mechanism. . . 32
5.7 Test report for functional tests on AIDL IPC mechanism. . . 33
5.8 Test report for functional tests on Messenger IPC mechanism. . . 33
5.9 The attack surface of server application with Broadcast Receiver IPC mechanism. . 34
5.10 Android manifest of server application with Broadcast Receiver IPC mechanism. . 35
5.11 The attack surface of server application with Content Provider IPC mechanism. . . 36
5.12 Android manifest of server application with Content Provider IPC mechanism. . . 37
5.13 The attack surface of server application with AIDL IPC mechanism . . . 37
5.14 Android manifest of server application with AIDL IPC mechanism . . . 38
5.15 The attack surface of server application with Messenger IPC mechanism. . . 38
5.16 The Android manifest of server application with Messenger IPC mechanism. . . . 39
5.17 Malicious Broadcast Injection attack trying to modify the authentication state through the Authenticator application using Drozer. . . 39
5.18 Log-results of Drozer Agent after Malicious Broadcast Injection attack on the Au-thenticator application. . . 40
5.19 Malicious Broadcast Injection attack trying to modify the authentication state through a Client application using Drozer. . . 40
5.20 Broadcast Hijacking attack trying to intercept sensitive data communicated between Authenticator and Client applications. . . 40
5.21 Content Provider Hijacking attacks trying to query, update, read, and delete sensi-tive data using Drozer. . . 41
5.22 Malicious Service Launch and Service Hijacking attacks trying to Start and Send a malicious Message to the SSO Service using Drozer. . . 41
5.23 The combined average Wall Duration for the Authenticator and Client application(s). 42 5.24 The total Lines of Code required by the Authenticator and Client application(s) for each IPC mechanism. . . 43
8.1 Authenticator and client applications in an initial unauthenticated state (Broadcast Receiver). . . 56
8.2 MainActivity of Client 1 with entered user credentials (Broadcast Receiver). . . 57
8.3 Authenticator and client applications in a resulting authenticated state (Broadcast Receiver). . . 57
8.4 Authenticator and client applications in an initial unauthenticated state (Content Provider). . . 58 8.5 MainActivity of Client 1 with entered user credentials (Content Provider). . . 58 8.6 Authenticator and client applications in a resulting authenticated state (Content
Provider). . . 59 8.7 Authenticator and client applications in an initial unauthenticated state (AIDL). . . 59 8.8 MainActivity of Client 1 with entered user credentials (AIDL). . . 60 8.9 Authenticator and client applications in a resulting authenticated state (AIDL). . . . 60 8.10 Authenticator and client applications in an initial unauthenticated state (Messenger). 61 8.11 MainActivity of Client 1 with entered user credentials (Messenger). . . 61 8.12 Authenticator and client applications in a resulting authenticated state (Messenger). 62 8.13 Attempting to declare identical custom permissions in the Drozer Agent application. 63 8.14 Repackaging Drozer Agent application with discovered permissions. . . 64 8.15 Manifest of the Drozer Agent application after repackaged with permissions. . . 65 8.16 Execution time for the Sign In process by Authenticator application (Broadcast
Receiver). . . 65 8.17 Execution time for the Sign Out process by Authenticator application (Broadcast
Receiver). . . 66 8.18 Execution time for the Sign In process by Client application(s) (Broadcast Receiver). 66 8.19 Execution time for the Sign Out process by Client application(s) (Broadcast Receiver). 66 8.20 Execution time for the Sign In process by Authenticator application (Content
Provider). . . 67 8.21 Execution time for the Sign Out process by Authenticator application (Content
Provider). . . 67 8.22 Execution time for the Sign In process by Client application(s) (Content Provider). 67 8.23 Execution time for the Sign Out process by Client application(s) (Content Provider). 68 8.24 Execution time for the Sign In process by Authenticator application (AIDL). . . 68 8.25 Execution time for the Sign Out process by Authenticator application (AIDL). . . . 68 8.26 Execution time for the Sign In process by Client application(s) (AIDL). . . 68 8.27 Execution time for the Sign Out process by Client application(s) (AIDL). . . 69 8.28 Execution time for the Sign In process by Authenticator application (Messenger). . 69 8.29 Execution time for the Sign Out process by Authenticator application (Messenger). 69 8.30 Execution time for the Sign In process by Client application(s) (Messenger). . . 69 8.31 Execution time for the Sign Out process by Client application(s) (Messenger). . . . 70 8.32 Detailed view of LOC for the Authenticator and Client application(s) (Broadcast
Receiver). . . 70 8.33 Detailed view of LOC for the Authenticator and Client application(s) (Content
Provider). . . 70 8.34 Detailed view of LOC for the Authenticator and Client application(s) (AIDL). . . . 71 8.35 Detailed view of LOC for the Authenticator and Client application(s) (Messenger). 71
List of Tables
4.1 Functional tests performed on each SUT. . . 24 4.2 Steps taken during Discovery-phase using Drozer. . . 24 4.3 Attacks performed during penetration testing using Drozer. . . 25
1
Introduction
Since its introduction in November 2007, the Android OS has been increasing in popularity and as of 2019 serves about 1.6 billion users worldwide [1]. Furthermore, the number of applications available for download from the digital distribution service Google Play is as of September 2020 about 3.0 million [2]. This increase in users and applications consequently increases the amount of shared data, thereby demanding a greater understanding of current smartphone security vulnerabilities and limitations to ensure secure communication and its implications.
1.1
Motivation
Securing sensitive enterprise data on a Bring Your Own Device (BYOD) setup can be quite challenging, when different kinds of applications are executing in a shared environment, and when sensitive information needs to be shared or communicated between different applica-tions. Such a scenario could be a Single Sign-on (SSO) service application, where multiple ap-plications need to authenticate against a resource. One way to send and process data between applications can be through the use of Inter-process Communication (IPC) mechanisms. Such mechanisms may either be provided by the operating system (OS), or implemented by the applications. Independent of the choice of mechanism, this communication would need con-fidentiality protection from other applications, including system applications, as well as au-thenticity.
1.2
Aim
The aim of this thesis is to investigate and apply different types of IPC mechanisms with respect to confidentiality, integrity, and availability of a system including, but not limited to, an Android application and a server. These mechanisms should then be applied in a usage scenario, such as an SSO solution for authentication against a resource.
1.3
Research questions
1.4. Delimitation
RQ 1 Which types of IPC mechanisms can be used to enable a secure SSO solution?
RQ 2 How can the identified IPC mechanisms be secured to mitigate security threats af-fecting the confidentiality, integrity and availability of the developed SSO solution?
1.4
Delimitation
Since the term Inter-process Communication is widely used on both software and hardware-levels in different abstraction layers, it should be clarified that this thesis report will not focus on the lower-level IPC mechanics. Its focus will be on Android IPC mechanisms used in the application layer, consequently enabling Inter Application Communication (IAC) through the use of lower-level IPC.
In this thesis, so called covert channels presented in Section 3.1 will only be considered as an al-ternative communication approach. Hence, the focus is instead aimed towards the utilisation of the more conventional counterpart called overt channels.
2
Security in Android
In this section, security concepts pertaining to a smartphone running the Android OS will be presented.
The attack surface of an Android application is inevitably partly inherited by its architectural structure. Therefore, it is crucial for developers to at a minimum possess a general under-standing of each component and their interoperability with one another.
2.1
Architecture
As shown in figure 2.1, the Android OS constitutes five layers where the top-most System Apps (or Application) layer provides the visual interaction surface to its users through system applications or additionally installed third party applications. The Java API Framework (or Android Framework) layer includes Content Providers, a View System, and multiple Managers which enables applications to reuse core, modular system components and services provided by the Android Runtime (ART) or native C/C++ libraries. As of Android version 5.0 (API level 21), each application runs in its own isolated process with its own instance of the ART which enables execution of multiple virtual machines (VM) to provide both Ahead-Of-Time (AOT) and Just-In-Time (JIT) compilation. The Hardware Abstraction Layer (HAL) enables the Java API Framework to integrate hardware functionalities such as camera and audio by exposing interfaces for each hardware component. As its foundation, the Android OS relies on a customised Linux kernel that provides different hardware drivers, power management and several key security features. [3]
2.2. Linux Kernel
Figure 2.1: The Android OS stack.
2.2
Linux Kernel
As mentioned previously, several key security features of the Android OS is provided by its underlying Linux kernel. The Linux kernel provides security features such as; (1) process isolation, (2) resource isolation, (3) user-based permission, and (4) secure IPC. [4]
2.3
Application sandbox
One of the most crucial and important security concepts applied by the Android OS is its so called application sandboxing approach. It utilises the underlying Linux kernel features of process isolation, resource isolation, and user-based permission to isolate each Android ap-plication in its own sandbox environment. Hence, each apap-plication is treated as unique user with its own uniquely identifiable Linux User ID (UID) and Group ID (GID) [5]. Through this kernel-level isolation, an application can not share data with other applications without first declaring a shared UID or requesting additional permissions. However, since the introduction of Android 10 (API level 29) the use of a shared UID is strongly discouraged as it results in a non-deterministic behaviour and should be replaced with fundamental communication mechanisms such as a Service or Content Provider [6].
2.4. Permissions framework
2.4
Permissions framework
In conjunction with the concept of Application sandbox, the Android OS applies the principle of least privilege to limit each application to only a minimum number of privileges necessary for that application to function as intended [5][7]. Since the introduction of Android 6.0 (API 23) there exists three types of permissions assigned different protection levels depending on their intrusive nature with system and other applications. Each permission type can not only be used to request access to restricted system functionality or data, but also prevent unwanted interaction from other applications. [8][9]
Listing 2.1: Permission element [10]
<permission android:description="string resource"
android:icon="drawable resource"
android:label="string resource"
android:name="string"
android:permissionGroup="string"
android:protectionLevel=["normal" | "dangerous" |
"signature" | ...] />
Listing 2.2: Example Permission [9]
<manifest ...>
<uses-permission android:name="android.permission.CAMERA"/> <application ...>
...
</application> </manifest>
2.4.1
Install-time permissions
An install-time permission is presented during the install-time and needs to be granted by the end user for the application to be installed. Furthermore, these permissions constitutes minimal affect on the system or other applications, and can be further divided into two sub-types with corresponding protection levels; (1) Normal and (2) Signature. A Normal permission lets the application access isolated data and actions outside the application’s sandbox that could be minimally intrusive of user’s privacy and other applications. In parallel, a Signature permission is used to provide custom permissions between applications that is signed with the same certificate, thereby making it possible to expose their functionality to each other but also limit access from unauthorised components. [9][10][11]
Listing 2.3: Example Custom Permission with signature protection [12]
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapp">
<permission android:name="my_custom_permission_name"
android:protectionLevel="signature" />
2.4.2
Runtime permissions
This type of permission is also known as dangerous permission as it might allow an application to access data and actions that might provide the application with a substantial intrusiveness on the system or other applications. Hence, this type of permission needs to be granted by the
2.5. App components
user at runtime so that the user is provided additional information as to why it is necessary for the requesting application to obtain this elevated privilege. [9][10]
2.4.3
Special permissions
A special permission can only be defined by the platform and the Original Equipment Man-ufacturer (OEM) to provide protection to particular custom actions [9].
2.5
App components
As described by the Android Developer Documentation (ADD), an Android application is built on four types of fundamental components where each has its own distinct purpose and lifecycle. Furthermore, each component contributes to the application’s attack surface as it acts as an entry point through which a user, or the system, can enter the application. These four components are (1) Activity, (2) Service, (3) Broadcast Receiver, and (4) Content Provider. [5]
2.5.1
Activity
The activity component provides the entry point for user interaction. Each activity consists of a single screen with a dedicated User Interface (UI). However, creating a feature-rich appli-cation almost always requires multiple collaborating activity components to form a cohesive User Experience (UX). An activity facilitates the interaction between application and the un-derlying system by:
• Managing the current UI so that the system can run the appropriate process relevant to that specific activity.
• Indicating which activity that is of most interest for the user so that the system can prioritise each related process.
• Enabling the system to save an activity’s process so that it can be restored if it has been destroyed.
• Enabling navigation to other activities through messaging objects called Intents.
2.5.2
Service
A Service component performs operations either in a foreground or background fashion. A foreground Service is noticeable to the end user but can continue to run even when the end user is not interacting with the application. In contrast, a background Service performs operations that is not necessarily noticeable to the end user. [13]
The two main usages of a Service is to; (1) facilitate a background operation, or (2) facilitate reuse of functionality between applications by enabling a continuous interaction with a Ser-vice through a long-lasting connection by binding to it [14]. As a SerSer-vice can be configured to run in its own separate process, a bound Service enables a client-server messaging approach through IPC. Commonly, a Service is started to perform some kind of operation but can at the same time also be bounded by multiple components and keeps on running until all compo-nents unbinds. [13]
Listing 2.4: Service component [15]
<service android:description="string resource"
android:directBootAware=["true" | "false"] android:enabled=["true" | "false"]
2.5. App components
android:exported=["true" | "false"]
android:foregroundServiceType=["camera" | "connectedDevice" |
"dataSync" | "location" | " mediaPlayback" |
"mediaProjection" | "microphone" |
"phoneCall"] android:icon="drawable resource"
android:isolatedProcess=["true" | "false"] android:label="string resource"
android:name="string" android:permission="string" android:process="string" > . . . </service>
2.5.3
Broadcast Receiver
The Broadcast Receiver component enables a publish-subscribe communication between compo-nents. An application can register a Broadcast Receiver to receive events broadcasted from either the Android OS or other applications. Furthermore, a Broadcast Receiver can either be registered through a static manifest-declaration or dynamically with a context. To communi-cate with a Broadcast Receiver, a component can send a Broadcast Intent object including an action and payload to be handled. However, as a Broadcast Receiver is only active in its host-ing process for a short amount of time, it is not suitable to perform a long-lasthost-ing background operation and should not presume that the operation is performed successfully. [16]
Listing 2.5: Broadcast Receiver component [16]
<receiver android:directBootAware=["true" | "false"] android:enabled=["true" | "false"]
android:exported=["true" | "false"] android:icon="drawable resource"
android:label="string resource"
android:name="string"
android:permission="string"
android:process="string" > . . .
</receiver>
Listing 2.6: Example Manifest-declared Broadcast Receiver [16]
<receiver android:name=".MyBroadcastReceiver" android:exported="true"> <intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/> <action android:name="android.intent.action.INPUT_METHOD_CHANGED"
/>
</intent-filter> </receiver>
Listing 2.7: Example Context-registered Broadcast Receiver [16]
BroadcastReceiver br = new MyBroadcastReceiver();
IntentFilter filter = new IntentFilter(ConnectivityManager. CONNECTIVITY_ACTION);
2.6. Bring Your Own Device
filter.addAction(Intent.ACTION_AIRPLANE_MODE_CHANGED);
this.registerReceiver(br, filter);
2.5.4
Content Provider
A Content Provider component encapsulates application data and enables sharing of data between applications [17]. The encapsulated data is stored similar to tables in a relational database. To communicate with a Content Provider, a client Content Provider object is con-structed by the interested application and enables a CRUD interaction. [18]
The two main usages of a Content Provider is either; (1) an implementation of a client object to access a Content Provider in another application, or (2) creation of a Client Provider to share data with other applications [18].
Listing 2.8: Content Provider component [19]
<provider android:authorities="list"
android:directBootAware=["true" | "false"] android:enabled=["true" | "false"]
android:exported=["true" | "false"]
android:grantUriPermissions=["true" | "false"] android:icon="drawable resource"
android:initOrder="integer"
android:label="string resource"
android:multiprocess=["true" | "false"] android:name="string"
android:permission="string"
android:process="string"
android:readPermission="string"
android:syncable=["true" | "false"] android:writePermission="string" > . . .
</provider>
2.6
Bring Your Own Device
As of Android version 5.0 (Lollipop), enterprises can provide their employees with the option of an integrated Bring Your Own Device (BYOD) solution for Android devices. Enterprises can set-up and manage so called Work profiles (or Managed profiles) for their employees, en-suring a secure environment for sensitive enterprise data and specific enterprise applications [20].
By default, there are restrictions on the communication between common user profiles and work profiles. Hence, ensuring reliable and secure IPC between applications installed in differ-ent profiles can be challenging. However, IT admins can configure which Intdiffer-ents, discussed more in depth in section 3.2.1, that are allowed to pass between these profiles. The most common issue raised by this communication restriction is so called Failed Intents. This occurs when an Intent has no handler within any of the allowed profiles and needs to be prevented by verifying that there is a suitable resolution before sending it. [20]
Listing 2.9: Example Preventing Failed Intents [20]
2.7. Best practices
// Build the "set timer" intent
Intent timerIntent = new Intent(AlarmClock.ACTION_SET_TIMER) .putExtra(AlarmClock.EXTRA_MESSAGE, message)
.putExtra(AlarmClock.EXTRA_LENGTH, seconds) .putExtra(AlarmClock.EXTRA_SKIP_UI, true);
// Check if there's a handler for the intent
if (timerIntent.resolveActivity(getPackageManager()) == null) {
// Can't resolve the intent! Fail this operation cleanly // (perhaps by showing an error message)
} else {
// Intent resolves, it's safe to fire it off
startActivity(timerIntent);
} }
2.7
Best practices
Understanding best practices for implementing secure Android applications is paramount to mitigate security vulnerabilities for each targeted device and its content. In addition to ad-dressing security measures such as Applying signature-based permissions, Disallowing access to local content providers (See Appendix 8.1.2) and Using Intents to defer permissions (See Appendix 8.1.3) [12], the ADD also presents IPC-specific Security Tips (ST) to be used when implement-ing different IPC mechanisms [21]. Furthermore, the ADD declares a more condensed form of these best practices in their so called Core App Quality Checklist (CAQC) that includes a security section with multiple different criteria to be tested against to ensure a high-quality app. Some of these criteria specific to security are [22]:
“PS-T1 - The app runs on the latest public version of the Android platform without crashing or severely impacting core functionality.”
“SC-P1 - The app requests only the absolute minimum number of permis-sions that it needs to support its use case at hand.”
“SC-DF2 - No personal or sensitive user data is logged to the system log or an app-specific log.”
“SC-AC1 - Only application components that share data with other apps, or components that should be invoked by other apps, are exported.”
“SC-AC2 - All intents and broadcasts follow best practices:
1. Use explicit intents if the destination application is well defined.
2. Use Intents to defer permissions to a different app that already has the permission.
3. Share data securely across apps.
4. Intents that contain a payload are verified before use. ...
”
“SC-AC3 - All content providers that share content between your apps use android:protectionLevel="signature" for custom permissions. This includes ac-tivities, services, broadcast receivers, and especially content providers.”
2.7. Best practices
In addition to the ADD, the non-profit Open Web Application Security Project (OWASP)1aims at improving the security of software, including mobile applications, through different com-munity lead open-source projects. Multiple generic mobile security oriented best practices can be found in their Mobile App Security Checklist (MASC)2, including security requirements specific to IPC.
1https://owasp.org/about/
3
IPC mechanisms
In this chapter, the theoretical foundation on inter-process communication mechanisms in Android will be presented.
Chapter 2 has shown how the Android OS is built on top of a custom Linux kernel, thus providing both Android and Linux specific features related to both security and rudimentary functionalities. However, as described in the ADD, there can be situations where the inher-ited Linux specific features should be avoided in favour of the Android specific ones. The ADD declares that instead of using traditional Linux IPC mechanisms such as Sockets and Shared Memory, developers should use the Android specific IPC mechanisms such as Intents, Binder or Messenger with a Service, and BroadcastReceiver. Utilising these Android specific IPC mechanisms allows the developer to secure each IPC mechanism by (1) applying a security pol-icy and (2) verifying the identity of each application requesting to utilise the IPC mechanism. [21]
Despite the directives provided in the ADD, there can be situations where an Android ap-plication will need to implement other communication methods depending on its specific situation and required functionality. The Android OS intentionally provides so called overt channels for conventional IPC and unintentionally provides so called covert channels for non-conventional IPC. Furthermore, the use of covert channels is commonly considered as an intentional method to hide malicious communication. [23][24]
3.1
Covert channels
With the primary goal of hiding the actual communication, a covert channel can be a shared resource used to secretly communicate. Hence, rather than encrypting the communication it tries to use a non-conventional communication medium to secretly communicate. Two pri-mary covert channels in Android is classified as Timing channels and Storage channels. [23][24]
3.2. Overt channels
3.1.1
Timing channels
A Timing channel is a synchronous communication method that does not require storage ca-pability, but rather exploits shared resources such as battery consumption and phone call frequency to communicate. [23]
3.1.2
Storage channels
In contrast to timing channels, a Storage channel is an asynchronous communication method that exploits shared storage such as content providers and phone call logs. [23]
3.2
Overt channels
To support conventional IPC mechanisms, the Android OS provides overt channels which is intended to be used as proper communication methods, and instead of hiding its commu-nication can be secured through security features provided by the system. The main overt channels provided is; (1) Intents, (2) Broadcast Receivers, (3) Content Providers, and (4) Remote Procedural Calls (RPC) [23]. However, several of the aforementioned channels is dependent on the first one, i.e. Intents, to be utilised properly.
3.2.1
Intents
An Intent is a messaging object which forms the glue between Android components. It con-stitutes of a passive data structure that can be sent to three out of the four app components presented in section 2.5 and carries an abstract description of an operation to be performed by the receiving component [25]. Furthermore, there are three fundamental use cases for Intents, such as (1) Starting an Activity, (2) Starting a Service, and (3) Delivering a Broadcast [26]. Depending on the situation, an Intent can be used to perform Inter Application Commu-nication (IAC) whenever the Inter Component CommuCommu-nication (ICC) expands outside the application it originates from. This in turn means that the Intent needs to hold enough infor-mation about the recipient application as well as its target component to successfully arrive at its destination within the Android OS. Depending on the level of details provided, an Intent can be classified as either implicit or explicit.
3.2.1.1 Implicit Intent
An Implicit Intent does not require details about a specific component within a specific appli-cation. It is instead declaring a somewhat general action to be performed by any component that is set to handle it. In parallel, other applications can declare so called intent-filters that is set to filter Intents for that specific action. Furthermore, the Android OS automatically finds the appropriate component to start through a process called Intent resolution. This pro-cess tries to match the Implicit Intent with any of the declared intent-filters [25]. However, if there exists multiple applications with the same intent-filter, the Android OS lets the user pick which application that should handle that Implicit Intent. [26]
Listing 3.1: Example Implicit Intent [26]
// Create the text message with a string
Intent sendIntent = new Intent();
sendIntent.setAction(Intent.ACTION_SEND);
sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage); sendIntent.setType("text/plain");
3.2. Overt channels
if (sendIntent.resolveActivity(getPackageManager()) != null) { startActivity(sendIntent);
}
Listing 3.2: Example Intent Filter [26]
<activity android:name="ShareActivity"> <intent-filter>
<action android:name="android.intent.action.SEND"/>
<category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="text/plain"/>
</intent-filter> </activity>
3.2.1.2 Explicit Intent
In contrary to Implicit Intents, an Explicit Intent holds information about a specific compo-nent that could pertain to either an internal compocompo-nent or a compocompo-nent located in another application [26].
Listing 3.3: Example Explicit Intent [26]
// Executed in an Activity, so 'this' is the Context
// The fileUrl is a string URL, such as "http://www.example.com/image.png"
Intent downloadIntent = new Intent(this, DownloadService.class); downloadIntent.setData(Uri.parse(fileUrl));
startService(downloadIntent);
3.2.2
Broadcast Receiver
As described in section 2.5.3, Broadcast Receivers is used to receive broadcast Intents sent by an application component or the Android OS itself. Hence, it can be used in conjunc-tion with the Intent mechanism to provide IAC through IPC. As of Android 8.0 (API 26), the Android OS imposes a greater restriction on Manifest-declared Broadcast Receivers in an at-tempt to make the component more secure. Consequently, most of the Android OS specific implicit broadcasts can no longer be received. In addition to added declaration restrictions, a Broadcast Receiver can be secured with the use of permissions or package specification on a broadcast Intent. This protects against unauthorised access through the need for a match-ing permission on the incommatch-ing Intent or assignmatch-ing a specific package when sendmatch-ing one to interested components. [16]
Listing 3.4: Example Broadcast Intent with Permission [16]
sendBroadcast(new Intent("com.example.NOTIFY"), Manifest.permission. SEND_SMS);
// The receiving component needs to request the following permission
<uses-permission android:name="android.permission.SEND_SMS"/>
3.2.3
Content Provider
As described in section 2.5.4, a Content Provider can be used to share data with other appli-cations by allowing access to its application data through client objects. To gain access to a specific Content Provider, a Content URI is used to identify its data and a Content Resolver
3.2. Overt channels
resolves the used URI, matching it to the correct publicly available provider in the system. Hence, gaining access to a public Content Provider is not by default restricted to its own iso-lated component. To enable secure communication and block unwanted access, the Content Provider can demand custom read and write permissions pertaining to that specific Content Provider component. Whenever a Content Provider component has declared the need for a specific permission, the requesting application needs to have been granted that permission by declaring it using a permission tag in its manifest. [18]
Listing 3.5: Content URI syntax [27]
content://authority/path/id
3.2.4
Remote Procedure Calls
As described in section 2.3, each application is by default running in its own process and restricted to its own sandbox environment. However, the Android OS provides the possibility to perform so called Remote Procedure Calls (RPC) that can be invoked locally but executed in another process [23][28]. The data objects communicated between these processes needs to be decomposed into primitives that the Android OS can understand. There exists three mechanisms in different abstraction layers to facilitate this procedure; (1) Binder, (2) AIDL, and (3) Messenger [29].
3.2.4.1 Binder
The Binder mechanism is supported by a Binder driver in the Linux kernel. It runs in the same process as the calling component and enables execution of RPC within a single application without the support of multi-threading [30][13]. Moreover, a Binder needs to be implemented in the context of a Service, Activity, or a Content Provider to let the system know it should remain running. The Binder mechanism is commonly used in the context of a background Service which allows other components to interact with remote methods in a client-server manner [23].
3.2.4.2 AIDL
In order to function properly, any communication needs to be performed in such a way that all communicating parties understand each other. By designing a custom Interface with the use of Android Interface Definition Language (AIDL), the format of the communication can be agreed upon to support RPC between applications and enabling concurrent IPC with the support of multi-threading [29][23]. AIDL facilitates the procedure of decomposing objects into primitives that the Android OS can understand and supports all primitive types in Java, Arrays (of primitive types), String, CharSequence, List (of primitive types), Map (of primitive types). As of Android 10 (API 29), AIDL supports the Parcelable object which enables communication of custom classes between processes through IPC [29].
AIDL can be used with a background Service to perform marshalling and unmarshalling of data between processes. As mentioned previously, AIDL supports concurrent IPC through multi-threading and therefore requires the background Service to be thread-safe. Hence, it is only used in scenarios where a remote Service is needed to handle multiple requests simulta-neously. [31][29]
Fundamentally, the AIDL mechanism uses the Binder driver to make calls which (similar to the Binder mechanism) enables a client-server approach where a server process registers an interface which a client process can make calls to. [32]
3.3. Threats
3.2.4.3 Messenger
The Messenger mechanism serves a Handler object within each calling process to enable message-based communication between processes [33]. Each Handler is associated with a message queue within a single thread [34]. Implementing a Messenger object merely points to a Handler reference which can be handed over to another process to delegate communica-tion. Hence, there are no methods to be called but instead a Message object is marshalled by the dedicated Messenger [31]. Moreover, the underlying mechanics are based on the Binder mechanism to perform lower-level IPC. In contrast to the AIDL mechanism, the Messenger mechanism is used whenever concurrent IPC is not required and the complexity of handling multi-threading is unwanted [31].
3.3
Threats
Every single IPC mechanism presented in section 3.2 relies on at least one of the core compo-nents provided in section 2.5. Understanding which of the identified threats that affects each core component is therefore crucial for the purpose of achieving secure IPC.
Despite its application sandboxing and permissions framework for managing IPC in a se-cure and effective way, the Android OS is vulnerable to a variety of different security threats affecting confidentiality, integrity, and availability, if not mitigated adequately.
3.3.1
Activity Hijacking
In a Activity Hijacking scenario, a malicious Activity is registering a suitable Intent Filter to intercept Implicit Intents sent by another application and effectively replacing the intended Activity [35][23]. Hence, it can result in data leakage malicious data injection, or unusable func-tionality [36][37].
3.3.2
Malicious Activity Launch
In an Malicious Activity Launch scenario, a malicious Activity is launched within another ap-plication with the use of forged Explicit or Implicit Intents. The resulting consequences can be data leakage, modification of application state, or data manipulation. [23][36]
3.3.3
Broadcast Hijacking
The act of Broadcast Hijacking, also called Broadcast Theft [38][36], involves the interception of public broadcasts to perform eavesdropping or denial-of-service (DoS) attacks [23][38]. In other words, a malicious application can register a Broadcast Receiver with an suitable Intent Filter to hijack broadcasts and access their payloads. Hence, it can result in data leakage or unusable functionality [36][39].
3.3.4
Malicious Broadcast Injection
In a Malicious Broadcast Injection scenario, a malicious broadcast Intent is sent to a public component [36]. Some broadcasts are sent by the Android OS to notify applications about changes in device state, a component can therefore make itself public to be able to receive such events. However, sending a malicious broadcast Intent with an empty action description can trick vulnerable components to perform actions which are only meant to be triggered by sys-tem broadcasts. Hence, failure to verify incoming Intents properly might result in malicious data injection and modification of application state [39][36]. Moreover, as Broadcast Receivers are sometimes used to broadcast incoming data to other components, such as Activities and
3.4. Security testing
Services, it induces a security threat where malicious data can be propagated throughout the entire application [35][36].
3.3.5
Service Hijacking
Service Hijacking is similar to Activity Hijacking as it involves intercepting Implicit Intents, and as a result creates a connection to the victim application [35][23]. Unlike Activities, Services run in the background of an application and can therefore be unapparent to users. Similar to other Hijacking threats, Service Hijacking induces a security threat that involves the use of eavesdropping and DoS attacks. Hence, it might result in data leakage, malicious data injection, or unusable functionality [36][23].
3.3.6
Malicious Service Launch
As mentioned in section 2.5.2, a Service can be bound by a component to provide a client-server connection. In a Malicious Service Launch scenario, a malicious component binds to an exposed and vulnerable Service [35]. As Services are used as background servers, the infor-mation sent to the Service can be of high interest to a malicious application. The implication of this threat is data leakage, modification of application state, or data manipulation. To mitigate this, a Service needs to be secured properly by either making it private or assigning a signature level permission to restrict unauthorised access. [35][36]
3.3.7
Content Provider Hijacking
In a Content Provider Hijacking scenario, a malicious application obtains access to an exposed and vulnerable Content Provider. Hence, whenever a public Content Provider is not pro-tected adequately with a signature level permission the resulting consequences can be data leakage or data manipulation. [40][41]
3.3.8
Identical Custom Permission
As mentioned in section 2.4, an Android application can request install-time custom permis-sions without the need of a user interaction during runtime. However, this does not restrict other applications from creating identical custom permissions with or without a malicious in-tent. Furthermore, when multiple applications have defined identical custom permissions, whichever is installed first is the one whose definition is used [40]. This enables other ap-plications to access protected components outside of their own application sandbox if not protected properly. Assigning a signature protection level to each vulnerable component is therefore required to protect them sufficiently as it requires that the application trying to in-teract with that component is signed with the same certificate as the application providing that component [10].
3.4
Security testing
Security testing aims at detecting vulnerabilities within a system that could threaten its se-curity in relation to relevant sese-curity properties. It involves the process of testing the system by taking on the role of an attacker. Hence, security testing is used to verify if a security property is upheld or violated. This can be achieved by either (1) showing conformance with the security properties or (2) addressing known vulnerabilities. Furthermore, security testing can be divided into two types of approaches, i.e. (1) Security functional testing or (2) Secu-rity vulnerability testing. With the aim of showing conformance with each secuSecu-rity property, Security functional testing verifies whether the system under test (SUT) has been implemented correctly. Whereas, Security vulnerability testing aims at identifying any vulnerabilities in the
3.4. Security testing
SUT by performing penetration testing with the role of an attacker trying to attack and exploit potential vulnerabilities. [42][43]
The most common security properties used to devise security requirements of a system and tested for in security testing is the CIA-triad. It includes the three core security properties; con-fidentiality, integrity, and availability. These are their definitions presented in the ISO-standard ISO/IEC 27000:2018 [44]:
“Confidentiality - property that information is not made available or disclosed to unauthorized individuals, entities, or processes.”
“Integrity - property of accuracy and completeness.”
“Availability - property of being accessible and usable on demand by an au-thorized entity.”
The perspectives taken when performing any type of security testing can be divided into two principal testing techniques, i.e. White-box testing and Black-box testing (or a combination of the two called Grey-box testing). The former White-box testing technique takes on the perspective where access to information about how the SUT has been designed or coded is provided and used to perform targeted tests. In contrast, the Black-box testing technique does not have access to any information about the internals of the SUT. [42]
3.4.1
Penetration testing
Penetration testing is an established testing technique that involves the action of trying to attack and exploit potential vulnerabilities in the form of a malicious third party. It can be performed as both a White-box testing technique as well as a Black-box testing technique de-pending on the level of information used when testing the SUT. A prerequisite for penetration testing is that the SUT is close to production ready with a complete set of features, enabling execution of all required workflows. [42]
Figure 3.1: The four phases of penetration testing.
As shown in Figure 3.1, the process of penetration testing can be divided into the following four phases [42]:
1. The Planning phase is used to determine the scope of the SUT and the invasiveness of the attacks to be performed.
2. The Discovery phase involves two parts. The first part aims at discovering the initial at-tack surface of the SUT. The second part targets vulnerability analysis to identify potential vulnerabilities to be tested.
3. The Attack phase utilizes the identified vulnerabilities to perform targeted attacks in an attempt to compromise the SUT. Should an attack be successful, each related security
3.4. Security testing
vulneraibility is then exploited to highlight new discoveries and potentially expose an elevated attack surface to be attacked.
4. The Reporting phase is used to present the information documented during the previous phases along with an estimated severeness of exploited security vulnerabilities.
3.4.1.1 Drozer
Drozer, formerly known as Mercury, is an open-source security assessment framework for the Android OS. As shown in Figure 3.2, Drozer consists of a CLI console and an Android application called the agent that contains an embedded server running on TCP-port 31415. The agent application enables interaction with other applications to simulate the role of a malicious application. Drozer is built with a modular approach in mind, where different types of security assessment techniques is provided through a dedicated so called Module. For example, it allows you to determine the attack surface of an Android application through the use of its AttackSurface-module which identifies any exported components, and more. [45]
Figure 3.2: The Drozer framework.
The results of a successful attack can be quite different depending on the module used. List-ings 3.6, 3.8, and 3.9 shows example results of different attacks using the Drozer framework.
Listing 3.6: Example result using the Send-module on a Service.
dz> run app.service.send com.example.srv com.example.srv.Service --msg 1 2 3 --extra float value 0.1324 --extra string test value
Got a reply from com.example.srv/com.example.srv.Service: what: 1
arg1: 2 arg2: 3 Data:
value (float) : 0.1324 test (string) : value
Listing 3.7: Example result using the Send-module on a Broadcast Receiver.
dz> run app.broadcast.send --action android.intent.action.BOOT_COMPLETED java.lang.SecurityException: Permission Denial: not allowed to send broadcast android.intent.action.BOOT_COMPLETED from pid=955, uid=10044
Listing 3.8: Example result using the Sniff -module on a Broadcast Receiver.
3.5. Related work
[*] Broadcast receiver registered to sniff matching intents [*] Output is updated once a second. Press Control+C to exit.
Action: android.intent.action.BATTERY_CHANGED
Raw: Intent { act=android.intent.action.BATTERY_CHANGED flg=0x60000010 (has extras) }
Extra: technology=Li-ion (java.lang.String) Extra: icon-small=17303411 (java.lang.Integer) Extra: health=2 (java.lang.Integer)
Extra: online=4 (java.lang.Integer) Extra: status=2 (java.lang.Integer) Extra: plugged=2 (java.lang.Integer) Extra: present=true (java.lang.Boolean) Extra: level=80 (java.lang.Integer) Extra: scale=100 (java.lang.Integer) Extra: temperature=280 (java.lang.Integer) Extra: current_avg=460 (java.lang.Integer) Extra: voltage=4151 (java.lang.Integer) Extra: charge_type=1 (java.lang.Integer) Extra: invalid_charger=0 (java.lang.Integer)
Listing 3.9: Example result using the Query-module on a Content Provider.
dz> run app.provider.query content://com.mwr.example.sieve. DBContentProvider/Passwords/ --vertical
_id: 1 service: Email
username: incognitoguy50
password: PSFjqXIMVa5NJFudgDuuLVgJYFD+8w== (Base64-encoded) email: incognitoguy50@gmail.com
3.5
Related work
The IPC mechanisms presented in this thesis not only facilitate ICC within a single appli-cation but also between multiple appliappli-cations, thus enabling IAC. Similar work of utilising said IPC mechanisms has been performed. Singapati [46] investigated the possibility to de-velop Android applications with functionality that could be shared with other applications through IPC. An example application was developed that utilised the AIDL and Messenger IPC mechanisms together with a background Service to successfully communicate with appli-cation components in separate processes. Moreover, he concluded that IPC could be achieved using mechanisms provided by the Android OS instead of implementing traditional Linux based IPC mechanisms. In contrast to this thesis however, additional IPC mechanisms and related threats were not investigated.
Kristiansen et al. [47] examined the feasibility of developing multiple smaller applications instead of one big to enable a secure and user-friendly SSO experience. However, their work is mainly focused towards the usability of an SSO experience utilising the Content Provider mechanism to manage token communication. Moreover, they conclude that an SSO solu-tion with multiple smaller applicasolu-tions can be as secure as one big when mitigating threats through the use of Android OS signature permission protection. In addition, they recommend future work involving the addition of a background Service to facilitate the authentication flow.
3.5. Related work
In addition to SSO related work, there have been multiple attempts at analysing the IPC related threats by mainly focusing on IAC [35][39][48][49][37][23][38][36][50]. Bhandari et al. [23] performed a survey to highlight several key IAC threats by assessing the strengths and weaknesses of current state-of-the-art IAC analysing techniques. They conclude that the security concepts provided by the Android OS exhibits shortcomings due to its reliance on decisions made by the end user for granting permissions. Hay et al. [49] investigated the pos-sibility to detect IAC vulnerabilities affecting the integrity of an IAC channel. They developed a framework named IntentDroid that dynamically analyses Android applications. However, their work only focused on communication related to the Activity component, and as a result indicated future work should be performed on the remaining application components.
4
Method
In this chapter, the method of implementation and the security evaluation of all identified IPC mechanisms described in Section 3.2 is outlined.
As the Android OS is a rapidly changing system, this thesis has focused its implementation and evaluation on the (at the time of writing) latest version of Android. Hence, the identi-fied IPC mechanisms and the SSO solutions have been implemented and evaluated using a Google Pixel 4a device running Android 11 (API level 30). Furthermore, the implementation has been performed using Android Studio version 4.1.2 on a virtual machine environment running Ubuntu 20.04.1 LTS.
4.1
Implementation
To answer the research questions, multiple SSO solutions have been implemented with each identified IPC mechanism as its core mechanism to enable IAC communication across pro-cesses.
The implementation of each IPC mechanism and its supporting components is primarily based on the available developer documentation provided by the Android Developer Doc-umentation (ADD)1 and the Android Open Source Project (AOSP)2Documentation as it is comprehensive and directly linked to the developers of the Android OS.
As described in Section 3.2, the Android OS provides different overt channels to enable IPC across applications. The implementation of each corresponding IPC mechanism is dependent on the communicating components and their specific implementation. To achieve a distinct implementation flow and replicability, each IPC mechanism is implemented using a scalable SSO structure with a joint Authorization server and a dedicated Authentication solution, such as Firebase Authentication3. Two almost identical client applications are implemented to en-able IAC with a server application. A background Service configured to be running in its own
1https://developer.android.com/docs 2https://source.android.com/
4.1. Implementation
process of which a client application can bind to, as a result making it a bound background Service, is implemented to enable long lasting background operations highly suited for an SSO authentication flow. Each SSO solution is thereby implemented using a bound back-ground Service to perform the authorization verification with the dedicated back-end server. Also, each SSO solution provides an Authenticator application to provide the aforementioned background SSO Service as one of its components and effectively list all the connected client applications as well as displaying the current authentication state and its related user informa-tion.
4.1.1
System Requirements Analysis
To validate the implementation of each IPC mechanism in its SSO solution, a system require-ments analysis was performed focusing on core SSO functionalities to communicate sensitive data, i.e. authentication state and user information, between applications. With the basis of ensuring functional IAC through IPC, thereby enabling the implementation of a SSO solution, the following somewhat obvious functional requirements were given each IPC mechanism:
IPC-R 1 Communicate an action to be performed by the SSO Service.
IPC-R 2 Send sensitive data across application boundaries to the SSO Service.
IPC-R 3 Receive sensitive data from the SSO Service initiated by another application.
IPC-R 4 Keep in sync with the SSO Service about the current authentication state and user information.
Regardless of which IPC mechanism that was communicating with the SSO Service, the SSO Service had to be able to accurately perform the requested actions to authenticate a user and provide basic SSO functionalities. Hence, the following requirements were placed on the SSO Service to enable a scalable solution:
SSO-R 1 Handle incoming calls to perform the correct operations with back-end server without erroneous behaviour.
SSO-R 2 Maintain access to all client applications in order to update them with the cur-rent authentication state and user information.
SSO-R 3 Automatically update all client applications of current authentication state and user information.
SSO-R 4 Be able to Sign In a user with an email and a password.
SSO-R 5 Be able to Sign Out an already authenticated user.
4.1.1.1 Security requirements
As each IPC mechanism was implemented with the purpose of creating a secure communi-cation between applicommuni-cations to enable a SSO solution, security requirements (S-R) for each implemented SSO solution needed to be devised in addition to its functional requirements presented above. The CIA-triad was used as a basis to devise each S-R. Also, some of the IPC-R and SSO-R requirements undeniably rely on the following security requirements:
S-R 1 Valid credentials should allow an authorized user access to confidential informa-tion.
4.2. Evaluation
S-R 2 Invalid credentials should deny access to any confidential information.
S-R 3 Sensitive data communicated between applications should be accurate.
S-R 4 Sensitive data communicated between applications should be complete.
S-R 5 Authorized applications should be allowed access to the server application.
S-R 6 Unauthorized applications should be denied access to exported components.
S-R 7 Unauthorized applications should be prohibited to obtain sensitive data, either stored or communicated between applications.
S-R 8 Unauthorized applications should be prohibited to modify sensitive data, either stored or communicated between applications.
S-R 9 Unauthorized applications should be prohibited to delete sensitive data, either stored or communicated between applications.
S-R 10 Authentication state should be synchronized.
4.1.2
Mitigating threats
To be able to answer RQ2, the identified threats presented in Section 3.3 have been addressed using up-to-date information provided by the ADD and the OWASP MASC. Complemen-tary insights and mitigation approaches have been obtained from relevant research literature focusing on Android related threats and vulnerabilities. For example, Khadiranaikar et al. [51] provided their insights into the development of an Android application and presented a collection of recommendations for securing IPC related to Intents.
4.2
Evaluation
The evaluation part of this thesis is focused on the security and performance of each SSO so-lution and subsequently each implemented IPC mechanism. The security aspect has been evaluated through a security testing approach divided into two parts, i.e. security functional testing and security vulnerability testing via the use of penetration testing.
4.2.1
Functional testing
Each SUT has been tested against some of the devised security requirements presented in Sec-tion 4.1.1.1 to ensure correct behaviour and the level of conformity with the corresponding security property presented in Section 3.4.
Table 4.1 shows five functional tests with a pre-defined set of conditions to be used in each test as well as the corresponding result to achieve in the form of two types of actions (or states). Each condition was set to either be true (T) or false (F) and the expected resulting action is indicated with an x. The tests number 2 and 4 can be seen as dependent parts of tests number 1 and 5 but highlights the granularity of the authentication process with each SUT.
4.2. Evaluation
Table 4.1: Functional tests performed on each SUT.
4.2.2
Penetration testing
The security of each IPC mechanism was tested through a penetration testing technique us-ing a Grey-box approach to determine the level of conformity with each CIA-triad security property presented in Section 3.4.
The Drozer security framework was used to perform a form of Grey-box penetration testing acting as a malicious attacker without prior programming knowledge and with some infor-mation about the internals, otherwise accessible through reverse engineering.
Planning
All the performed penetration tests are targeting each SSO solution as the SUT with a more specific scope of targeting both the server application, i.e. Authenticator application, and one of the identical client applications separately as the application under test (AUT).
Discovery
Multiple different Drozer modules were used to disclose detailed information about the at-tack surface and any potentially vulnerable components by checking their exported state, i.e. either directly declared as exported=true or indirectly with the use of intent-filters. Detailed notes were taken of all exported components and specifically any component unprotected by a potentially insufficient permission to exploit in our attacks. Also, as the SSO Service is implemented in all SSO solutions, the information pertaining to that component is uni-formly identified at step D 3 listed below. Table 4.2 shows all the steps taken to perform the Discovery-phase for each AUT.
Table 4.2: Steps taken during Discovery-phase using Drozer.
Attack
As the SSO Service is present in all SSO solutions through the server application, the at-tacks aimed towards that Service component were uniform across each SUT. Hence, with the information gathered in the initial Discovery-phase, the attacks performed on the exported components is correlated to the relevant threats presented in Section 3.3.
4.2. Evaluation
Table 4.3 shows each attack with its corresponding component-specific Drozer module along with the targeted IPC mechanism as well as the type of threat it tries to simulate and the tested security requirements. Note that the two additional threats presented in Sections 3.3.1 and 3.3.2 related to the Activity component were not simulated in the Attack-phase as they are unable to cause a vulnerability in the SUT due to no additionally implemented Activities. Also, the threat mentioned in Section 3.3.8 is not addressed in the aforementioned Table but instead tested prior to performing the following attacks to ensure that a malicious application is unsuccessful at declaring an identical custom permission that could potentially enable ele-vated exploits. Note that all IPC mechanisms is tested against the three security requirements S-R 5, 6, and 7 as the SSO solution is set to synchronize the initial authentication state once a connection to the SSO Service has been established. Hence, successful A 1 and A 2 attacks would subsequently enable the attacker to obtain, modify or delete sensitive data handled by the SSO Service in which each IPC mechanism is communicating with.
Table 4.3: Attacks performed during penetration testing using Drozer.
Reporting
The Reporting-phase is fulfilled not only through the Reporting part presented in Section 5.2.2, but also by the information provided in Sections 4.2.2 and 4.2.2.
4.2.3
Performance analysis
4.2.3.1 Execution Time
The Execution Time, or Wall Duration, of each IPC mechanism implementation was evaluated through the use of Android Studios built-in Profiler4with custom Trace-sections5added to the source code of each SUT. In order to minimize potential corruption of measured execution time, the communication with the authorization server provided by Firebase Authentication is mocked to remove any variety in network response time.
Both the server application and one of the almost identical client applications was used to individually measure the execution time for the two authentication processes of Signing In and Signing Out a user. Each authentication process was performed five times sequentially and used to calculate an average Wall Duration, i.e. elapsed real time. No other CPU intensive processes were ensured to be running while performing each authentication process to mit-igate any additional CPU wait-time that could potentially corrupt the measured execution time.
4https://developer.android.com/studio/profile/android-profiler 5https://developer.android.com/reference/android/os/Trace
4.2. Evaluation
4.2.3.2 Lines of Code
The Lines of Code (LOC) metric was used to determine the degree of complexity required by each IPC mechanism implementation. Regardless of the number of required classes or method-calls, each IPC mechanism was implemented in such a way that each commonly performed action, e.g. Sign In and Sign Out, had a single dedicated method if not otherwise required by the IPC mechanism. Hence, measuring the LOC of each implementation was used to understand the general complexity and overhead of source code required to enable a secure SSO solution with each IPC mechanism.
The Android Studio plug-in Statistic6was used to calculate the LOC of each implementation by only calculating the executable lines of code, i.e. excluding any blank-lines or comments, in both Java source code as well as relevant XML source code, e.g. the Manifest.
