Possible Attacks On Android Computer Science Essay

Published Date: 02 Nov 2017

Making Users More Conscious Against

Possible Attacks on Android

Burak SOYKAL

Matrikelnummer: 0427197

Studienkennzahl: 534

Emre Can SÖNMEZ

Matrikelnummer: 0427232

Studienkennzahl: 535

Technische Universität Wien

Fakultät für Informatik

Supervisor

Assoc. Prof. Dipl.-Ing Inin Drin Hilda Tellioglu

----------------------- Page 2-----------------------

Contents

1 Background 4

2 Evaluating Android Security 6

2.1 Threat and Aims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Control Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Rooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Known Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Android Permissions 12

3.1 Enforcement of Permissons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 A Case Study 22

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3 Proceedings and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Conclusion 34

----------------------- Page 3-----------------------

Abstract

In this paper we present the results of a test we conducted - asking users from dif-

fering age groups and knowledge of OS platforms to try out the application that we

have developed. Before and after exploring our application (meant to heighten user

awareness of security problems with permissions on mobile devices) the users were

asked to fill out a questionnaire so that it could be deduced whether they had under-

stood the way permissions are used and which dangers they pose. Our results show

that there was definite improvement and that the experiment was indeed successful

and apps such as our could benefit users from all walks of life..

3

----------------------- Page 4-----------------------

1 Background

Android is an operating system that was designed for use on mobile devices, namely smartphones

and tablets. It is owned by the tech behemoth Google. It is an open-source and programmable

software development framework, and was announced for the first time in 2007. It became the

leading smartphone platform in the end of 2010 with a 32% market share, subsequently reaching

68.1% of the market in the second quarter of 2012. [1, 2]. In the third quarter of 2012, more than

1 million new Android devices were being activated daily. [3].

Android Architecture: An Android application consists of diverse parts[4], each with a different

function. The 4 components will be dealt with in detail in the following text.

Activities are what the user sees when he is interacting with the application. In essence, an

activity is a single screen with user interface. It allows the user to communicate with the

application.

Services represent background processes. A service has no user interface and is mostly

used by long running operations to enable performance without blocking out the user. An

example for a service would be music playing in the background without blocking the user’s

interaction with the application.

Content providers are used to store and retrieve data from a shared set of application data

storage. This kind of data can be kept in, for example, the SQLite database of the mobile

device, and can be queried, even modified.

A number of content providers will be arranged for by Android, ContactsContract for con-

tact management, MediaStore for various multimedia files and CalendarContacts for access

to the calendars on the device.

Broadcast receivers are components that react to broadcast messages (which can be created

by different sources). As an example, Android alters the user of the battery’s low status

by posting messag. Other applications can get this message and adapt their behaviour (for

example, a game getting this message could be saving the player’s progress as a precaution).

This component is also used for status bar notifications.

Google uses this component to kill unwanted applications from a users device. Google Play

pushes the REMOVE_ASSET message to the device and this message could be received with

this component. With the INSTALL_ASSET message, various applications from the market

could also be installed.[5]

Listing 1.1: Identifying a Broadcast reciever

<receiver android:name=".Receiver" android:exported="true">

<intentfilter android:priority="1000">

<action android:name="android.provider.Telephony.SMS_RECEIVED"/>

</intentfilter>

</receiver>

----------------------- Page 5-----------------------

Figure 1.1: Android System Architechture [A]

Figure 1.1 shows the 4 different layers of Android’s operating system. The monolithic Linux

kernel resides in the lowest layer of the system and has been highly optimized and adequately

adapted for the mobile environment. It is in charge of memory and process management. It

includes drivers for hardware; IPC (Inter-process Communication)- which is in charge of the com-

munication between processes and threads; and lastly file system access.

The second layer is where the native libraries of the Android system are kept. These libraries are

written in the C/C++ programming language and can be used by the other components from the last

2 layers. SQLlite is responsible for database management, WebKit is in charge of web rendering

purposes. Media codecs are responsible for playing different kinds of multimedia formats such as

MP3, MPEG4, H.264.

To the right of these libraries is Android runtime. Dalvik Virtual Machine is a different version

of the Java Virtual Machine, which has been optimized to meet the requirements of a mobile

environment. Dalvik uses one .dex file to save all the compiled source code from the applications,

which are written as bytecodes to boost efficiency. These libraries are written in the Java language.

The third layer is the Application Framework layer, which is essential for developers, since it

contains Java frameworks, in other words, APIs. In this layer there are different Managers that

have different roles. PackageManager is responsible for retrieving different types of information

from installed or running applications. NotificationManager is charged with notifying the user

of the events that are currently underway (e.g. information being displayed in the status bar).

ViewManager is responsible for drawing and event handling.

The last layer, called the Application layer, is home to the applications that are currently installed

in the system. A multitude of similar apps come with the device and are tasked with the central

functions of the device, such as messaging and making phone calls.

5

----------------------- Page 6-----------------------

2 Evaluating Android Security

2.1 Threat and Aims

Malicious Applications

Malicious applications are the most common source of infection, which could certainly be com-

pared to the "trojans" on the PCs. An experienced programmer can write malicious code into the

program that he/she has created or could use the "repackaging" process to download non-free pop-

ular applications, alter them by using the malicious code, and upload it back into the app market

(Figure 2.1). This is a source of concern for users who are unwilling to pay for non-free applica-

tions. In addition, users can choose to allow the installation of an application, that they download

from various suspect websites, which is very convenient for the attackers.

According to the research of Y. Zhou and X. Jiang, 1083 (86.0%) of 1280 malware samples they

have collected were repackaged versions of legitimate applications. 36.7% of these applications

were using root-level exploits and more than 90% were turning the devices into botnet controlled

through SMS and network.[6]

Non-free applications aren’t the only problem that users can come across. Free applications

are widely spread and could also be malicious. Until it becomes apparent that this application is

malicious, it will not be removed from the market, which will be very unfortunate for normal-end

users. Malicious code could also arrive to the users’ devices via updates; once the users allow the

automatic update process. It is also possible for the attacker to get a hold of the developers account

and push the malicious update.[7]

Modified operating systems (as known as Custom Roms) are one the largest sources of malicious

applications. The fact that most of them come rooted makes the situation worse than usual. Since

these custom ROMs come with pre-installed applications, their legitimacy can not be guaranteed.

Some attackers could fool users into believing that there is a critical update due and tell them

it can be download from a certain website. In this way, a new application update or a brand new

application with the same icon and description could be downloaded and installed.

According to a research[8], three types of threats can be defined:

Malware: Malware could be defined as Trojans, botnets and worms. Malware can be created

for many reasons but the main objective is financial return. Beyond the main objective, other goarls

could be summarized as purposefully annoying users and gaining control of the whole systems.

They are considered illegal in many countries and can are punishable by jail time.

Personal Spyware: Spyware is used to collect information, which may originate from short

messages or location histories. It does not do any particular damage but may steal confidential

information.

Grayware: Grayware collects data from users so that they can be sold for marketing or user

profiling purposes.

----------------------- Page 7-----------------------

Figure 2.1: Repacking Process

Stolen/Lost Phones

Lost and stolen mobile devices can present a huge problem; due to the fact that the mobile device

is viewed as a private belonging, device owners tend to not put any kind of security mechanism on

it. Sometimes using a security mechanism on the phone could be viewed as futile because once

another person has this device, most of the protection layers are easily surpassed. If the device has

a PIN lock, it could be unlocked in a cell phone store at a moment’s notice.

Depending on the the research that Lookout have conducted;[9]

People in the U.S lose a smartphone once a year.

During 2012 New Year’s, $14 million worth of phones were lost.

Each day, $7 million worth of phones are lost.

User Behaviour

Compared to the other threats, user behavior could be the most important point in the field of

mobile device security. Personal and business use of the device must be segregated. Employees

using company phones are often unaware of a security policy being applied, ignoring what it means

for personal and business usage. For example, an employee can deactivate any kind of security

application on the device if he/she has no restrictions to do so, unknowingly download and install

a malicious application, storing confidential files in plain sight and changing system settings that

may give the malicious applications a chance to take over the system. These kinds of actions may

lead to vulnerable exposure of the company itself. Surveys show us that one third of the employees

need to refrain from the security policies to be able do their jobs.[10]

2.2 Control Access

Because different smartphone platforms have different security characteristics, smartphone secu-

rity applications, suites and services need to take into consideration many points when dealing with

7

----------------------- Page 8-----------------------

various facts - such as user behaviour, phone access, network and data storage. There are many

ways in which the applications could take care of security - encryptions, antivirus applications,

firewalls and remote access, all used in order to be able to protect the sensitive information that

is stored on the device, or protect the device itself. Remote access can lock the device, install a

password and even locate the device by turning on its GPS tracking. Firewalls can block incoming

and outgoing data packages.

Network can be controlled in various ways. Users could use Virtual Personal Networks to

connect to the network in a safer way and protect the data. Wireless networks connected to the

device can be protected by using conventional security protocols such as WPA (Wi-fi Protected

Access), WPA2 (Wi-Fi Protected Access II) for authentication and AES (Advanced Encryption

Standart) could be used to to encrypt the passing data. Companies that supply devices to their

staff must be held accountable for security. The staff is not liable since security is not just about

applications.

Authentication

Authentication is the way to ensure that solely the people who are supposed to be authorized users

are granted access to the system. There are two different ways of how authentication works, one

being that user provides some kind of information (such as a username and password). If the

authentication is approved, the user has been granted access to the system. The other type is two-

factor authentication, which requires two out of these three factors: something the user knows;

something the user has and something the user is. The user has to know and have at least two out

of these three factors to be able to get access to the system.

In the case of mobile devices two-factor authentication is seen as rather unnecessary or even

useless since a single device is not being shared between people. On smartphones authentication

is undertaken by using a PIN (Personal Identification Number), which is randomly chosen by the

network provider and may be subsequently changed by the user. PIN2 is another mean used for the

protection of certain network settings. PIN gives the cellular network access to the device. This

ensures that if the SIM card is inserted in another device, only the person who knows the code can

use the cellular network. A survey has shown that only 34% of mobile device owners did not use

PIN protection at all and 18% of these users utilized the standby PIN protection [11].

In order to add an extra layer of security to Android, iOS and BlackBerry devices, Google has

developed its own "Two-step authentication", which requires the user to enter a six-digit code to

be allowed to use specific Google services. This six-digit code can be generated by an application

called Google Authenticator. If the user does not accomplish this, the code can be sent to the

him/her via SMS. This Google service uses the time-based One-time Password Algorithm and the

HMAC-based One Time Password Algorithm to generate its codes.[12]

There are some contingencies that Google has thought of:

Backup phone numbers:

The user will be asked to provide a backup phone number that could be used to obtain a new

code in case the primary phone number is indisposed.

Backup codes:

The user will be given a set of codes, only to be used once if the main and backup phones

are unavailable. This will allow the user to sign in and set things in order.

8

----------------------- Page 9-----------------------

Network connection:

Google Authenticator does not require a working network connection.

There are also other authentication types that grant users access to the device, such as passwords

and the pattern screen lock, as well as face recognition. Passwords provide a higher level of

security than PIN numbers, since they don’t have to consist of numbers and are not of limited

length. Pattern screen locks are basically used to unlock the phone by using a relatively simple 3

x 3 grid. It is done by connecting dots in different ways, in which one dot can be passed over only

once. This type of security provides a total of 389112 different combinations. Face recognition

is a nice feature for protection, but it does not offer a higher level of security. In case someone’s

appearance is similar to that of the user (for example a twin) they could unlock the device without

problem.

Sandboxing

When an application is installed, each package is given a unique Linux user ID. Depending on the

duration of the package, the ID remains constant. Same applications might have a different ID on

different devices, but will have the same UID. This property points out that two different applica-

tion codes can not run in the same process, since they are supposed to be running as different Linux

users. Developers could use the sharedUserId in the manifest file to define two different packages

with the same ID. By placing these two packages in one application, so they would be signed with

the same signature, makes data sharing between the packages unavailable to other applications.

These two safety measures establish the term "Sandbox".[13]

Intrusion Detection

An Intrusion Detection System (IDS) is used to monitor malicious activity during the usage of

device or network traffic. Traditionally, such systems collect and analyze information so as to

find enough evidence of whether the system has been attacked or not. Because these kinds of

systems try to identify the behavioral patterns of code, a malicious application may evolve in a

different way so that it would avoid detection, making IDS’s effectiveness diminish over time.

The downside of installing an IDS application on a device would be the battery life problem, since

these programs would have to keep running all the time to be able to provide real time protection

against such attacks. There are currenty 2 well-known Intrusion Detection Systems for Google’s

Android, which are known as Andromaly and SecuritySuite.[14]

Firewall

Firewalls are used to control incoming and outgoing network traffic by analyzing data packets that

are transmitted over network interfaces. This kind of protection can be summarized in two sec-

tions. Firstly, it would’t allow any malicious data packages into the system. Secondly, even if there

is already malware on the phone, it would block any outgoing data packages which are associated

with that malware. Since a firewall system only protects incoming packages over network inter-

faces, it can’t prevent malware from entering the phone through SMS or MMS.[14] The downside

of this protection plan is that firewall applications might require root access, which might bring

about more unwanted damage.

9

----------------------- Page 10-----------------------

Remote Management

Remote management helps combine other security mechanisms on Android while giving users the

ability to control the system remotely. With this type of control, different kinds of settings could

be altered, such as Wi-Fi and network. Remote management is mostly used to obtain the device’s

location by silently enabling the GPS and lock it to prevent users’ data from being stolen.[15]

Remote management could also be used to control the security mechanisms when dealing with

inexperienced or ignorant employees.

AntiVirus Software

Antivirus software tries to identify and remove possible malware from specific locations that are

commonly used by the user, such as the default download folder, SD-Card folders, files that have

been received through Bluetooth, etc. Identification is based on the signature repository of the

application it uses. Therefore each antivirus program might have a different detection rate. There

are currently over 40 antivirus applications available.

Different antivirus applications scan different parts of the device. Some of them scan the entire

device storage while other applications only scan through important files and applications.[16]

2.3 Rooting

Rooting is the process of allowing a device user to obtain privileged control over the system. This

procedure is done to overcome some of the limitations set by network carriers or by the hardware

itself. It allows some applications that require low level permissions to perform various operations

which would not have been possible otherwise. It is done by installing the SuperUser application

on the phone. Once the device has been rooted there is a potential risk of the manufacturer warranty

becoming void.

Rooting could used for different reasons and features:

Performance Improvement:

Rooting can be used to improve the overall performance of the system, such as changing

the CPU’s minimum and maximum speed, setting the scaling governor of the CPU, memory

and battery improvements. Changing these settings requires low-level system permissions,

so rooting is required due to this fact.

Interface Customization:

Rooting can be used to download and install different kinds of themes. Each theme might

have different sets of icons used for different purposes.

Additional Features:

Tethering is a feature that can be installed and used after the rooting procedure. In older

versions of Android no tethering functions were provided as a default by the system.

System Backup:

Rooting can be used to backup applications that have already been installed on the system.

Since the applications are in a system folder, rooting is required to be able to see these

applications and back them up.

Bloatware:

Some users root their devices to be able to remove unwanted third-party-applications (which

are called bloatware) that are preinstalled with the system.

10

----------------------- Page 11-----------------------

Even though rooting may seem very useful it poses a very high security risk that may be harm-

ful both to the user and the developer. Bricking the device is one of the problems that users might

come across. Once the device has been bricked it becomes unusable. From the developers’ view-

point it might be the more devastating scenario; once the device has been rooted, the user is able

to peek into the system folders with various file explorers where the applications reside. If the user

has already paid for an application, he/she can redistribute this file. There have been some coun-

termeasures against this threat; called "Google Play Licencing" ; which Google has implemented

fairly recently.

Some of the applications downloaded from the markets require root-access to be able to func-

tion. Most of the performance utilization programs require root access, since they need to access

the low-level settings of the system itself.

2.4 Known Attacks

In August 2010, researchers from Kaspersky Lab found the first ever Trojan-SMS; which

was named Trojan-SMS.AndroidOS.FakePlayer.a; it had disguised itself as a movie player

application and was able to send SMS to premium-rate numbers.[17]

In 2010 November, two researchers, Jon Oberheide and Zach Lanier, found a bug which

allowed an application to download others without permission from the user; these appli-

cations are capable of locating the users, stealing their contact lists or sending pay-per-text

messages. It has been done it by creating a "fake" Angry Birds game which was disguised

as an expansion pack to the original game. Users only recieved a status bar notification

reporting that the application was being installed.[18]

During the same month another bug in the Android stock internet browser had been found

to have let malicious applications get installed with the INSTALL_PACKAGES permission,

used to update the Flash plug-in for the browser.[19] This security leak was later fixed

with Android 2.2, but at that time, only 36% of the users had the most recent version of

the Android system, which meant that the remainder of the users were still exposed to the

attack.[20]

A research team from Norh Carolina State University has found a bunch of vulnerabilities

by evaluating the security of different smartphone models produced by popular companies

such as Samsung, Motorola and HTC. The research showed that these devices do not pro-

tect privilaged permissions from suspicious applications. They have developed a tool, called

"Woodpecker", which analyzes previously installed applications on the device. Out of 13

priviledged permissions, they found that 11 were explicitly leaked by pre-installed applica-

tions. They also found that by using these leaks, they could send SMS, record conversations,

locate the device and wipe out user data.[21]

11

----------------------- Page 12-----------------------

3 Android Permissions

3.1 Enforcement of Permissons

Permissions are barriers that limit access in order to protect the user’s private information. Its

misuse can cause huge problems. Without the user’s authorization the applications cannot access

certain essential features. The next paragraph elaborates how IPC (inter-process communication

model) works, followed by a description of Android Mobile OS permissions.

IPC

Inter-Process Communication is a group of methods needed to facilitate data transfer as well as

messaging between multiple threads during a process or a group of processes. It is also possible for

those processes to be connected by a network. Those methods can be classified as synchronization,

shared memory, RPC (remote procedure calls) and message passing.[22]

Beside the traditional IPC mechanisms such as shared memory, Android presents two specific

IPC mechanisms.

Intent

Its objective is to perform an action, basically informing of what the user wants to do or has

done. Depending on the intent, applications or the Operating System might be monitoring

such actions and will react accordingly. (To monitor for an intent the implementation of a

broadcast receiver is neccessary.)[23]

The code shown below demonstrates how to execute an intent:

Intent intent ;

intent = new intent(Intent.ACTION_VIEW,

Uri.parse( "http ://www .cookchefz .com"));

Permissions are often used to delegate who shall receive an intent sent by other applications

or to restrict the sending of intents to other activities or applications.

Binder

In Android’s OS, applications and services do not tend to the same process which means

one process cannot access another’s memory. On the other hand, they need to communicate

and data share with each other. To accomplish this Android OS needs a kind of structure

to manage inter-process communication calls (IPC Call) in order to support data sharing

and communication between two or more processes. Binders implement RPCs. If a remote

interface is defined in an AIDL (Android Interface Definition Language) file, it could be

called like any other local methods. With the help of Message Handler class, system services

are able to accept asychonous Binder communication, which wraps the Binder interface.[24,

25]

----------------------- Page 13-----------------------

Figure 3.1: Binder [B]

Let’s assume an application that displays or alters text files was developed. The user does

not want to restart/reopen the application, whenever he/she wants to work with text files. This is a

scenario in which public intent that names the application should be broadcasted. Other developers

don’t have to include this code, they can simply look for this application; after a successful search

they can call the intent and send a request to display or alter the text file. However, if an application

was written that turns the Wi-Fi on or off instead of playing with text files, other applications could

access Wi-Fi control without requiring another permission. [26, 27]

This is one possibly dangerous scenario which users aren’t aware of. Other dangers depend on

the permissions which are granted by applications although they do not really need them.

But how could the a user know whether an application really requires those permissions? That’s

why users should have better knowledge about Android’s permissions.

Permission Structure

Manifest file

Every Android application contains a file named AndroidManifest.xml in its root directory .

It is the application’s descriptor file known to developers as web.xml. AndroidManifest.xml is

automatically generated after creating a new Android project in Eclipse. It contains essential

information such as the name of the activities, required permissions, the name of the features and

libraries ... etc.

If a developer want to use any kind of permission in the application, he/she must put it in this

file or he/she will get an exception message upon wanting to compile and run the project.

13

----------------------- Page 14-----------------------

Listing 3.1: A simple Manifest file

<?xml version="1.0" encoding="utf8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.example.myapplication"

android:versionCode="1"

android:versionName="1.0" >

<usessdk

android:minSdkVersion="8"

android:targetSdkVersion="16" />

<usespermission android:name="android.permission.ACCESS_COARSE_LOCATION"/>

<application

android:allowBackup="true"

android:icon="@drawable/ic_launcher"

android:label="@string/app_name"

android:theme="@style/AppTheme" >

<activity

android:name="com.example.myapplication.MainActivity"

android:label="@string/app_name" >

<intentfilter>

<action android:name="android.intent.action.MAIN"/>

<category android:name="android.intent.category.LAUNCHER"/>

</intentfilter>

</activity>

</application>

</manifest>

If looked at it carefully, the AndroidManifest.xml file tells us that the application needs the AC-

CESS_COARSE_LOCATION permission . Users cannot see this file when they want to download

an Android application. But before the download starts user’s phone will show him/her a message

detailing which permissions are needed to run that application.

If a user taps on any of these permissions a pop-up dialog will appear, explaining what an

application can do by using this permission type. (Figure 3.3)

The main problem with downloading applications is that either the user is not willing to read

them or he/she does not understand what all the requirements are.[28]

Going back to the permissions structure it becomes evident that there are some elements about

permissions which the manifest file could contain.

<permission>

This tag is used to enforce custom permissions. The reason for creating custom permissions is

to protect publicly available activities and custom data providers.

Listing 3.2: Syntax of a <permission> tag[29]

<permission android:description="string resource" android:icon="drawable resource"

android:label="string resource" android:name="string"

android:permissionGroup="string"

android:protectionLevel=["normal" | "dangerous"

| "signature" | "signatureOrSystem"] />

android:description: One of the most important attributes of a custom permission will be

seen by the user before he/she downloads the application. It is, as its name implies, a brief

14

----------------------- Page 15-----------------------

Figure 3.2: List of permissions before Figure 3.3: Description of the permis-

the installation process [C] sion that the app uses [C]

piece of information, describing what this custom permission is going to do if the user

accepts it. It must be more informative than the label attribute.

android:label: The name for the permission, which will be shown to user.

android:name: It is the name of the permission, which is the same as in <uses-permission>

tag. Describes to the application which feature is allowed access.

For example android:name="com.mydomain.myprovider.permission.ACCESS_DATA"

The attribute "name" above tells the application that it will be allowed to access data if the

user accepts and authorizes the process.

android:protectionLevel: This attribute points out the method (the potential risk), which the

system should follow after granting (or not) that permission.

Protection Level

normal: The default value shows that the permission has a lower risk and gives requesting

applications access to isolated features. The Android’s system automatically accepts this

type of permission without requesting the authorization from the user. (Users can view

these permissions before they download the application)

15