47
Security Apps on Android Platform: An Evaluation A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science in Cyber Security by Vikas Yadav 14/MS/028 Under the Supervision of Dr. B. M. Mehtre (Associate Professor) Centre for Cyber Security Institute for Development & Research in Banking Technology, Hyderabad (Established By Reserve Bank of India) COMPUTER SCIENCE AND ENGINEERING DEPARTMENT SARDAR PATEL UNIVERSITY OF POLICE, SECURITY AND CRIMINAL JUSTICE JODHPUR – 342304, INDIA May, 2016

Security Apps on Android Platform: An Evaluation Interns 2016... · Security Apps on Android Platform: An Evaluation A Thesis Submitted in Partial Fulfillment of the Requirements

  • Upload
    donhan

  • View
    220

  • Download
    0

Embed Size (px)

Citation preview

Security Apps on Android Platform: An EvaluationA Thesis Submitted

in Partial Fulfillment of the Requirements

for the Degree of

Master of Sciencein

Cyber Security

by

Vikas Yadav14/MS/028

Under the Supervision ofDr. B. M. Mehtre

(Associate Professor)Centre for Cyber Security

Institute for Development & Research in Banking Technology, Hyderabad

(Established By Reserve Bank of India)

COMPUTER SCIENCE AND ENGINEERING DEPARTMENTSARDAR PATEL UNIVERSITY OF POLICE, SECURITY AND CRIMINAL

JUSTICE

JODHPUR – 342304, INDIAMay, 2016

UNDERTAKING

I declare that the work presented in this thesis titled “Security

Apps on Android Platform: An Evaluation”, submitted to the

Computer Science and Engineering Department, Sardar Patel Uni-

versity of Police, Security and Criminal Justice, Jodhpur, for the

award of the Master of Science degree in Cyber Security, is my

original work. I have not plagiarized or submitted the same work for

the award of any other degree. In case this undertaking is found in-

correct, I accept that my degree may be unconditionally withdrawn.

May, 2016

Jodhpur

(Vikas Yadav)

ii

CERTIFICATE

Certified that the work contained in the thesis titled “Security Apps

on Android Platform: An Evaluation”, by Vikas Yadav, Registration

Number 14/MS/028 has been carried out under my supervision and

that this work has not been submitted elsewhere for a degree.

May, 2016

Dr. B.M. MehtreAssociate Professor

Center for Cyber Security,

Institute for Development and Research in

Banking Technology, Hyderabad

(Established By Reserve Bank Of India)

iii

Acknowledgment

I would like to take this opportunity to express my deep sense of gratitude to all who

helped me directly or indirectly during this thesis work.

First, I would like to thank my supervisor, Associate Professor Dr. B.M. Mehtre , for

being a great mentor and the best adviser I could ever have. His advice, encouragement

and critics are source of innovative ideas, inspiration and causes behind the successful

completion of this dissertation. The confidence shown on me by him was the biggest

source of inspiration for me. It has been a privilege working with him from last five

month.

I wish to express my sincere gratitude to Dr. Bhupendra Singh ,Vice Chancellorand Sh. M.L. Kumawat , Former Vice Chancellor, for providing me all the facilities

required for the completion of this thesis work.

I would like to express my sincere appreciation and gratitude towards faculty mem-

bers at S.P.U.P., Jodhpur, especially Mr. Arjun Choudhary and Mr. Vikas Kr. Sihagfor their encouragement, consistent support and invaluable suggestions. I thanks to Mr.Ghanshyam Bopche Ph.D. scholars who helped me, guided me at the time I needed the

most. Whenever I get nervous, I used to talk with my colleagues. They always tried to

encourage me, without all mentioned above, this work could not have achieved its goal.

iv

Finally, I am grateful to my father Mr. H.S. Yadav , my mother Mrs. Vidya DeviYadav for their support. It was impossible for me to complete this thesis work without

their love, blessing and encouragement.

- Vikas Yadav

v

Biographical Sketch

Vikas Yadav

Bishangarh, Manoharpur, Shahpura, Jaipur (Raj.) PIN-303104

E-Mail: [email protected], Contact. No. +91-9462328623

Father’s Name : Mr. H.S. Yadav

Mother’s Name : Mrs. Vidya Devi Yadav

Education

• Pursuing Master of Science in Cyber, Security Computer Science & Engineering

department from S.P.U.P., Jodhpur.

• B.Tech. in Information Technology from RITM, Jaipur with 61.42% in 2014.

• Intermediate from Govt. Sec. School, Bishangarh with 56.15% in 2007.

• High School from Shri KS Govt. Sr. School, Shahpura with 70.17% in 2005.

vi

Dedicated to My Loving Family for their kind love & support.To my friends for showing confidence in me.

vii

}Learning is no harm, even if done by Reverse Engineering.~-Unknown

viii

Contents

Acknowledgment iv

Biographical Sketch vi

Abstract 1

1 Introduction 21.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Organization of The Thesis . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Literature Survey 5

3 Android OS Architecture and Security 73.1 Android Platform Structure . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 Android Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.2 Hardware Abstraction Layer (HAL) . . . . . . . . . . . . . . . . 10

3.1.3 Native Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.4 Android Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.5 Android Framework . . . . . . . . . . . . . . . . . . . . . . . . 10

ix

3.1.6 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Android Platform Versions . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Android Platform Security . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 System Level Security . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.2 Application Level Security . . . . . . . . . . . . . . . . . . . . . 14

3.4 Android OS Vulnerability Patch Process . . . . . . . . . . . . . . . . . . 15

4 Structure of Android Application 174.1 Introduction of Android Application . . . . . . . . . . . . . . . . . . . . 17

4.2 Security App Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 Security Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Evaluation Methodology 205.1 Dataset Security Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Exploit’s Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Device Level Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.4 App Level Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.5 Privacy Sensitive String Analyzer (PssA) . . . . . . . . . . . . . . . . . . 28

5.5.1 Working of PssA . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.5.2 PssA Result Analysis . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Conclusions & Future Work 316.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

References 34

x

List of Figures

1 Market share of Operating System . . . . . . . . . . . . . . . . . . . . . 8

2 Android Platform Architecture . . . . . . . . . . . . . . . . . . . . . . . 9

3 Distribution of Android OS versions . . . . . . . . . . . . . . . . . . . . 12

4 Permission window at app installation . . . . . . . . . . . . . . . . . . . 14

5 Permissions defined in Androidmanifest file . . . . . . . . . . . . . . . . 14

6 Android OS vulnerability patch process . . . . . . . . . . . . . . . . . . 16

7 Application structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8 Testing of Security Apps . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9 Disassembling process using ApkTool . . . . . . . . . . . . . . . . . . . 26

10 Permissions in AndroidManifest.xml . . . . . . . . . . . . . . . . . . . 27

11 Graph showing number of permissions according to protection Level. The

X-axis is the number of security apps and Y-axis show number of permis-

sions taken by security apps. . . . . . . . . . . . . . . . . . . . . . . . . 28

12 PssA using command prompt . . . . . . . . . . . . . . . . . . . . . . . 29

13 Privacy sensitive strings detection successfully complete . . . . . . . . . 29

14 Privacy sensitive strings declared as HIGH privacy risk . . . . . . . . . . 30

15 Privacy sensitive string in encoded language . . . . . . . . . . . . . . . . 30

xiv

Abstract

Android platform is the most popular open source mobile operating system. Because of

its popularity and open source nature, it is a soft target for hackers community. In practice,

device manufacturers do not provide OS updates for older versions. Instead of patching

old smartphones, they release a new device with upgraded OS versions. Therefore, most

of the unpatched devices are susceptible to attacks. Hence, the user looks for Security

Apps, to get necessary security. Essentially, security Apps claim complete protection for

the devices.

In this research, we have analyzed ten Security Apps in order to validate their claims.

We have tested their effectiveness on different Android OS versions. Essentially we model

various attack scenarios using previously discovered well-known vulnerabilities. Our ex-

perimental results show that few Security Apps generate alerts for insecure settings, but

the majority of them fail to detect OS-level exploits. Further, we performed static analy-

sis of permissions requested by apps at the time of installation. In this, we found out that

most of Security Apps tend to request much more dangerous level permissions than nec-

essary. Apart from this, wee introduce Privacy Sensitive String Analyzer (PssA) a python

based string. It provides a limited but useful functionality for detecting privacy sensitive

string in Android application source code.

1

Chapter 1

Introduction

1.1 Overview

Today, with 81.2% market share, Android has become most popular open-source Oper-

ating System for phones, tablets, and wearable devices [14]. Since the first commercial

release of Android, numerous security vulnerabilities have been discovered in each ver-

sion. The Once a vulnerability is reported, Android security team confirms it, and the

patch delivered by the development team which is distributed to partners. It’s up to the

network carriers, as well as manufacturers, to update all unpatched devices. Instead of

rolling out the patch to all the devices, manufacturer release a new device with patched

OS and higher model number. Therefore, all of the old devices remain unpatched, and this

number increases with each vulnerability reported in Android, which increases the magni-

tude of victims. Furthermore, different types of malware apps, and attack technique such

as denial of service [17], privilege escalation [11] and application repacking, and various

critical vulnerabilities influence the app and system elements. security of Android plat-

form depends on app sandbox environment and app-oriented Mandatory Access Control

(MAC) [6][7]. Each app assigned requested permissions and unique user ID (UID) at the

2

installation time, to execute in a sandbox environment. The sandbox environment avoids

intervention in between apps. The apps are not able to access sensitive data or resources

without appropriate permissions. The majority of apps ask for more extra permissions

than they actually require without provide documentation of permissions on Android OS.

The permissions mishandle can lead a critical risk [13] [16]. Android smartphone pro-

vide many extra functions. Therefore, the app is more complicated and request more

dangerous level permissions.

1.2 Problem Statement

Popularity and open-source nature of the Android platform attract the notorious hackers.

Moreover, every version of Android platforms affected by critical vulnerabilities. Instead

of releasing security patches for old devices, manufacturers release the new device with

upgraded OS versions. Therefore, most of the unpatched devices are prone to attacks.

Hence, the user looks for Security Apps, to get essential security. The security Apps

claim complete protection for the devices nevertheless various studies have demonstrated

that the use of obfuscation techniques can diminish the detection rates of security apps.

Therefore, we evaluate below listed security apps to validate their claims and effec-

tiveness against the well known Android OS-level vulnerabilities. Apart from this, we

performed static analysis on requested permissions of security apps, to check what kind

of permissions are used by these apps.

1. Avira

2. Kaspersky Internet Security

3. Norton Mobile Security

4. Quick Heal Mobile Security

5. McAfee Security

6. 360 Security

7. CM Security

3

8. Avast Mobile Security

9. AVG AntiVirus FREE

10. Comodo Mobile Security

1.3 Organization of The Thesis

The work carried out has been summarized in six chapters.

Chapter 2 We briefly study the related work that has been done in the field of security

apps.

Chapter 3 Provide brief overview of Android platform architecture and security.

Chapter 4 Presents the application structure and give an overview of Security Apps.

Chapter 5 Describe our evaluation methodology and findings

Chapter 6 Conclusions of the thesis and Future Work.

4

Chapter 2

Literature Survey

The expansion of malware on Android platform has led to various studies into its char-

acterization. Zhou et. al. [21] conducted a survey on a large dataset of 1,260 Android

malware samples in 49 different malware categories. They noticed that the most widely

recognized malware are legitimate applications repackaged with malicious payloads. Be-

cause of the malware risk, various identification techniques have been proposed to recog-

nize malware. Arp, Daniel, et al. [5] propose DREBIN, which applies machine learning

strategies on a huge dataset of 5,560 malicious samples and 123,453 benign and claims a

94% detection rate.

It is not clear, what detection method Android security apps use. Furthermore, An-

droid Security Apps run within the sandbox with limited resources, such as processing

power and battery life. Cai and Yap [8] determine the key elements used by the Security

Apps. To find detection logic, they conduct a study on 57 Android Security Apps using

2000 malware variations. They found that Security Apps use simple static features, which

easily elude by encrypting and renaming strings. Rastogi et al. (2013) [15] analyzed An-

droid Security Apps against different basic obfuscation strategies. They tested 10 Security

Apps (different from ours) using a dataset of 6 malware tests in 6 malware families. They

5

applied eight obfuscation techniques on the samples and testing the variants on the Secu-

rity Apps and found all of them failed to recognize the modifications.

The Android platform has permissions based mechanism to access data or critical

resource of the device. At the time of installation system prompts requested permissions

by an app. The user must accept all permissions to install the app. It is a presumption

that apps typically need less than full privileges. Wei et al. (2012) [18] found that most of

the apps are over privileged. The developer of app tend to access more hardware features

and use customized permissions. Fang et al. (2014) [12] inspect emerging concerns in

Android security, incompetent permission control, including coarse-grained permissions,

poor documentation, and permission escalation attack. They represent the connections

among these issues and analyze of the current countermeasures to address these problems.

Above stated studies have demonstrated that the use of obfuscation techniques can

diminish the detection rates of security apps. Therefore, we evaluate the behavior of

security apps against well-known OS level vulnerabilities.

6

Chapter 3

Android OS Architecture and

Security

3.1 Android Platform Structure

Android platform is one of the most famous open source operating system for phones,

tablets, wearable devices and consoles. It provides advanced computational capabilities

with better hardware configuration. Therefore user shifts from traditional computers and

laptops to smartphones. Android have largest market share 81.2% among all other mobile

Operating Systems. Figure 1 shows the total market share of Android Platform.

7

Figure 1: Market share of Operating System

Android is a software stack, which includes an application framework and core appli-

cations. Figure 2 shows an overview of the Android architecture. Android Software stack

consists of different segments that allow developers and device manufactures to work

independently. It is divided into five major components.

1. Linux kernel

2. Hardware Abstraction Layer (HAL)

3. Native Libraries

4. Android Runtime

5. Android Framework

6. Application

8

Figure 2: Android Platform Architecture

9

3.1.1 Android Kernel

Heart of Android OS architecture exists on the root level. it is in charge of device man-

agement, power management, device driver, memory management and resource access.

Initially, Android OS based on Linux kernel version 2.6 with a few enhancement for mo-

bile devices. Currently Linux Kernel version 3.4 or 3.10 used in Android Architecture,

specific version depends on device’s hardware platform.

3.1.2 Hardware Abstraction Layer (HAL)

The hardware abstraction layer characterizes a standard interface for hardware merchants

to implement and permits Android to be skeptic about lower-level driver executions. The

HAL provide to execution functionality without adjusting or influencing the higher level

system.

3.1.3 Native Libraries

Native libraries like OpenGL, FreeType, Webkit, SQLite, libc(C runtime library), Media,

work on the top the kernel layer. Every Library have a different function such as SQLite

for the database, Webkit for browser support, to provide internet security SSL is used, For

font support use FreeType library, for playing audio and video files Media library used.

Native libraries are written in C/C++ programming language.

3.1.4 Android Runtime

Core Java Libraries and Dalvik Virtual Machine are the main components of Android

Runtime. Every app runs with the help of these two components. Dalvik VM imple-

mented by Google, similar like JVM. It provides fast performance and expands less mem-

ory.

3.1.5 Android Framework

Android platform provides a rich application framework that allows the developer to build

innovative apps for the smartphone in a Java language environment. This layer works on

10

the top of Native Libraries in Android OS stack. Apps instantly interact with Android

framework. It gives the major APIs that the app will utilize including things like package

manager, telephony manager, Resource Manager, Content manager, View system and

receiving notification.

3.1.6 Application

An application that supports everyday need like e-mail, browsing, contact, games, set-

tings, phone, etc. these apps was developed in Java programming language by the de-

velopers. Google Play Store is a digital distribution platform operated by Google. The

user can download the millions of latest Android apps, games, music, movies, TV, books,

magazines & more. Anytime, anywhere, across your devices [1].

3.2 Android Platform Versions

After Android alpha, Google released Android 1.0 in September 2008, its first commercial

version. After that Google and the Open Handset Alliance (OHA) continually develop

and updates its initially released version. Latest OS version Android 6.0 code name is

Marshmallow, was released in 2015 [19], October. Recently Google Announce their next

version Android 7.0 code name Android N, which is available in beta version [4].

11

Figure 3: Distribution of Android OS versions

3.3 Android Platform Security

After the first release of Android platform, many remarkable, changes come in Android

platform security, such as enhance application sandbox with SELinux, Guest Mode, Full

disk encryption and improve detection and reaction mechanism for the safety vulnerabil-

ities. However, Android security divides into two level.

1. System Level Security

2. Application Level Security

3.3.1 System Level Security

At System Level Security, Android provide an extra layer. Following security viewpoints

come under system level security.

12

Linux Security

Android platform based on Linux kernel. Linux was build and test by security experts all

over the world. Which makes it a stable and secure Kernel.

SELinux

To provide more security and reliability Android involve the Security Enhanced Linux

(SELinux) in Android version 4.3 and later. It uses Mandatory Access Control (MAC)

environment in instead of Discretionary Access Control (DAC). [3] MAC provide extra

protection against potential security vulnerabilities by protesting of system services to the

applications.

Application Sandboxing

On Android platform every app assigned a unique User ID (UID) at the installation time

and execute in a sandbox environment. The sandbox environment avoids intervention

in between apps. The apps are not able to access sensitive data or resources without

appropriate permissions.

Cryptography

Android platform uses cryptographic techniques which are used by apps to provide secu-

rity to sensitive data and resources. Mostly AES, SHA, RSA and DSA.

Password Protection

Different device locking techniques used on Android platform to protect data from unau-

thorized access such as PIN, Password, Pattern, Face Lock and Fingerprint.

13

3.3.2 Application Level Security

Permission Model

Android Security relies on the permission-based model. The system will prompt list of

permissions (Figure 4 ) requested by the app, at installation time. To install an app, the

user must accept all permission requested by the app.

Figure 4: Permission window at app installation

These permissions defined in Androidmanifest file ( Figure 5 ) of the App, using

permissions apps can be able to access resource and data. In section 5.4 we use these

categories.

Figure 5: Permissions defined in Androidmanifest file

14

Further, Permissions classifies into four categories according to their protection level:

1. Normal : A low-risk permission to access API calls and automatically granted

when app request them, Such as SET WALLPAPER.

2. Dangerous : A high-level permission. These permissions have possible risk Be-

cause they provide access to sensitive user data and devices resource. Such as

READ CONTACTS, READ LOGS.

3. Signature : Requesting app and declared app signed with the same certificate then

system automatically allow the permissions with informing the user. If apps have

same sign certificate then can share data or resources.

4. Signature or System : If requesting app is in the same system or signed with the

same certificate.

Application Signing

The developer must sign the apps before uploading on Google PlayStore. Every App has

unique package name, which helps to identify the app developer. At installation time,

certificate of an app is verified with signature. Two apps with same signature can share

same Dalvik VM.

App from Unknown Source

Android platform allows the user to install the third-party app. However, initially this

functioning not enabled, the user activates manually.

3.4 Android OS Vulnerability Patch Process

Android security team is manage security vulnerabilities found in the Android OS. In

Figure 6 shown vulnerability patch process. After reporting a vulnerability, it notified

to original equipment manufacturer (OEM) partners. The development team responsible

for fixing the bug, then release it to Android OEM partners. Device manufacturer makes

15

patches according to their device hardware. Afterward, patch released to the user device

over the air (OTA) for installation. Sometimes network carrier partners also involved.

It’s up to the network carriers, as well as manufacturers, to more frequently update

a large set of devices. Manufacturer instead of providing the patch for old OS-versions,

release the new device with upgraded OS version. Therefore, all of the old devices remain

unpatched, and this number increases with each update from Android, which increases the

magnitude of victims. These old unpatched devices have the potential risk and soft target

for hackers.

Figure 6: Android OS vulnerability patch process

16

Chapter 4

Structure of Android Application

4.1 Introduction of Android Application

Android Applications are written in Java language. All necessary data to run an app,

are compiled in an archive file with a .apk extension. At the installation time, each app

assigned a unique Linux user ID, which used by the system to identify the app. Each app

works in a sandbox environment. Therefore, app’s code is isolated from all other apps.

This sandbox environment not allows to an app to access data and resources. Therefore, an

app that wants to get specific system component and resources must request appropriate

permission. If two applications have same Linux user ID, then apps run in a same virtual

machine. To obtained same Linux user ID, an application signed by same certificates.

4.2 Security App Structure

Each Android App have same structure as shown in Figure 7.

17

Figure 7: Application structure

Every Android App has the same structure as shown in Figure 7. The app components

are explained below as follow:

1. Manifest File: It contains essential details of app package and other components

of the app such as services, broadcast receivers, activities, content providers, etc.

It also provides information about permissions required by the app. Hardware and

software features such as camera, Wi-Fi, GPS services, required by the app has to

be in the manifest file.

2. META-INF: This directory contain following three files.

(a) MANIFEST.MF: It is used by manifest file.

(b) CERT.RSA: Certificate of the app.

(c) CERT.SF: This file contain SHA-1 digest of the corresponding lines in the

MANIFEST.MF file and list of resources.

3. classes.dex: This file contains compiled Java classes in dex format, which is exe-

cuted in Dalvik VM.

18

4. res: This directory contains application resources such as sounds, graphics, etc.

5. resoures.arsc: Contains precompiled resources such as binary XML files.

4.3 Security Apps

As Android enabled device market grows, Security application developer also looks into

it. The Computer Anti-Virus Tool developer also have an Android App version on Google

PlayStore. The Security Apps have similar functionality like computer Anti-Virus tool.

Same as a traditional PC Anti-Virus, Android Security Apps claim complete security for

the devices. These Security Apps provide protection from virus, spyware, and malware.

They also offer some extra features, such as Anti-theft, Backup of data, remote wipe of

data and finding location. These additional feature useful when device lost or stolen. The

user can control their device using web interface and registered mobile numbers.

However, There are some limitations for Security Apps. First, On Android Platform,

every application execute in a sandbox environment. Therefore, Security Apps does not

have Kernel level privileges like traditional PC Anti-Virus tools. Second, Android Smart-

phone has a limited power source, processing power, and network bandwidth in compare

to Computer. Therefore, Security Apps quit restricted to perform functionality on An-

droid Platform. On Google PlayStore [1] free of licensed version of security apps are

available, the user can download and install directly on the device.

19

Chapter 5Evaluation Methodology

5.1 Dataset Security Apps

We start by describing our Security Apps and Exploits, followed by our evaluation ap-

proach, and then discuss our results. We tested 10 Security Apps (Table 1) against three

well-known Android OS-level vulnerabilities (List 5.2). We select these 10 Security Apps

from Google PlayStore [1] based on following criteria such as:

1. Popularity and ranking in security apps on PlayStore.

2. Simplicity and performance.

3. Anti-Virus engine for both cloud and local.

4. Apps and System Scan capability.

5. SD Card Scanner.

6. On app installation scan.

7. Safe Browsing.

20

8. Scan settings and advice for unsecured settings.

9. Review from Users.

We do not violate the end user license agreement, when we perform reverse engineering.

In our work Security Apps will be mentioned as SA1, SA2, ....., SA10.

Table 1: Selected Security Apps for Testing

SA App Name Package nameSA1 Avira com.avira.android

SA2 Kaspersky Internet Security com.kms.free

SA3 Norton Mobile Security com.symantec.mobilesecurity

SA4 Quick Heal Mobile Security com.quickheal.platform

SA5 McAfee Security com.wsandroid.suite

SA6 360 Security com.qihoo.security

SA7 CM Security com.cleanmaster.security

SA8 Avast Mobile Security com.avast.android.mobilesecurity

SA9 AVG AntiVirus FREE com.antivirus

SA10 Comodo Mobile Security com.comodo.cisme.antivirus

5.2 Exploit’s Introduction

We choose three exploits list 5.2, the reason behind choosing these exploits:

• Listed exploits are easily available on Internet.

• Vulnerable Android OS version from these exploits are still used by a large number

of users.

1. Exploit 1: Web View attack [9] Uses a vulnerability, which is exits in between the

interface of JavaScript and Java to install a remote shell. This exploit available on

Metasploit module in Kali Linux 2.0.

21

2. Exploit 2: reverse tcp attack Create payload using Metasploit module in Kali

Linux 2.0 platform and embed the payload in a legitimate apk to get remote access

of device.

3. Exploit 3: Stagefright [10],[22] We use a arbitrary code which is crafted in meta-

data of MP4 file to get remote access.

5.3 Device Level Analysis

Figure 8: Testing of Security Apps

22

We have chosen three well known Android vulnerabilities on three different OS versions

Table2. Description of exploits we already provide in Section 5.2. Our device level anal-

ysis approach depicted in Figure 8.

Table 2: List of Test Device Versions

Device OS Name OS VersionTest Device 1 Jelly Bean 4.1.1

Test Device 2 KitKat 4.4.2

Test Device 3 Lollipop 5.0.2

Following steps are performed to test Security Apps on device:

Step 1 Install Security App on the test device.

Step 2 Start Security App and perform a complete scan (Passive Scan). The scan results

are tabulated in Table 3 as alert.

Step 3 Check scan result of passive scanning and evaluate the result.

Step 4 Exploit attacks and check Security App’s action (Active Scan). The active scan

results are tabulated in Table 3 as detection.

Step 5 Un-Install the Security App.

Step 6 Start from step 1 to analysis rest of SA2, SA3, ....., SA10.

We model three Attack Scenarios: Attack Scenario 1, 2,and 3In Attack Scenario 1, we test each Security Apps one by one against exploit 1, 2 and 3

on Test Device 1. Same as we evaluate all Security Apps in Attack Scenario 2 on Test

Device 2 and Attack Scenario 3 on Test Device 3. The obtained results are tabulated in

Table 3.

Findings 1 The examination was made on the capability of Security Apps to generate

alert and detection message about malicious and unsecured settings, such as Install apps

from unknown source, USB debugging and unsecured browsing. For exploit 1, we found

23

that only McAfee Security and Avast Mobile Security generate an alert warning and detect

insecure web browsing. The WebView exploit works only on Test Device 1, other device

versions patched for this vulnerability. However, none of the security apps does not detect

malicious URL.

Findings 2 For attack scenario 2, we observe that majority of security apps gener-

ate the alert message in passive scanning stage about unsecured settings. These alert

messages useful for security unconscious users. We find that Norton Mobile Security,

McAfee Security, and Avast Mobile Security generate the warning for all three Test de-

vices. Active scan result shows that apk file has been found to contain Malware and

recommend that you remove this apk file immediately.

Findings 3 When we send crafted MP4 to test devices, all Security Apps fail to detect

the arbitrary code, crafted in the metadata of MP4 file.

24

Attack 1 Attack 2 Attack 3Security Apps Device Alert Detection Alert Detection Alert Detection

SA 1

Device 1 No No Yes Yes No No

Device 2 No No No No No No

Device 3 No No No No No No

SA 2

Device 1 No No No No No No

Device 2 No No No No No No

Device 3 No No Yes Yes No No

SA 3

Device 1 No No Yes Yes No No

Device 2 No No Yes Yes No No

Device 3 No No Yes Yes No No

SA 4

Device 1 No No No No No No

Device 2 No No No No No No

Device 3 No No No No No No

SA 5

Device 1 No No No No No No

Device 2 Yes Yes Yes Yes No No

Device 3 Yes Yes Yes Yes No No

SA 6

Device 1 No No No No No No

Device 2 No No No No No No

Device 3 No No No No No No

SA 7

Device 1 No No No No No No

Device 2 No No No No No No

Device 3 No No No No No No

SA 8

Device 1 No No Yes Yes No No

Device 2 Yes Yes Yes Yes No No

Device 3 Yes Yes Yes Yes No No

SA 9

Device 1 No No Yes No No No

Device 2 No No No No No No

Device 3 No No No No No No

SA 10

Device 1 No No No No No No

Device 2 No No No No No No

Device 3 No No No No No No

Table 3: Results for Attack Scenario 1, 2 and 325

5.4 App Level Analysis

In application level evaluation we perform static analysis using ApkTool [20]. This tool

is able to disassemble APK file resources such as Android’s binary XML, SMALI and

Java code, strings without executing the application. After extracting the permissions of

Security Apps from their Androidmanifest file by performing reverse engineering.

Figure 9: Disassembling process using ApkTool

26

Figure 10: Permissions in AndroidManifest.xml

We observe that, security apps have the tendency to gain critical resources related

permissions Such as:

• READ PHONE STATE

• CALL PHONE

• WRITE EXTERNAL STORAGE

• READ CONTACTS

• WRITE CONTACTS

• READ SMS

• READ CALL LOG

• WRITE CALL LOG

• CHANGE WIFI STATE

27

• ACCESS COARSE LOCATION

• ACCESS FINE LOCATION

• WRITE EXTERNAL STORAGE etc.

These above-listed permissions have dangerous protection level. Our static analysis

result shows that out of defined 130 permissions, security apps request approx 85 permis-

sions. The majority of apps ask 30-35 dangerous level permissions.

Figure 11: Graph showing number of permissions according to protection Level. The

X-axis is the number of security apps and Y-axis show number of permissions taken by

security apps.

5.5 Privacy Sensitive String Analyzer (PssA)

We present a Privacy-Sensitive String Analyzer (PssA), a static analysis python script.

PssA provides a limited but useful functionality for detecting privacy sensitive string in

android app source code. Such as IP address, email id, username, password, IMEI, and

28

dbname. Using PssA we able to know, that how developer use and declare sensitive pri-

vacy strings in app’s source code.

5.5.1 Working of PssA

To work with PssA, we need to install Python 2.7 [2] and ApkTool [20] on system.

Step 1 Put PssA script and .apk file in a same directory and run PssA using Windows

command prompt. 1

Step 2 It will ask apk file, give complete app name with .apk extension as Figure 12.

Step 3 It will take some time and shows a completion message as Figure 13.

Step 4 It will generate a log file with given app name. we can manually analysis this log

file.

Figure 12: PssA using command prompt

Figure 13: Privacy sensitive strings detection successfully complete

1we can run PssA with Python IDE also.

29

5.5.2 PssA Result Analysis

When we analysis log file manually, we found that majority of security apps contain

privacy sensitive strings. App developer declare these privacy sensitive strings same as

shown Figure 14,15. These strings are susceptible as privacy perspective and many harm

user device.

Figure 14: Privacy sensitive strings declared as HIGH privacy risk

Figure 15: Privacy sensitive string in encoded language

30

Chapter 6Conclusions & Future Work

6.1 Conclusions

In this research work, we evaluate the effectiveness of 10 security apps against the well-

known OS-level vulnerabilities. Based on our device level findings, we show that majority

of security apps (7/10) failed to detect OS-level vulnerabilities. However, few security

apps (3/10) generate an alert message for unsecured settings. In addition, based on the

static analysis of permissions gained by security apps on their protection level, we show

that security apps tend to gain dangerous level permissions.

6.2 Future Work

We have identified two issues in Security Apps, including insufficient permission doc-

umentation and effectiveness of Security Apps against OS-Level attacks on unpatched

Android OS versions. However, Our study is limited in two ways: First, We analyzed

a small number of security apps against limited exploits. Second, Selection of security

apps is biased towards popularity in ordinary users. We found that majority of security

31

apps are not aware of OS-Level vulnerabilities, tend to request more permissions related

to critical resources of the device and contain privacy sensitive strings. These all issues

may lead to financial loss or privacy leakage directly. There remains a requirement for

active security applications that able to detect and mitigate OS-level exploits.

In the future work, we have to consider the said limitations and develop the solution to

enhance the effectiveness of the security apps.

32

Authors Publications

Vikas Yadav, Babu M. Mehtre, ”Security Apps on Android Platform: An Evaluation”,

Submitted to journal of Digital Investigation, Elsevier, in May 2016

33

References

[1] Playstore. URL: https://play.google.com/store.

[2] pyhton. 2016. URL: https://www.python.org/.

[3] Selinux. 2016. URL: https://source.android.com/security/

selinux/.

[4] Android-Developers, . Android-n. 2016. URL: http://developer.

android.com/preview/index.html.

[5] Arp, D., Spreitzenbarth, M., Gascon, H., Rieck, K.. Drebin: Effective and

explainable detection of android malware in your pocket. 2014. .

[6] Barrera, D., Kayacik, H.G., van Oorschot, P.C., Somayaji, A.. A methodology

for empirical analysis of permission-based security models and its application to

android. In: Proceedings of the 17th ACM Conference on Computer and Commu-

nications Security. ACM; CCS ’10; 2010. p. 73–84.

[7] Bartel, A., Klein, J., Le Traon, Y., Monperrus, M.. Automatically securing

permission-based software by reducing the attack surface: An application to an-

droid. In: Proceedings of the 27th IEEE/ACM International Conference on Auto-

mated Software Engineering. ACM; ASE 2012; 2012. p. 274–277.

34

[8] Cai, Z., Yap, R.H.. Inferring the detection logic and evaluating the effectiveness of

android anti-virus apps. In: Proceedings of the Sixth ACM Conference on Data and

Application Security and Privacy. ACM; CODASPY ’16; 2016. p. 172–182.

[9] (CVE-2013-4710), . Webview-attack. 2013. URL: https://www.

cvedetails.com/cve-details.php?t=1&cve_id=CVE-2013-4710.

[10] (CVE-2015-6602), . Webview-attack. 2015. URL: http://www.cvedetails.

com/cve-details.php?t=1&cve_id=CVE-2015-6602.

[11] Davi, L., Dmitrienko, A., Sadeghi, A.R., Winandy, M.. Information Security:

13th International Conference, ISC 2010, Boca Raton, FL, USA, October 25-28,

2010, Revised Selected Papers; Springer Berlin Heidelberg. p. 346–360.

[12] Fang, Z., Han, W., Li, Y.. Permission based android security: Issues and counter-

measures. Computers & Security 2014;43:205 – 218.

[13] Felt, A.P., Chin, E., Hanna, S., Song, D., Wagner, D.. Android permissions

demystified. In: Proceedings of the 18th ACM Conference on Computer and Com-

munications Security. ACM; CCS ’11; 2011. p. 627–638.

[14] NetMarketShare, . Market share reports (source of analytics data). 2016. URL:

https://www.netmarketshare.com/.

[15] Rastogi, V., Chen, Y., Jiang, X.. Droidchameleon: Evaluating android anti-

malware against transformation attacks. In: Proceedings of the 8th ACM SIGSAC

symposium on Information, computer and communications security (ASIACCS).

2013. p. 329–334.

[16] Sarma, B.P., Li, N., Gates, C., Potharaju, R., Nita-Rotaru, C., Molloy, I.. Android

permissions: A perspective combining risks and benefits. In: Proceedings of the

17th ACM Symposium on Access Control Models and Technologies. SACMAT ’12;

2012. p. 13–22.

[17] Traynor, P., Lin, M., Ongtang, M., Rao, V., Jaeger, T., McDaniel, P., La Porta,

T.. On cellular botnets: Measuring the impact of malicious devices on a cellular

35

network core. In: Proceedings of the 16th ACM Conference on Computer and

Communications Security. ACM; 2009. p. 223–234.

[18] Wei, X., Gomez, L., Neamtiu, I., Faloutsos, M.. Permission evolution in the

android ecosystem. In: Proceedings of the 28th Annual Computer Security Appli-

cations Conference. New York, NY, USA: ACM; ACSAC ’12; 2012. p. 31–40.

[19] wikipedia, . Android-marshmallow. 2016. URL: https://en.wikipedia.

org/wiki/Android_Marshmallow.

[20] Winsniewski, R.. Android–apktool: A tool for reverse engineering android apk

files. 2012.

[21] Zhou, Y., Jiang, X.. Dissecting android malware: Characterization and evolution.

In: 2012 IEEE Symposium on Security and Privacy. 2012. p. 95–109.

[22] Zimperium, . Stagefright vulnerability. 2015. URL: https://blog.

zimperium.com/stagefright-vulnerability-details-stagef;

right-detector-tool-released/.

36