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
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
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