Next Generation Smart Devices

Submitted by

Swati Gaur

Enrollment No 2014MTCSE021

Thesis Supervisors

Dr Karan Verma amp Gaurav Somani

A Thesis Submitted in Partial Fulfilment of the Requirements for the award of the

Degree of

Master of Technology

in

Computer Science and Engineering

Department of Computer Science and Engineering

School of Engineering and Technology

Central University of Rajasthan

May 2016

CANDIDATErsquoS DECLARATION

I hereby declare that the work presented in this dissertation report entitled

ldquoNext Generation Smart Devicesrdquo in partial fulfilment for the award of

degree of ldquoMaster of Technologyrdquo in Computer Science and Engineering

with specialization in Information Security and submitted to Department

of Computer Science and Engineering School of Engineering and Technol-

ogy Central University of Rajasthan is a record of my own investigation

carried under the Dr Karan Verma- Assistant Professor Central Univer-

sity of Rajasthan MTech (CSE) from IIT Roorkee PhD from Universiti

Teknologi PETRONAS in Malaysia IETF IEEE-ISOC

I have not submitted the matter presented in this dissertation anywhere

else for the award of any other degree

Date May 9 2016 Swati Gaur

Place Central University of Rajasthan Ajmer 2014MTCSE021

I Swati Gaur understand that plagiarism is defined as any one or the

combination of the following

1 Uncredited verbatim copying of individual sentences paragraphs or

illustrations from any source published or unpublished including the

Internet

2 Uncredited improper paraphrasing of pages or paragraphs

3 Credited Verbatim copying of major portion of the paper without clear

definition of who did or wrote that I have made sure that all the

ideas expressions graphs diagrams etc that are not result of my

work are properly credited Long phrases of sentences that had to be

used verbatim from published literature have been clearly identified

using quotation marks

I affirm that no portion of my work in minor project titled ldquoNext Gen-

eration Smart Devicesrdquo can be considered as plagiarism and I take full

responsibility if such a complaint occurs I understand very well that the

minor project advisor may not be in a position to check for the possibility

of such incidences of plagiarism in this body of work

CERTIFICATE

This is to certify that the dissertation report entitled ldquoNext Generation

Smart Devicerdquo done by Swati Gaur Enrolment No

2014MTCSE021 is an authentic work carried out by her at Central Uni-

versity of Rajasthan Ajmer under my guidance The matter embodied in

this minor project work has not been submitted earlier for the award of any

degree to the best of my knowledge and belief

Date 9 May 2016 Dr Karan Verma

Assistant Professor

Central University of Rajasthan Ajmer

Acknowledgements

This dissertation report I present here would not have been possible with-

out the support of several person whom I would like to thank Foremost

It is my privilege to express my sincere thanks and gratitude to my highly

intellectual supervisors Dr Karan Verma amp Gaurav Somani (mentor)

for being so kind and giving generous support to accomplish my Goals

they are Down to Earth Intern-ship supervisors Prof Manoj Singh

Gaur and Associate Prof Vijay Lakshmi MNIT Jaipur Other fac-

ulty members of CSE department Prof Manish Dev Shrimali (Dean

and HEAD) of School of Engineering amp Technology Ravi Saharan (Co-

ordinator) Dr Muzzammil Hussain Ginika Mahajan and Harish

Sharma I am grateful and highly obliged for their trust support oppor-

tunities and the guidance in all the time of the thesis work Internal Ex-

aminers of CS department Dr Ravi Raj Choudhary Dr Nagaraju Anand

Sharam and others for their motivation enthusiasm and immense knowl-

edge Furthermore I am thankful for the visiting faculties Prof Abdul

Sattar from Griffith University Dr Mahesh Chandra Govil (Head)

of CSE dept in MNIT Jaipur Dr Kumkum Garg (Pro President) of

Manipal University in Jaipur Prof Anil Kumar Tiwari from IIT Jodh-

pur for encouraging my dissertation work I gratefully acknowledge to my

Super-seniors Vikas Jaimann (Milestone of CSE dept) Shweta Saharan

Reena Rathore Aditya Ranjan Vineet Saini Abdul Quyoom Raja Ali

and others for giving motivational talk in their area of interest Finally

most importantly I am indebted to my family for all the encouragement

and moral support spiritually all the time

Swati Gaur

ABSTRACT

Smart devices are inevitable in our fast pacing life and plethora of world

wide data resides in the pocket operating system aka Smartphone next

wave of computer can be ease using hand-held mobile gadgets Computing

and non-computing elements will be socket connected therefore revolution-

izing Internet of Things (IOT) Privacy protection tactics is not significant

require transparency in dashboard amp controller The role of the actor and

subject influences its visibility protection and trust whereas sustainabil-

ity issues raised by web tracking by third parties using cookies Big data

exploitation by blocking legislation standardization is not viable tactics

that can hurt the ecosystem Juice caster attack towards automatic us-

ing projector that steals sensitive information charging attack caused by

micro USB connector using Mobile high-definition link (MHL) can steal

the data by capturing display screen Lightning attack using connector

is feasible in Android OS iOS Fault Injection (obfuscation techniques)

Screen-milker attack can be initiated by monitoring the screen and pick

up the user credentials and leads to side channel motion on touch screen

Smartphones with a soft keyboard Bluejacking and sniffing is unaffordable

by any human-driven analysis are require to combat Android ramping up

the competition to develop next wave technologies it prominently thriv-

ing research area with suitable amount of pileup flaws in Android software

stack that are unsolved To combat these vulnerabilities we overlook the

Honified tool that provides fine-grained component level access control The

Honified is derived from the concept of Honeypot that is made for being

attacked and compromise the security It lures the attacking application

and further it is used to provide the resilient as well as robust access control

at Stock Android Honified uses the concept of In-app reference monitoring

aka Inline reference monitoring it also thwarts the dissemination of private

data of the user and prompts the user to uninstall the app to reduce mon-

itoring overhead Delta Microbenchmark shows that overall score of work

with Honified tool achieved 9689 that is quite affordable

Contents

Contents vi

List of Figures viii

List of Tables x

Nomenclature x

1 Introduction 1

11 Introduction 1

111 Our Contribution 2

112 Assumptions 3

12 Inter-Application Communication (IAC) Attack Surface 3

121 Inter-App communication in Android 3

122 IAC vulnerabilities and Attacks 4

123 Motivating Example 5

13 Requirement Analysis amp its ingredients 6

131 General defence techniques 6

2 Literature Survey amp Review 8

21 Android Platform background security and weaknesses 8

211 Androidrsquos Security model 10

212 Android Security Weaknesses 11

213 Android Security Guidelines 12

23 Attack classification 14

24 Static Taint Analysis 14

25 Capability leaks 16

vi

CONTENTS

26 Stack Investigation 16

27 Application level privilege escalation attack 16

271 Detection 16

272 Prevention 17

28 Application and kernel level privilege escalation attack 17

281 Detection 17

282 Prevention 17

3 Proposed Methodology 20

311 Honified Architecture 20

312 Design amp Implementation 21

313 Proposed Algorithm amp its work flow 26

4 Evaluation 29

41 Evaluation 29

411 Case Study 32

42 Performance 34

4201 Functionality 34

4202 Size 39

421 Portability 39

4211 On Device amp Off Device Deployment 39

4212 App Store 40

4213 Development time Deployment 40

5 Conclusion and Future work 41

References 42

vii

List of Figures

11 Attack Scenario 1 5

21 Android Architecture Diagram 9

22 Android Security Model 10

23 Application level privilege escalation attack classification 15

24 Literature Review and Literature Survey 18

32 Honified Work Flow 21

33 Preprocessing of Apk 23

34 App transformation 24

35 Dynamic analysis 25

41 Application escalating privileges 33

42 Honey-App handles privilege escalation 33

45 Launching before Honified 35

46 Launching after Honified 36

47 IPC before Honified 37

48 IPC after Honified 38

viii

List of Algorithms

1 Honified algorithm 26

2 Honey app Algorithm 27

ix

List of Tables

21 Comparative study of state-of-the-art research 19

41 IACBench-master Apps dataset detecting Implicit Intent 30

42 Buggy Genome App dataset 32

43 Supported Android version of Honified 39

x

Chapter 1

Introduction

11 Introduction

Smartphones have become necessary gadget and Android have reached with 82 of the

worldwide sales in 2Q15 market share [1] With this extensive growth of the Android

Smartphone targets prodigious amount of malware For example Samsung HTC LG

Huawei and ZTE devices running version up to 51 were rendered susceptible due to its

exploitation of flows present in buggy apps that elevate attackerrsquos permissions under-

neath the user [2] Similarly Gartner estimated that the growing interest of IOT may

significantly increase of smartphone to be reach 26 billion by 2020 [3] and will connect

the userrsquos home appliances with Android device [4] A portable home device manage-

ment system that connect home devices with the Smartphones via internet [Chen et al

2016] There are health-care applications which serve the patients and facilitates them

with the medical thing by tracking to its nearby places [Laplante and Laplante2015]

Social internet of the vehicle (IOV) requires interaction between the vehicle and the

drivers Furthermore the electronic devices home appliances auto mobiles are becom-

ing interconnected and ubiquitous using novel applications that can undoubtedly have

security issues [Maglaras et al2016] Android Applications are mainly written in Java

but another potential vulnerability resides in the Android Applications is due to the

presence of native code which is commonly written in C or C++ via Java Native Inter-

face(JNI) Researchers have notified about another flaw called OpenSSLX509Certificate

present in the Android Platform that influence over 55 of the end users Further-

more it compromises the security of the system amp replaces the malicious apps with

the other popular apps eg facebook to steal social networking login credentials [8]

Soundcomber is a context aware sound trojan that extracts the credit card credentials

1

and uses innocuous permission from being detected and it utilizes other application to

send extracted information from the device [SoundComber Schlegel et al 2011 ]

The IBM Security X-Force Research team have discovered that the 10 Banking

Apps build on Apache Cordova platform is susceptible to steal sensitive data from the

users remotely[10] Android malware performs split personality attack to elude malware

scanner in the android virtual device and it performs attacks in real device [Maier et al

2015] Every application is comprised of a set of permissions which is displayed to

the user before installation of an application [Felt et al2011] After approval of all

the permissions user can install the application without further modification of these

permissions which serves the purpose of security [Felt et al2012]

Android security requires major concern in such scenarios where a malicious ap-

plication in the device may not just steal the private data credit card details login

credential or inject some code but can affect physical safety or security [Vylegzhanina

et al2015] In fact the security model of the Android device and its applications are

having diverse shortcomings In order to overcome these shortcomings we are propos-

ing a resilient solution to protect the privacy of the users and the exploitation of the

buggy but legitimate applications

111 Our Contribution

In this Paper we are proposing Honified tool that provides component level access

control mechanism to prevent intent vulnerabilities and dissemination of private data of

the user The proposed Honified tool is based on the concept of a honeypot Honeypot

system appeals the attacker to compromise the security and detects unknown attacks

[Mulliner et al2011] Firstly we have utilized AAPT tool available in Android to

find the meta-data of android application we have leveraged in-line reference monitor

resides in middle layer of an Android OS and embed it into Application that was found

it to be vulnerable using APKtool[16] In-line reference monitoring concept avoids the

hindrance of Android platform security extension and mediates ICC to provide access

control at middleware Layer [Davis et al2012 Backes et al2012 Seo et al2016 Jeon

et al2012] Whereas modification to the Android platform framework is complicated

and challenging that requires rooting of the device There are existing techniques

that embody in-line reference monitoring [Davis et al2012] but they use in the main

launching activity of an application that increases the unnecessary overhead at the

launching time of an application

2

112 Assumptions

We are utilizing SELinux found in Android version (44 and above) to provide access

control at the kernel level whereas SELinux can be disabled temporarily from enforce-

ment mode to permissive mode We are not preserving the integrity of an application

having origin from the same developer which is not our scope and it will be further

negotiable with the developer to share the common key for a signature of an application

12 Inter-Application Communication (IAC) Attack Sur-

face

Android is a Linux-based operating system which is developed by Google to encour-

age various applications to share their functionality with other applications for the

re-usability of the existing code The applications which are involved in sharing data

with other application should tightly restrict their component with the permissions

But a generally application developer cannot decide what permissions must compo-

nent possess to prevent the invocation of other less privileged application Therefore

without concerning about the security issues they keep their component unprotected

and exported This can therefore be utilized by other malicious application that does

not have apparently specific rights

121 Inter-App communication in Android

Android applications can communicate with each other through intent ICC It can ex-

pose any components to be invoked by another android application Activity Service

Broadcast Receiver and content provider are the basic components of Android Appli-

cation Activities require user intervention and it can be started by sending intent

Each activity serves a distinct purpose Android allows for multiple applications to run

concurrently but there is only one activity running in the foreground at a time The

Android OS keeps track of all running activities on an activity stack The activity on

top of the stack is active while those below cannot be interacted with until all activities

higher on the stack are destroyed A fragment is a kind of sub activity that enables

modular activity design The fragment has its own layout in lifecycle callback The

fragment can be added and removed from the running activity Services run in the

background and does not have a user interface Like Activities it can be started with

intent Applications can communicate with services using the bindService() method

that will result in a communication channel called a binder channel Broadcast Re-

3

ceiver receives broadcast intent and does not have a user interface unlike activities

The broadcast message can send out using intent to multiple applications Application

can listen broadcast event using onReceive() method The content provider provides

the data to another application as a local database Android provides a number of

default content provider Contact provider is a Content provider for the Android Con-

tacts Browser provider maintains the browser history cookies and bookmarks

The activity requires user intervention but service and broadcast receiver might be run

in the background and can be the target by the malicious application to request for

the sensitive data using Intent The intent is an object that provides communication

between components it carries the payload via bundle The intent is also known as

a data container An intent generally consists of an address of a recipient component

an action to be performed by the recipient and often data If a recipient component

name within the application along with their package name is explicitly identified then

it is sent to the specified recipient is known as Explicit Intent if not then implicit

intent is to send to that Application which having appropriate IPC binder and generic

intent-filter that can handle such intent

122 IAC vulnerabilities and Attacks

Poorly developed applications without considering security perspective may be suscep-

tible to security attacks Permission spreading explicit capability leaks unauthorized

accessibility of data (eg credit card details amp login credentials) intent spoofing are

variants of confused deputy attack Generally these vulnerabilities are present due

to the presence of illegal access to sensitive data Permission Spreading occurs when

deputy grants permission to the illicit applications Component hijacking occurs when

buggy application inadvertently leaks some private data by exporting their components

The confused deputy attack is initiated by the requesting application which does

not have the privilege to access the system component and send the request sensitive

data through another deputy application who has that privilege to access The con-

fused deputy attack can be performing in three ways First Deputy might accidentally

or unintentionally expose their component without concerning much about the security

policy Second rdquoConfusedrdquo Deputy intentionally exposed its component to be used by

another application but an attacker may invoke it by intent spoofing Third the devel-

oper might expose component intentionally for attenuating authority but the incorrect

implementation of attenuation policy leads to the system policy to be inconsistent

4

123 Motivating Example

In this example we will introduce about the potential attack scenarios in which one

application will constitute an information flow with the help of other application having

other permission which is not present in the intentional application that takes this

initiative of performing dissemination of private data of a user without the consent of

the user

Figure 11 Attack Scenario 1

We have created some Android applications test-suit to test the possible inter-

application communication This test-suit is consists of malign benign as well buggy

apps with a distinct set of permissions Let us consider a scenario as shown in Figure

1 App1 contains a P1 set of permissions and does not contain a P2 set of permissions

Whereas App2 contains the P2 set of permissions and does not contain the P1 set of

permissions additionally App2 application is buggy due to the presence of Exposed

and public component Both the applications are having a distinct set of permission

where it will utilize other application to perform the task on their behalf App2 is

buggy because of its exposed or publicly available components without restricted set

of the permission defined in their component

Figure 2 is an another motivating example which describes the attack scenario of the two

5

application say App3 and App4 performing inter-app communication in which App4 is

buggy with the exposed component present without protected permission These two

apps are having the distinct set of permission but that permissions are not mentioned

inside the block of the exposed component App3 is accessing sensitive data and passing

and invoking App4 by calling startActivityForResult() App4 handles this intent using

getIntent() and set the result using setResult() On the other hand App3 is expecting

the result from App4 and after successful receiving of the result using intent it sends

the sensitive information to appropriate sink

To be precise our tool will provide the access control to the application accessing

sensitive resources Moreover it will allow the communication between the application

having equal or more privileged than invoking application if the application is calling

with the expected result from a less privileged application that will describe in detail

in the design and implementation section

13 Requirement Analysis amp its ingredients

In this section we will first discuss the generic defense techniques requirements of

effective detection and then elaborate how do we meet these requirements with different

security aspects

131 General defence techniques

These defence technique is used by the existing mechanism and it firstly addressed by

author Felt et al 2011 [21]

D1 Capabilities

A capability is shareable token provides the access rights that can not be forgeable

as token[22] In confused deputy attack deputy (intentionally or unintentionally)

ask for a token from a requester to make API call on their behalf In order to pre-

vent this attack access control mechanism is to be deployed using static analysis

to recognize what permission are to be involved for secure communication

D2 Taint Tracing

In taint tracing sensitive data gets tainted and the requester is accessing the

tainted data then the variable pointing to that data is also get tainted If deputy

makes tainted source privilege API call then confused deputy attack can identify

by tracing the tainted data reach to sink Taint explosion can occur when tracing

data and control flow whereas Confused deputy attack can be possible using

6

direct or indirect data flow because not all confused deputy attacks perform data

flow

D3 Mandatory Access Control

In the Mandatory access control(MAC) mechanism operating system enforces

access control policy at the different level of integrity and confidentiality In

this mechanism no information can flow from highly privileged principals to

low privilege principals But there are some scenarios where highly privileged

application invoke less privilege application (eg startActivityForResult()) with

expecting some results to be returned In this case less privilege application can

not return the result to high privilege application for the restricted access control

Hence It is desirable to have stringent MAC rules

D4 Stack Investigation

In Stack Investigation the system can check stack for any unprivileged API call

If any deputy had made any unprivileged API call then it can verify the privilege

of the callee application with the called application during runtime in Call Stack

This approach has a limitation if there is any asynchronous API call that is not

present in the stack

D5 History based Access Control

In the History based access control (HBAC) mechanism permission of the target

authorized application to get reduced after interaction with the unauthorized

application Like MAC HAC reduces permission of the authorized application

after receiving a call which has a restriction on application performance

7

Chapter 2

Literature Survey amp Review

21 Android Platform background security and weak-

nesses

Android is developed under an Open source project maintained by Google promoted

by open handset alliance and consist of original equipment manufacturer [23] [24] An-

droid is an Operating System developed on the top of the Linux kernel prevails upon

the other Smart Phones due to the wide range of connectivity internet Bluetooth

NFC and Google Wallet [25] ARM and x86 are two instructions set architecture that

Android supports Android is build on top of the Linux kernel the native libraries such

as OpenSSL Zlib Webkit OpenGL libs are developed in CC++ [26] Android has

a limitation of restricted number of resources so it uses light weight SQLite database

SQLite supports standard relational database like SQL and in addition it requires (ap-

prox 250 KByte) of memory during runtime[27] During system boot operation zygote

as VM process starts and initiates Dalvik virtual machine which further pre-load and

pre-initialize core libraries classes Android runs in optimized Java Virtual Machine

called the Dalvik Virtual Machine and each application runs in an isolated environ-

ment in their virtual machine Application framework at middle layer provides basic

functionality to an application such as resource management window management ac-

tivity lifecycle management etc which serves distinct functionality to the application

[28] The vital facet of Android platform is performing Cross process communication

aka Inter-Application Communication (IAC) via (Inter-Process Communication) IPC

binder In order to inherit the re-usability of the existing utility present in the other

application [29] The reference monitor is a component of an android operating sys-

tem reside at the middle layer to mediate the inter-component communication (ICC)

8

Figure 21 Android Architecture Diagram

It also provides the mandatory access control (MAC) mechanism to be enforced of

how an application can access the component present in intra-application or inter-

applications Binder component framework provides synchronous Remote procedural

call (RPC) mechanism for inter-component communication[30] The application can

make inter-component communication through intent Intent carries the data along

with their MIME type and action required to operated upon Intent-filter defined in

the manifest file to advertise the type of intent it can receive along with the matched

action data type categories [31] Android leverages discretionary access control to en-

force access control but there are some pitfalls that require flexible mandatory access

control by bringing security enhanced Linux in an Android platform (SEAndroid)[32]

9

Figure 22 Android Security Model

211 Androidrsquos Security model

Android is a Linux-based operating system provides discretionary access control an-

droid has similar and inherited security mechanism Each application (running process)

is assigned a unique UserId and every file can have read write and execute permission

for a user a group of users and everyone Android security model relies on App sand-

boxing permission declaration App signing [33] Android application runs in a sand-

box with a set of permissions which isolates the application from other applications

Android application cannot access private data from other application without having

appropriate permission

Android permission provides fine-grained security features that are compulsorily de-

clared in AndroidManifestxml file It emphasizes process to restrict specific operations

can be performed Permissions are requested during installation time and granted if

agreed by the user Granted permission will not change later and it will monitor by

the reference monitor Permissions are categories into three levels of security Nor-

mal permission Dangerous permission and systemorSignature permission[34] Normal

permission API call may annoy the user ie SET WALLPAPER But it does not

require user acceptance as it does not harm the users Dangerous permission API call

ieRECORD AUDIO is a harmful permission and require user acceptance Signature

permissions are extremely dangerous permissions ie CLEAR APP USER DATA is

10

granted only when requesting application is signed by the same developer that appar-

ently specified those permissions System permissions are granted if the application is

system application that meets the specific requirements of the systems A malicious

application that requests Dangerous permission System and Signature permissions can

spy on the phone to incurs a financial loss and clear phone data Existing static analysis

can check the permission during installation that makes the application to be suspicious

Application signing is another security mechanism that android platform uses to

establish entrust between app developers and targeted app users For signing applica-

tion a developer uses public key and private key pair to generate a certificate This

certificate is appended along with other files of an APK and validate during installation

time Applications can be signed with two possible ways ie Debug mode and Release

mode In debug mode the developer can sign their certificate using private key present

in Android SDK Whereas In Release mode Application can be signed using its own

generated private key Certificate of the Application provides the authenticity and ori-

gin of the developer If the application is sharing their userID by defining sharedUserId

in their manifest file it allows applications to reside in the same sandbox and same

developer provenance[35]

212 Android Security Weaknesses

We summarize the peculiarities and limitations which provokes the various attacks on

Android operating system and its App market as follows

W1 Android platform allows alternative third party market other than Google Play

(official Android Market) to launch their applications with less restrictive permis-

sions As a result it allows inadvertent installation of malware[36]

W2 Permissions are checking during installation time and there is no inspection during

run time As a result App can run use or misuse all of its permissions granted

during installation time[12]

W3 Easy to reverse-engineered with the injection of malicious code [37]

W4 No isolation mechanism for third party libraries such as an advertisement that

cause improper ad display that is overlaid on top of the targeting application UI

and earn revenues with a single fraud click [38]

W5 Native code that are written in C amp C++ via Java Native interface are potentially

vulnerable to evade malware from monitoring tools and analysis techniques [39]

11

W6 App developer is unconscious to the aspects of Android ICC that may uninten-

tionally keep their sensitive APIrsquos unprotected[30]

W7 Vulnerabilities due to the presence of pre-installed apps and vendors customized

manufacturers on device[40]

213 Android Security Guidelines

Enck et al and [42] have demonstrated well about the secure app development guide-

lines If developers are developing applications then they should consider these instruc-

tions to dodge security flaws that we are succinctly describing here

G1 Do not log and Broadcast sensitive information using implicit intent and always

send explicit intent to a pending intent containing the same set of permission as

that of the application sending pending intent

G2 Unsuccessful passing of explicit intent to pending intent would allow the intent to

be abused by another application thereby either leakage or altering of sensitive

data can occur by intent spoofing

G3 Do not forget to protect exported components with strong permission and check

that the application having specification permission before responding The meth-

ods ContextcheckCallingPermission() and ContextenforceCallingPermission() can

be used to verify the calling application with appropriate permission passed in

their arguments

G4 Do not flag FLAG GRANT READ URI PERMISSION or FLAG GRANT WRITE

URI PERMISSION on the intent that carrying sensitive data in URI If the ma-

licious application containing URI permission granted in Manifest file then it can

read or write URI without having access right

author Felt et al2011

1 Capabilities

A capability is an unforgeable shareable token that when used grants access to

a rights [22] In confused deputy attack deputy (intentionally or unintentionally)

12

2 Taint tagging amp Tracing

flow

3 Mandatory Access Control

4 Stack Investigation

5 History based Access Control

In the History based access control (HBAC) mechanismheuristic analysis of per-

mission of the target authorized application to get reduced after interaction with

the unauthorized application Like MAC HAC reduces permission of the au-

thorized application after receiving a call which has a restriction on application

performance

13

23 Attack classification

24 Static Taint Analysis

Apposcopy[Feng et al2014] it assimilates a static taint analysis to construct inter-

component callgraph and data flow graph to find the control and data flow between

the components Epicc[Octeau et al2013] formalized the ICC analysis by reducing to

the instance of the Inter-procedural Distributive Environment (IDE) data flow prob-

lem It is context flow inter-procedural and path sensitive Epicc builds on the top

of soot and uses Heroes IDE solver which precisely detect the vulnerability and seeks

for the component that are communicating FlowDroid [Arzt et al2014] analyses the

leakage of data Whereas flow context field and object-sensitivity allows the analysis

to reduce the number of false rate It can not detect data-flow across different apps

components that communicate by means of ICC IccTA[Li et al2015] uses Soot a pop-

ular framework for analyzing the application based on Java and represents data flow

using Jimple IccTA leverage flowdroid for CFG generation and data flow analysis

IccTA detects inter application communication but could not recognize inter-app com-

munication vulnerability CHEX[Lu et al2012] is component hijacking examiner that

performs app splitting to discover the entry point in android app and facilitate global

data-flow analysis across the methods to grab various kinds of vulnerability CHEX

gives the result of the vulnerable app but it can not find out what are those apps which

invokes that vulnerable apps ScanDroid[Fuchs et al2009] is an Automated security

certification tool for Android applications ScanDroid checks the data flow consistency

with integrity and confidentiality On this basis it makes the security relevant deci-

sions by string analysis Its implementation is build on WALA tool[49] and require

java byte code that is not scalable to large apps WoodPecker[Grace et al2012] de-

termine dangerous permissions from public interface of an application in stock eight

popular Android devices and finds the entry point from CFG Moreover if the entry

point is not protected with permission then there is a possibility of capability leak It

takes the union of permissions of those application that reside in the same sandbox

IntentDroid[Hay et al2015] provides platform-level instrumentation and probing tech-

niques to establish binding between message send and creation of bundle object for that

message and verifies message is sent by IntentDroid to declare it relevant or irrelevant

otherwise Sifta[von Rhein et al] is a variability-aware approach depend on graph-based

data structure for representing flow annotated with boolean expression that indicates

the presence and absence condition of apps in flow Sifta is build on the reuse code

14

Figure 23 Application level privilege escalation attack classification

15

of DIDFAIL[Burket et al] But it inherits the limitations of Epicc and FlowDroid

Stowaway[Felt et al2011] identifies the required APIs present in the Application using

static analysis and reduce the extraneous permission to prevent advertising application

to get the permission of their host application

State-of-the-art tools performing static analysis are limited to the work of known

vulnerabilities and matching and comparing the pattern with the existing signatures

25 Capability leaks

PaddyFrog[Wu et al] DroidChecker[Chan et al] DroidAlarm[Zhongyang et al] iden-

tifies the capability leaks by generating control flow graph and data flow graph It

performs static analysis over the byte code of an application

IPC Inspection[Felt et al 2011] reduces the permission of high privileged app (deputy)

to the intersection of the requester and deputy permissions after it receives commu-

nication from the less privileged app IPC-inspection will persuade storage overhead

explicitly by maintaining the multiple instances of the same application with a distinct

set of permissions

Quire[Dietz et al2011] analyses the full call chain and data provenance request

using IPC and RPC secondly it uses cryptographic techniques to protect the data

goes off the device Quire have limitation of not forwarding the IPC that is done by its

own behalf so it can not detect colluding application

Furthermore due to the unexpected denial of callerrsquos application and running with

the reduced permission may lead to the application crash It is still not clear that how

permissions that is controlled by a Linux discretionary access control can be reduced

Application can regain its permissions by invoking some other application

27 Application level privilege escalation attack

271 Detection

XManDroid[Bugiel et al] extends reference monitor to monitor the system applica-

tion during runtime that performs ICC and validate whether the ICC can exploit in

combination with other component in different application But their policy set is

16

incomplete for the verification of communication link between apps that increases false

positive result

272 Prevention

Magdy et al prevent high risk level application to be accessed by low risk level using

firewall Firewall can be used to protect multiple critical permissions by creating the

different zones for preventing applications They are just protecting the two known

dangerous permissions INTERNET and READ CONTACTS containing apps with dif-

ferent zones but could not detect what are those apps which are trying to exploit that

apps

28 Application and kernel level privilege escalation at-

tack

281 Detection

Bugiel et al2012 is an extension to the previous work of XMandroid it provides system-

centric and policy driven runtime monitoring approach for communication link between

application at middle as well as kernel level(local UNIX domain and File system) Its

pre-assume policy sets hinders to detect zero-day attacks Hay et al2015 binds the

message integrity of the sender app by IntentDroid itself It performs platform level

instrumentation and dichotomize into relevant and irrelevant

282 Prevention

RanDroid[Schmerl et al2016] It is an user-centric approach that relies on the ap-

proval of the novice user who grant or abort the inadvertent leakage of private data

among the applications Tissa[Zhou et al2011] MockDroid[Beresford et al2011]

AppFence[Hornyack et al2011] I ARM Droid[Davis et al2012] performs the security

extensions by providing the fake data of the user by modifying the whole contents of the

content provider that influences the entire data on the device DroidForce[Rasthofer

et al2014]

17

Literature Review

LiteratureSurvey

ExistingMechanism

Binder

ICC

Monitoring

Modifysensor

Mocking

ModifyServices

ModifyProviders

FileAccess

Socket

ApkHooks

Limitations

Modify MockDroid JailbreakSystem XManDroid or

FlaskDroid RootCRePE DeviceQuire

MockDroid XManDroid FlaskDroid CRePE Quire

TaintDroid Kirin

IPC Inspection AppFence APEX Saint

SEAndroid TISSA

Domain Boxify EludeIsolation TrustDroid Virtual MC

Inline Aurasium RequireReference AppGuard EstimationMonitor DrAndroidampMrHide

I ARM Droid DroidForce Retroskelton

Component AdDroid HighRetrofit ApSplit Overhead

Compac

Table 1 Literature Survey amp Literature Review

1

Figure 24 Literature Review and Literature Survey

18

Tab

le2

1

Com

par

ativ

est

ud

yof

stat

e-of

-th

e-ar

tre

searc

hS

tate

-of-

the-a

rt-r

ese

arc

hM

ech

an

ism

Mod

ificati

on

Dep

loym

ent

Tools

uti

lized

Flo

wD

roid

[45]

Sta

tic

NA

offd

evic

eD

exp

ler

Soot

S

par

kA

pp

osc

opy[4

3]

Sta

tic

NA

off

dev

ice

Ep

icc[

44]

Sta

tic

NA

off

dev

ice

Her

os

Sp

ark

S

oot

d

are

IccT

A[4

6]

Sta

tic

NA

off

dev

ice

CH

EX

[47]

]S

tati

cN

Aoff

dev

ice

Dex

Lib

W

AL

AS

can

Dro

id[4

8]

Sta

tic

NA

off

dev

ice

WA

LA

Wood

Pec

ker[

50]

Sta

tic

NA

off

dev

ice

bak

smal

iad

bD

IDFA

IL[5

3]

Sta

tic

NA

off

-dev

ice

Sif

ta[5

2]S

tati

cN

Aoff

-dev

ice

Pad

dyF

rog[

54]

Sta

tic

NA

off

dev

ice

Dro

idC

hec

ker[

55]

Sta

tic

An

aly

sis

NA

off

-dev

ice

Dro

idA

larm

[56]

Sta

tic

NA

off-d

evic

e

Kir

in[6

6]In

stall

-tim

eS

yst

emon

-dev

ice

XS

BP

rolo

gE

ngi

ne

Inte

ntD

roid

[Hay

etal

201

5]

Inst

rum

enta

tion

IPC

Insp

ecti

on[2

1]S

tack

-Inve

stig

atio

nS

yst

emon

-dev

ice

Ded

exer

Qu

ire[

57]

Sta

ck-I

nve

stig

atio

nS

yst

em+

Ker

nel

on-d

evic

e

Xm

anD

roid

[58]

Ref

eren

ceM

on

itor

ing

Syst

emon

-dev

ice

Bu

giel

etal

[201

2]

Ref

eren

ceM

on

itor

ing

Syst

emO

n-d

evic

eX

man

Dro

id

Tai

ntD

roid

[67]

Dyn

am

icta

inti

ng

Syst

emon

-dev

ice

Tis

sa[6

2]

Mock

use

rd

ata

Syst

em+

conte

nt

pro

vid

erO

n-d

evic

eM

ock

Dro

id[[

63]

Mock

use

rd

ata

Syst

em+

Con

tent

Pro

vid

erO

n-d

evic

e

Ap

pF

ence

[64]

Mock

ing

ampta

inti

ng

Syst

emO

n-d

evic

eT

aintD

roid

Dr

An

dro

idamp

Mr

Hid

e[20]

]In

stru

men

tati

onA

pp

lica

tion

Off

-dev

ice

Ap

kto

ol

Red

exer

Au

rasi

um

[68]

Inst

rum

enta

tion

App

lica

tion

On

-dev

ice

apkto

olA

pp

Gu

ard

[69]

Inst

rum

enta

tion

Ap

pli

cati

onO

n-d

evic

ed

exli

bI-

AR

M-D

roid

[17]

Inst

rum

enta

tion

Ap

pli

cati

onoff

-dev

ice

smali

bak

smal

iR

etro

skel

ton

[70]

Inst

rum

enta

tion

Ap

pli

cati

onoff

-dev

ice

smal

iD

roid

Forc

e[[6

5]

Inst

rum

enta

tion

Ap

pli

cati

onoff

-dev

ice

19

Chapter 3

Proposed Methodology

31 Proposed Methodology

In this Section we present design and Implementation of Honified tool We have devel-

oped Honified that will handle implicit intent as well as performs app transformation

with the code of reference monitor aka (In-line Reference monitors) that will mediate

access control mechanism as per the specification described in the App itself

311 Honified Architecture

Figure 31 Honified Architecture

20

Figure 32 Honified Work Flow

312 Design amp Implementation

Honified targets the buggy (vulnerable app) Vulnerable apps are those apps which

are not necessarily malicious indeed but it gives support to other apps Furthermore

these apps make their component be publicly available and allow them to be exported

by other apps HAP tool analyzes app by listening to the event of installation of the

app using BroadcastReceiver ie one of the components of the Android app present

in the app of Honified tool Honified tool performs the extraction of the meta-data of

the application including package name the number of components with or without

exported features permissions in the first phase of the tool and in the next phase it

performs the app transformation of the app if it is reported as a buggy app in former

phase Once the app transformation has been done then honey enabled app consist

of in-line reference monitor will be launched after the complete deletion of the buggy

app Every app has some valid certificate that is signed by the app developer before

launching of an app in App store This certificate is present in the Android App itself

Complete deletion of the app is compulsory to prevent incompatible certificate issues

during re-installation of transformed app with re-written secure code in Android device

21

Fundamentally in order to thwart inter-application communication vulnerabilities in

Android HAP tool mainly focused on the Service as an unprotected component because

it does not require user intervention and runs in a background and evade themselves

from being observed by the user The whole solution is divided into three phase module

Phase 1 Preprocessing of Apk

In this phase we are parsing AndroidManifestxml file to extract meta-data of the

android application such as unprotected components permissions package name and

certificate Afterward App transformation will perform if the app is reported to be

vulnerable This phase is vital for the construction of policy As application possesses

permissions to be included for the monitoring code in a source file of an application

that will further utilize in verification of permission during runtime

P11 Exposed Component Recognition

Android application runs in their sandbox to prevent other applications to inter-

leave with the applications Android application comprises of many components

which interact with each other by initiating ICC Some applications allow other

application to interact with itself by exposing their components Whereas the

Application developer cannot anticipate the security exploitation of the exposed

component Hence they keep their components to be unprotected without saving

it with apparent permissions In this phase we are trying to find out the po-

tentially exposed components android exported=rdquotruerdquo present without enclosed

with permissions in their AndroidManifestxml file using AAPT tool available in

Android device

P12 Permission Extraction

Application consists of various permissions which provide an access right to sensi-

tive APIs present in the Android Device The vulnerable application also contains

permission in their AndroidManifestxml file but that permissions are not a part

of exposed components We are extracting that permission so it can be further

utilized to build the secure component that provides secure shelter for the exposed

components

22

Figure 33 Preprocessing of Apk

Phase 2 App Transformation

It is an intermediate stage where app transformation is to perform App transformation

utilizes Apktool to embed the in-line reference monitor that can monitor the launching

of intent running application at the activity stack and the permission associated with

the applications In order to prevent app to bypass monitoring scanner we are placing

monitoring code in the exposed components and replacing the code of the exposed

components with some protected component If Application wants to communicate

with the previously unprotected components it has to go through the secure shelter

component

T21 Transform Dalvik bytecode

When we develop an android application after successful compilation of An-

droid application apk file generates and consists of Dalvik bytecode which is the

optimized and platform compatible bytecode for the Android operating system

However it is not user-friendly so there is a tool named as Apktool that disas-

sembles Dalvik bytecode to smali code which is in human readable format Our

Honified tool also utilizes Apktool for converting Dalvik bytecode to smali code

And then it re-writes the desired smali files with the secure shelter component

execution for the initial verification

T22 Transform AndroidManifestxml file

AndroidManifestxml file consist of Package name a number of components used

Permission to access resources of the application We have transformed Android-

Manifestxml file by appending one BroadcastReceiver named as Malware Re-

porter and N number of shelter component of N exposed component Malware

23

Reporter as a component will monitor the event of installation of android app

and it will also warn the user if it is found to be malicious by secure shelter com-

ponent We are extending ActivityManager to get the details of the top running

activity from Activity Stack and list of asynchronous service For using Activity-

Manager as a reference monitor to monitor the running task we are appending

GET TASK permission in manifest file But this permission which is appended

after meta-data extraction and during transformation will not be considered for

monitoring in another application

T23 App Signing For App signing we are preferably using the new cryptographic

private key which is far different from the original application Basically Dig-

ital signature used for an application entitled a trust level between the same

application developer and multiple versions of the application This indicates the

originality of the application from the same vendor and same digital signature

In order to maintain the originality of the application and ensures the same trust

level we will use the same original key for signing the key in future after the

approved by the application developer

Figure 34 App transformation

Phase 3 Runtime Intent Mandatory Access Control

In Runtime intent mandatory access control it is required to run honey enabled the

app that will perform the basic operation and its secure shelter component remains

idle until it does not interact with other application Once honey enabled app is being

invoked by other application by explicitly sending intent to the exposed component

The Modified exposed component will handle the intent in monitoring mode and it will

divert the intent along its data or MIME type to other created component with the

same source code accessing sensitive resources and graphical interface

24

P31 Reference monitoring

In-line reference monitoring extends the Android reference monitor framework to

monitor communication between Android application In-line Reference monitor

provides the one-direction MAC where Application is highly privileged can ac-

cess the resources of less privilege even by sending flow control to start another

component (eg startActivityForResult()) Whenever Application receives intent

then it checks the Activity Stack and Service Stack to get the lists of Activities

and concurrent services running on the stack along with their package name by

extending ActivityManager ActivityManagerRunningTaskInfo() is a Class of

an android ActivityManager that retrieves the information about the particular

currently running task in the android device from activity stack ActivityMan-

agerRunningTaskInfotopActivity() helps to retrieve the package name of the

Application running at the top of Activity stack

P32 Permission Recognition and comparison

In permission recognition We are extending PackageManager to get the list of ap-

plication that possesses same permission that we have extracted during the phase

of Static Analysis PackageManager is an API that manages the installation

uninstallation and upgradations of android application It also helps to get the

information about the installed android app in the device using package name

The PackageManager class allows getting the instances of an android application

by calling getPackageManager() PackageManager also facilitates the method for

the modification and querying installed package and related permissions Pack-

ageManagergetInstalledApplications() returns a list of all the installed android

applications in a device

Figure 35 Dynamic analysis

25

Above three phases of the proposed work will combat these threats that we have

addressed in this paper at section III It not only provides the demystified privileges

to the application with the similar and compatible set of permissions but also protects

the dissemination of private user data by giving user interface warning

313 Proposed Algorithm amp its work flow

There is two algorithms First Honified tool algorithm and Second HoneyApp Algo-

rithm Honified is a tool that will generate the HoneyApp Both the apps contain inline

reference monitor to mediate the inter-process communication Honey enabled app will

decide to receive the intent if the appropriate permission is found in the application

Algorithm 1 Honified algorithm

1 Input Android mobile apps

2 Output Buggy Apps with Honey code

3 procedure Vulnerability Scanner amp App transformation

4 while Apps in the Android device do

5 Extract Apprsquos Meta-data

6 for all Not permission protected components do

7 if androidexported=rdquotruerdquo then

8 return Buggy Apps

9 end if

10 end for

11 for all vulnerable components in Buggy Apps do

12 Performs App transformation

13 Extends PackageManager amp ActivityManager

14 end for

15 end while

16 return Honey Enable Buggy App

17 end procedure

26

Algorithm 2 Honey app Algorithm

2 Output Malicious App

3 procedure Honey app

4 if Implicit Intent then

5 Honified handles

6 Verifies generic permissions

7 else Explicit Intent

8 Honey Enabled Apprsquos shelter component handles

9 Shelter component verifies permissions

10 end if

11 if Calling App perm sube Called App perm then

12 Perform basic operation

13 elsereturn Malware Reporter reports malware

14 end if

15 end procedure

Working of Honified

Honified will transform buggy app amp generates honey enabled buggy Apps which will

use to lure the attacking apps Honified can also receive implicit intent if the target

android application is not decided

1 Honified utilizes AAPT (Android App packaging tool) for extracting Android-

Manifestxml file from android apps and the name of the unprotected amp exported

components of the android apps

2 After extracting Meta-data (package name permissions exported components)

it performs app transformation

3 In App transformation a new component file name with the same component

type of unprotected component is appended in the Apk by repackaging it with the

apktool and also update the AndroidManifestxml file with the same component

file name and component type without exporting it publicly

4 If there are C exposed component then it will append C secure shelter component

and one component (Broadcast Receiver) that will report malicious activity to

the user

27

5 Swap the contents of the files of new secure shelter component and unprotected

component

6 Now the unprotected component file contains the code of malicious app scanner

that handles the intent on behalf of the previously unprotected component

7 Assemble the apk using Apktool

8 Resign the apk with the new fresh private key

9 Re-install honey enabled app after the successful deletion of the previous buggy

app

Working of HoneyApp

1 Implicit intent is handled by HoneyAppPlanterapk whereas it compares the

generic permission of the calling application INTERNET SEND SMS basically

uses in intent-filter

2 For Explicit intent HoneyApp generated by HoneyAppPlanter tool handles

3 It also retrieves the information about the installed application along with their

corresponding permissions and top android application at the Activity Stack using

PackageManager and ActivityManager respectively

4 It then compares the permissions of the honey enabled calling app with the per-

mission of called app

5 If the called app does not contain the permissions of the honey enabled calling

app then it will declare the called app as the malicious app

6 Otherwise it allows them to communicate

28

Chapter 4

Evaluation

41 Evaluation

For evaluating the profound study of proposed tool we have tested on the available and

developed app dataset Available 49 malware family consist of 1376 apps from Genome

malware dataset amp 3000 apps from playdrone dataset [Viennot et al 2014]9 apps from

IACBench-master Selected 3 Inter-Application communication apps from DroidBench-

master dataset We have checked how many buggy apps are present in the Genome

malware dataset and transformed to Honey enabled App HoneyAppplanterapk Han-

dles Implicit Intents from IACBench-master and DroidBench-master apps We have

developed various attack scenarios to detect inter-application communication vulnera-

bilities

we have implemented various apps that are accessing sensitive APIs of the Android

Application and one of the application pair have exposed their component public that

allows other application to send their intent with data and MIME type (optional field)

Before testing HoneyAppPlanter tool we have checked that these apps are working

fine with the leakage of private data in the emulator Afterward we have transformed

exposed application to HoneyApp and makes them honey enable consist of the in-line

reference monitor After performing the transformation it can be depicted that the

application which was performing inter-application communication are prevented with

access control and at the same time it gives warning to the user to delete these apps

from their device On the other hand we have checked the correctness of the tool by

testing benign apps which are accessing sensitive API with the appropriate permission

Furthermore these benign apps are having the privilege of accessing the data using

other application without security violation To test the reliability of proposed tool

29

we have also tested those apps which keep their component exposed but protect them

with the permissions These applications are not buggy as these apps allowing inter-

application communication with the equal or more set of permissions present in other

apps There can be dangerous permissions but there can be the possibilities of signa-

ture system or user define customized permission Customized user defined permission

can be categorized in normal dangerous or signature permissions Our tool considers

all possible scenarios by preventing them to be reported as buggy during meta-data

extraction phase

Table 41 IACBench-master Apps dataset detecting Implicit Intent

IACBench-

master Apps

Implicit Intent

prevention

ActToAct X

ActToService X

ActToBndService X

ActToBroad X

ActToOrdBroad X

MultipleIntent X

LoopApp Xdagger

LoopChain Xdagger

SameFilterDiffCompXdagger

dagger Provide access control but can not cat-

egorizeX Provide access control and detect

As shown in Table 2 we have tested HoneyAppPlanterapk in DroidBench and

IACBench dataset These datasets are consist of 9 apps from IACBench and 3 Apps

from DroidBench that access sensitive API ie IMEI no and send using implicit intent

to other application that sends SMS and view browser In order to detect and prevent

inter-app communication HoneyAppPlanterapk handles the implicit intent and veri-

fies the permission present in the application ie SEND SMS INTERNET It is found

that none of these applications have these permissions and it is detected by our Apk

tool during runtime

In ActToAct Application having activity component sends the implicit intent to an-

other activity component in other application HoneyAppPlanterapk tool handles this

30

implicit intent activity and verifies the privileges of caller application Similarly tool

can handles ActToSerive ActToBndService ActToBroad ActToOrdBroad In Multi-

pleIntent multiple intents from the same application are sent to the targeting appli-

cation Our tool apk can handle this multiple intents effectively without false alarm

rate In LongApp an intent is sent from one component of the application to another

component and then to other after receiving of that intent and creates the loop chain

Our tool can prevent the occurrence of the loop but cannot detect classify it to the

category of Loop creating App Similarly In LongChain five intent send as a long

chain to target other app and that app forwards this loop Our tool can prevent the

creation of loop chain but cannot categorize as chain creating the app In the Same-

FilterDiffComponent app multiple intents send to a different component of the same

intent filter The tool can handle all the intent at the same time

31

Table 42 Buggy Genome App datasetGenome Apps Total samples Exposed Intent Implicit Intent sharedUserId

ADRD 21 3 10 1

AndroidOBada 2 2 0 0

AnserverBot 187 0 1 1

Asroot 8 0 0 0

BaseBridge 122 0 0 0

BeanBot 8 1 0 0

Bgserv 9 0 9 0

CoinPirate 1 1 1 0

CruseWin 2 0 0 0

DogWars 1 0 1 0

DroidCoupon 1 0 0 0

DroidDeluxe 1 0 0 0

DroidDream 14 3 0 0

DroidDreamLight 46 2 2 0

DroidKungFu1 34 1 2 0

DroidKungfu3 309 16 14 0

DroidKungfuSapp 3 0 0 0

DroidKungFuUpdate 1 0 0 0

EndOfDay 1 0 0 0

FakeInstaller 1 0 0 0

FakeNetFlix 1 0 0 0

FakePlayer 5 0 0 0

GamblerSMS 1 0 0 0

Genimi 67 0 7 0

GGTracker 1 0 1 0

GingerMaster 4 4 0 0

GoldDream 47 29 0 1

Gone60 9 0 0 0

GPSSMsSpy 6 0 0 0

HippoSMS 4 2 0 0

JiFake 1 0 0 0

jSMSHider 16 0 3 0

Kmin 52 0 0 0

LoveTrap 1 0 0 0

NickyBot 1 0 0 0

NickSpy 2 2 0 0

Pincer 6 0 4 0

PincerApk 40 0 7 0

Pjapps 58 7 5 0

Plankton 11 0 0 0

RogueLemon 2 0 0 0

RogueSPPush 9 0 0 0

SMSReplicator 1 0 0 0

SndApps 10 10 0 0

Spitmo 1 0 0 0

Tapsnak 2 0 0 0

Walkinwat 1 0 0 0

YZHC 22 0 0 0

zHash 11 0 11 0

Zitmo 1 0 0 0

Zsone 12 12 0 0

daggerImplicit intent to view browser

sectImplicit intent to send SMS

411 Case Study

According to the result as shown in table IV Genome 49 malware family dataset

consist of 1376 apps There are some applications from the Genome dataset pro-

vides the exploitable interface that can be utilized by the other application Mostly

32

Service amp BroadcastReceiver component present in the application were found to be

exploited This malware utilizes various sensitive APIs to access the resource of the

device Whereas there are some applications that contain unprotected public inter-

face of implicit intent in the application These application uses various combination

of SMS sending features and some provide browser view with malicious Url payload

ADRD AnserverBot GoldDream malware families share their user id Applications

which are having common user id reside in the same sandbox environment with the

same resource allocation They can invoke other applicationrsquos component and inherit

the functionality across the process

0

50

100

150

200

250

300

350

400

300600

9001200

12001500

21002400

27003000

o

f exposed c

om

ponents

of apps in playdrone dataset

Exposed activity apps

ExposedActivityTotalExposedActivity

Figure 41 Application escalating priv-

ileges

0

20

40

60

80

100

120

140

160

300600

9001200

15001800

21002400

27003000

o

f exposed c

om

ponents

Exposed service apps

ExposedServiceTotalExposedService

Figure 42 Honey-App handles privi-

lege escalation

0

5

10

15

20

25

30

35

40

300600

9001200

15001800

21002400

27003000

o

f exposed c

om

ponents

Exposed Receiver apps

ileges

0

5

10

15

20

25

30

300600

9001200

15001800

21002400

27003000

o

f exposed c

om

ponents

Exposed provider apps

lege escalationAs shown in Figure we have tested on the downloaded dataset available in Play-

Drone PlayDrone is Google play store crawler that contains over 1100000 of Android

33

App snapshot and index PlayDrone dataset is consist of the huge collection of An-

droid apps including adware and malware but we have downloaded top 3000 application

and performs meta-data extraction to find the app is buggy or not and then we have

transformed buggy apps into honey enabled a buggy app to prevent these apps from

other less privileged application Although we have performed static analysis to get the

maximum number of exposed components present in the application but preserving

the threshold initially prevent to know the attacker attacking pattern sequence

42 Performance

Delta Microbenchmarking is used to test the performance overhead of HAP tool with

respect without HAP tool We have achieved 9689 performance gain with HAP tool

whereas existing mechanism are providing separate components and library that can

be bypass by the malware

Before Honified After Honified

50

100

150

200

250 Warm up duration (nsec)

Benchmark duration (nsec)

4201 Functionality

After app transformation we have preserved the functionality of the application We

have anecdotally verified and confirmed the functionality of the application before trans-

formation and after transformation on the android virtual device (emulator) contain

API 44 level App transformation is completely automated without user intervention

and we have manually observed the same user interface and same execution of the

component without reduced permission set

34

Figure 45 Launching before Honified

35

Figure 46 Launching after Honified

36

Figure 47 IPC before Honified

37

Figure 48 IPC after Honified

38

4202 Size

Android devices are resource constrained Linux-based operating system it precludes

the use of resource consuming Therefore we need to consider the size while running

any application Android applications are compressed as APK file consist of Dalvik

byte code We have added 10KBs of the 1000 lines of code in APK file along with the

component name described in AndroidManifestxml file and GET TASKS permission

421 Portability

In this section we discuss the basic granularities of integrating HAP tool into default

application framework and App store market

4211 On Device amp Off Device Deployment

Apps downloaded on Android real Device have to go through the HoneyAppPlanterapk

tool during the time of installation and then it inquires the PackageInstaller that will

give user interface to handle application installed in the Device After getting details

about the total number of an application installed (or installing) in the Android Device

HAP tool performs meta-data extraction and then transforms the desired application

using Apktool available in Android version without data loss if it was reported buggy

In off device deployment of HoneyAppPlater tool users can download the various app

dataset and HoneyAppPlanter tool that utilizes Apktool for the (Linux version) It

performs the same procedure of extracting transforming on Linux operating system

Whereas for runtime analysis of Honey enabled buggy app user to have to install app

on virtually emulated Android device

Device Portability

Table VI summarizes about the currently available Android version supported by the

proposed HAP tool implementationBelow Android version 41 is not compatible for

the deployment as it lacks the feature of process isolation

Table 43 Supported Android version of HonifiedAndroid version le 40 41 42 43 44 50 51

Supported timesdagger X X X X X XdaggerNo process isolation X SupportedtimesNot Supported

39

4212 App Store

Various Android App market is available that can apply our HoneyAppPlanter tool on

their app store like Google bouncer used by Google Play store Whenever an application

is registered in any App-store then App-Store can verify the application and identify

its peculiarities Before launching any app in App-Store it can transform the app into

the Honey-Enabled app with the re-written code of In-line reference monitor

4213 Development time Deployment

In the above two deployment approach the transformation of app code requires resign-

ing of the application that violates the integrity of an application as the application

cannot get updated after modifying the signature of an application ie originality of

the application Installation of the transformed app can be done after the complete

uninstallation of an application To overcome app transformation and re-signing issues

with the same signature key we recommend App developer to use our HAP tool during

the time of development of the application with secure code consist of the in-line ref-

erence monitor Honey enabled developed app provides access control mechanism and

also gives warning regarding the presence of malicious application to the user These

applications can get updated and provides all the desired resources

40

Chapter 5

Conclusion and Future work

Inter-application communication can be utilized by third party application that can

lead to serious threats in Android Operating System We proposed Honified tool a

fine-grained component level access control to combat intent based attacks and dissem-

ination of private data of a user We have not preserved the integrity of an application

that will be negotiable with the developer in future to provide the common private

key for the application signature According to the Delta MicroBenchmark we have

observed affordable overhead that is less comparative to other mechanism We will

make Honified tool as an open source tool in future

41

References

[1] smartphone market mdash TechCrunch httptechcrunchcom20150820

peak-androidg5ros1sDG2b 1

[2] Androidrsquos 5 biggest security flaws 2015 mdash Security

mdash Techworld httpwwwtechworldcomsecurity

androids-5-biggest-security-flaws-2015-3622116 1

[3] Gartner Gartner Says the Internet of Things Will Transform the Data Center

httpwwwgartnercomnewsroomid2684616 2015 1

[4] Google announces androidhome framework for home

automation httpwwwengadgetcom20110510

google-announces-android-at-home-framework 1

[5] Nien-tsu Chen Chun-lun Kuo and Pang-hao Wang Portable home device man-

aging systems and devices thereof January 14 2016 US Patent 20160014108

1

[6] Phillip A Laplante and Nancy L Laplante A structured approach for describing

healthcare applications for the internet of things In Internet of Things (WF-IoT)

2015 IEEE 2nd World Forum on pages 621ndash625 IEEE 2015 1

[7] Leandros A Maglaras Ali H Al-Bayatti Ying He Isabel Wagner and Helge Jan-

icke Social internet of vehicles for smart cities Journal of Sensor and Actuator

Networks 5(1)3 2016 1

[8] Android vulnerability - the hacker news httpthehackernewscom201508

android-flaw-hackinghtml 2015 1

[9] Roman Schlegel Kehuan Zhang Xiao-yong Zhou Mehool Intwala Apu Kapadia

and XiaoFeng Wang Soundcomber A stealthy and context-aware sound trojan

for smartphones In NDSS volume 11 pages 17ndash33 2011 2

42

REFERENCES

[10] Apache cordova vulnerability10 of android banking https

securityintelligencecomapache-cordova-phonegap-vulnerability-android-banking-apps

2

[11] Dominik Maier Mykola Protsenko and Tilo Muller A game of droid and mouse

The threat of split-personality malware on android Computers amp Security 54

2ndash15 2015 2

[12] Adrienne Porter Felt Erika Chin Steve Hanna Dawn Song and David Wagner

Android permissions demystified In Proceedings of the 18th ACM conference on

Computer and communications security pages 627ndash638 ACM 2011 2 11 16

[13] Adrienne Porter Felt Elizabeth Ha Serge Egelman Ariel Haney Erika Chin

and David Wagner Android permissions User attention comprehension and

behavior In Proceedings of the Eighth Symposium on Usable Privacy and Security

page 3 ACM 2012 2

[14] Violetta Vylegzhanina Douglas C Schmidt and Jules White Gaps and future

directions in mobile security research 2015 2

[15] Collin Mulliner Steffen Liebergeld and Matthias Lange Poster Honeydroid-

creating a smartphone honeypot In IEEE Symposium on Security and Privacy

2011 2

[16] Apktool - a tool for reverse engineering android apk files httpsibotpeaches

githubioApktool 2

[17] Benjamin Davis Ben Sanders Armen Khodaverdian and Hao Chen I-arm-droid

A rewriting framework for in-app reference monitors for android applications Mo-

bile Security Technologies 2012 2012 2 17 19

[18] Michael Backes Sebastian Gerling Christian Hammer Matteo Maffei and Philipp

von Styp-Rekowsky Appguard-real-time policy enforcement for third-party appli-

cations 2012 2

[19] Jaebaek Seo Daehyeok Kim Donghyun Cho Taesoo Kim and Insik Shin Flex-

droid Enforcing in-app privilege separation in android 2016 2

[20] Jinseong Jeon Kristopher K Micinski Jeffrey A Vaughan Ari Fogel Nikhilesh

Reddy Jeffrey S Foster and Todd Millstein Dr android and mr hide fine-

grained permissions in android applications In Proceedings of the second ACM

43

REFERENCES

workshop on Security and privacy in smartphones and mobile devices pages 3ndash14

ACM 2012 2 19

[21] Adrienne Porter Felt Helen J Wang Alexander Moshchuk Steve Hanna and

Erika Chin Permission re-delegation Attacks and defenses In USENIX Security

Symposium 2011 6 12 16 19

[22] Norm Hardy The confused deputy(or why capabilities might have been invented)

ACM SIGOPS Operating Systems Review 22(4)36ndash38 1988 6 12

[23] Open handset alliance httpwwwopenhandsetalliancecom 8

[24] Parvez Faruki Ammar Bharmal Vijay Laxmi Vijay Ganmoor Manoj Singh Gaur

Mauro Conti and Muttukrishnan Rajarajan Android security a survey of issues

malware penetration and defenses Communications Surveys amp Tutorials IEEE

17(2)998ndash1022 2015 8

[25] Whats an android mdash my history technology and studies https

historyofmbtwordpresscom20121012whats-an-android 8

[26] Stefan Brahler Analysis of the android architecture Karlsruhe institute for tech-

nology 7 2010 8

[27] Lars Vogel Android sqlite database and contentprovider-tutorial Java Eclipse

Android and Web programming tutorials 2010 8

[28] David Ehringer The dalvik virtual machine architecture Techn report (March

2010) 4 2010 8

[29] Thorsten Schreiber Android binder A shorter more general

work but good for an overview of Binder httpwww nds rub

demediaattachmentsfiles201203binder pdf 2011 8

[30] William Enck Machigar Ongtang and Patrick McDaniel Understanding android

security IEEE security amp privacy (1)50ndash57 2009 9 12

[31] Intents and intent filters httpdeveloperandroidcomguidecomponents

intents-filtershtml 9

[32] Stephen Smalley and Robert Craig Security enhanced (se) android Bringing

flexible mac to android In NDSS volume 310 pages 20ndash38 2013 9

44

REFERENCES

[33] security tips mdash android developers httpdeveloperandroidcomtraining

articlessecurity-tipshtml 10

[34] Erika Chin Adrienne Porter Felt Kate Greenwood and David Wagner Analyzing

inter-application communication in android In Proceedings of the 9th international

conference on Mobile systems applications and services pages 239ndash252 ACM

2011 10

[35] Signing your applications httpdeveloperandroidcomtoolspublishing

app-signinghtml 11

[36] Yajin Zhou Zhi Wang Wu Zhou and Xuxian Jiang Hey you get off of my

market Detecting malicious apps in official and alternative android markets In

NDSS 2012 11

[37] Wu Zhou Yajin Zhou Xuxian Jiang and Peng Ning Detecting repackaged smart-

phone applications in third-party android marketplaces In Proceedings of the sec-

ond ACM conference on Data and Application Security and Privacy pages 317ndash

326 ACM 2012 11

[38] Paul Pearce Adrienne Porter Felt Gabriel Nunez and David Wagner Addroid

Privilege separation for applications and advertisers in android In Proceedings of

the 7th ACM Symposium on Information Computer and Communications Secu-

rity pages 71ndash72 ACM 2012 11

[39] Mengtao Sun and Gang Tan Nativeguard Protecting android applications from

third-party native libraries In Proceedings of the 2014 ACM conference on Security

and privacy in wireless amp mobile networks pages 165ndash176 ACM 2014 11

[40] Lei Wu Michael Grace Yajin Zhou Chiachih Wu and Xuxian Jiang The im-

pact of vendor customizations on android security In Proceedings of the 2013

ACM SIGSAC conference on Computer amp communications security pages 623ndash

634 ACM 2013 12

[41] William Enck Damien Octeau Patrick Mcdaniel and Swarat Chaudhuri A study

of android application security In In Proc USENIX Security Symposium 2011

12

[42] Android (drd) - cert secure coding standards httpswwwsecurecodingcert

orgconfluencepagesviewpageactionpageId=111509535 12

45

REFERENCES

[43] Yu Feng Saswat Anand Isil Dillig and Alex Aiken Apposcopy Semantics-

based detection of android malware through static analysis In Proceedings of

the 22nd ACM SIGSOFT International Symposium on Foundations of Software

Engineering pages 576ndash587 ACM 2014 14 19

[44] Damien Octeau Patrick McDaniel Somesh Jha Alexandre Bartel Eric Bodden

Jacques Klein and Yves Le Traon Effective inter-component communication

mapping in android with epicc An essential step towards holistic security analysis

Effective Inter-Component Communication Mapping in Android with Epicc An

Essential Step Towards Holistic Security Analysis 2013 14 19

[45] Steven Arzt Siegfried Rasthofer Christian Fritz Eric Bodden Alexandre Bartel

Jacques Klein Yves Le Traon Damien Octeau and Patrick McDaniel Flowdroid

Precise context flow field object-sensitive and lifecycle-aware taint analysis for

android apps In ACM SIGPLAN Notices volume 49 pages 259ndash269 ACM 2014

14 19

[46] Li Li Alexandre Bartel Tegawende Francois D Assise Bissyande Jacques Klein

Yves Le Traon Steven Arzt Siegfried Rasthofer Eric Bodden Damien Octeau

and Patrick McDaniel Iccta detecting inter-component privacy leaks in android

apps In 2015 IEEEACM 37th IEEE International Conference on Software En-

gineering (ICSE 2015) 2015 14 19

[47] Long Lu Zhichun Li Zhenyu Wu Wenke Lee and Guofei Jiang Chex statically

vetting android apps for component hijacking vulnerabilities In Proceedings of the

2012 ACM conference on Computer and communications security pages 229ndash240

ACM 2012 14 19

[48] Adam P Fuchs Avik Chaudhuri and Jeffrey S Foster Scandroid Automated

security certification of android applications Manuscript Univ of Maryland

httpwww cs umd eduavikprojectsscandroidascaa 2(3) 2009 14 19

[49] Main page - walawiki httpwalasourceforgenetwikiindexphpMain_

Page 14

[50] Michael C Grace Yajin Zhou Zhi Wang and Xuxian Jiang Systematic detection

of capability leaks in stock android smartphones In NDSS 2012 14 19

[51] Roee Hay Omer Tripp and Marco Pistoia Dynamic detection of inter-application

communication vulnerabilities in android In Proceedings of the 2015 International

46

REFERENCES

Symposium on Software Testing and Analysis pages 118ndash128 ACM 2015 14 17

19

[52] Alexander von Rhein Thorsten Berger Niklas Schalck Johansson Mikael Mark

Hardoslash and Sven Apel Lifting inter-app data-flow analysis to large app sets 2015

14 19

[53] Johnathon Burket Lori Flynn Will Klieber Jonathan Lim and William Snavely

Making didfail succeed Enhancing the cert static taint analyzer for android app

sets 2015 16 19

[54] Jianliang Wu Tingting Cui Tao Ban Shanqing Guo and Lizhen Cui Paddyfrog

systematically detecting confused deputy vulnerability in android applications

Security and Communication Networks 8(13)2338ndash2349 2015 16 19

[55] Patrick PF Chan Lucas CK Hui and Siu-Ming Yiu Droidchecker analyzing

android applications for capability leak In Proceedings of the fifth ACM conference

on Security and Privacy in Wireless and Mobile Networks pages 125ndash136 ACM

2012 16 19

[56] Yibing Zhongyang Zhi Xin Bing Mao and Li Xie Droidalarm an all-sided

static analysis tool for android privilege-escalation malware In Proceedings of

the 8th ACM SIGSAC symposium on Information computer and communications

security pages 353ndash358 ACM 2013 16 19

[57] Michael Dietz Shashi Shekhar Yuliy Pisetsky Anhei Shu and Dan S Wallach

Quire Lightweight provenance for smart phone operating systems In USENIX

Security Symposium page 24 2011 16 19

[58] Sven Bugiel Lucas Davi Alexandra Dmitrienko Thomas Fischer and Ahmad-

Reza Sadeghi Xmandroid A new android evolution to mitigate privilege esca-

lation attacks Technische Universitat Darmstadt Technical Report TR-2011-04

2011 16 19

[59] Ali Magdy Mohsen Mahros and Elsayed Hemayed Firewall-based solution for

preventing privilege escalation attacks in android 17

[60] Sven Bugiel Lucas Davi Alexandra Dmitrienko Thomas Fischer Ahmad-Reza

Sadeghi and Bhargava Shastry Towards taming privilege-escalation attacks on

android In NDSS 2012 17 19

47

REFERENCES

[61] Bradley Schmerl Jeffrey Gennari Javier Camara and David Garlan Raindroidndasha

system for run-time mitigation of android intent vulnerabilities 2016 17

[62] Yajin Zhou Xinwen Zhang Xuxian Jiang and Vincent W Freeh Taming

information-stealing smartphone applications (on android) In Trust and Trust-

worthy Computing pages 93ndash107 Springer 2011 17 19

[63] Alastair R Beresford Andrew Rice Nicholas Skehin and Ripduman Sohan Mock-

droid trading privacy for application functionality on smartphones In Proceedings

of the 12th Workshop on Mobile Computing Systems and Applications pages 49ndash

54 ACM 2011 17 19

[64] Peter Hornyack Seungyeop Han Jaeyeon Jung Stuart Schechter and David

Wetherall These arenrsquot the droids yoursquore looking for retrofitting android to

protect data from imperious applications In Proceedings of the 18th ACM confer-

ence on Computer and communications security pages 639ndash652 ACM 2011 17

19

[65] Siegfried Rasthofer Steven Arzt Enrico Lovat and Eric Bodden Droidforce

Enforcing complex data-centric system-wide policies in android In Availability

Reliability and Security (ARES) 2014 Ninth International Conference on pages

40ndash49 IEEE 2014 17 19

[66] William Enck Machigar Ongtang and Patrick McDaniel Mitigating android

software misuse before it happens 2008 19

[67] William Enck Peter Gilbert Seungyeop Han Vasant Tendulkar Byung-Gon

Chun Landon P Cox Jaeyeon Jung Patrick McDaniel and Anmol N Sheth

Taintdroid an information-flow tracking system for realtime privacy monitoring

on smartphones ACM Transactions on Computer Systems (TOCS) 32(2)5 2014

19

[68] Rubin Xu Hassen Saıdi and Ross Anderson Aurasium Practical policy en-

forcement for android applications In Presented as part of the 21st USENIX

Security Symposium (USENIX Security 12) pages 539ndash552 Bellevue WA 2012

USENIX ISBN 978-931971-95-9 URL httpswwwusenixorgconference

usenixsecurity12technical-sessionspresentationxu_rubin 19

von Styp-Rekowsky Appguardndashenforcing user requirements on android apps In

48

REFERENCES

Tools and Algorithms for the Construction and Analysis of Systems pages 543ndash

548 Springer 2013 19

[70] Benjamin Davis and Hao Chen Retroskeleton retrofitting android apps In

Proceeding of the 11th annual international conference on Mobile systems appli-

cations and services pages 181ndash192 ACM 2013 19

[71] Nicolas Viennot Edward Garcia and Jason Nieh A measurement study of google

play In ACM SIGMETRICS Performance Evaluation Review volume 42 pages

221ndash233 ACM 2014 29

49

Contents
List of Figures
List of Tables
Nomenclature
1 Introduction
- 11 Introduction
- - 111 Our Contribution
  - 112 Assumptions
  - - 12 Inter-Application Communication (IAC) Attack Surface
    - - 121 Inter-App communication in Android
      - 122 IAC vulnerabilities and Attacks
      - 123 Motivating Example
      - 13 Requirement Analysis amp its ingredients
        
        
        2 Literature Survey amp Review
        
        21 Android Platform background security and weaknesses
        
        211 Androids Security model
        
        
        
        
        
        
        25 Capability leaks
        
        
        
        271 Detection
        
        272 Prevention
        
        28 Application and kernel level privilege escalation attack
        
        281 Detection
        
        282 Prevention
        
        
        
        
        
        
        4 Evaluation
        
        41 Evaluation
        
        411 Case Study
        
        42 Performance
        
        4201 Functionality
        
        4202 Size
        
        421 Portability
        
        
        4212 App Store
        
        
        5 Conclusion and Future work
        
        References