security of the android operating system - · pdf filesecurity of the android operating...

Security of the Android

Operating System

Yury Zhauniarovichyury.zhauniarovich@unitn.it

http://zhauniarovich.com

University of Trento

About://

M.Sc. in Computer Security from the Belarusian

State University

Ph.D. in Information and Communication Technology

from the University of Trento

The author of the free book “Android Security

(and Not) Internals” [1]

A reviewer of the book “Android Systems

Development How-to” [2]

A developer of several research prototypes based on

Android OS (YAASE [3], CRePE [4], MOSES [5])

Currently, a Postdoctoral Researcher at the University of Trento

Outline

General Bits and Pieces

Android Architecture

Android Security Internals

Security Problems and Solutions

What is the codename of the

following Android version?

Mobile Operating Systems

Why Android?

Open source system

On about 85% of all new mobile devices (according to the last IDC report [6])

A highly customized system (FacebookHome, Kindle Fire, different devices from China, CyanogenMod)

Running on different platforms (TV, Wearable, Auto)

Third-party applications can be easily developed

We can test third-party applications without publishing them in Google Play

1 million+ applications in Google Play

History of Android (2002-2007)

• 2002:

– Andy Rubin, CEO of Danger Inc., showed the first phone Sidekick

at Stanford

– Larry Page and Sergey Brin attended this event and became users

of this phone

• 2003:

– Rubin has left the company because the things did not go well

– In October, Andy Rubin, Rich Miner, Nick Sears, and Chris White

founded Android Inc. in Palo Alto

• 2005:

– In August, Android Inc. is acquired by Google

• 2007:

– November 5, Open Handset Alliance was announced

– The first product – Android

• 2008:

– In October, the first phone (HTC Dream) running Android 1.0 was

presented

• 2009:

– In April, Android 1.5 Cupcake was presented

– In September, Android 1.6 Donut appeared

– In October, Android 2.0 Eclair was announced together with a

new phone Motorola Droid (Milestone)

• 2010:– Google launched Nexus series with HTC Nexus One

– Google announced Android 2.3 Gingerbread, which was the most popular version till 2013, together with Samsung Nexus S

– Android popularity first surpassed Apple iPhone’s

• 2011:– Android 3.0 Honeycomb for tabs released with Motorola Xoom

– Android 4.0 Ice Cream Sandwich appeared combining two development branches

• 2012:– Android 4.1 Jelly Bean, 4.2 Jelly Bean

• 2013:– Android 4.3 Jelly Bean, 4.4 Kitkat

Android Versions

Astro Boy and Bender were code names for pre-1.0 milestones

11http://www.xda-developers.com/android/the-evolution-of-android-part-i/http://www.androidpolice.com/2012/09/17/a-history-of-pre-cupcake-android-codenames/

Android Version Share

Data collected during a 7-day period

ending on August 12, 2014.

https://developer.android.com/about/dashboards/index.html

What is the codename of

Android version 1.1?

Android Stack

Linux Kernel

Linux Kernel is used:

Memory management

Process management

Security module

Networking

Android Enhancements:

Ashmem

Power management

Binder IPC

Logger

Native Userspace

Components

Hardware Abstraction Layer

Init / Toolbox

Native Daemons (rild, adbd, vold, etc)

Native Libraries

Libraries:

2D and 3D graphics

Media codecs

Font rendering

The core of web browser

Bionic libc

Android Runtime

Dalvik VM:

Virtual machine for Android to run applications

Provides application portability

Supports multiple instances

CPU and memory optimized to run on mobile devices

Core Libraries:

Data structures

Utilities

File access

Network access

Graphics

Application Framework

System Services:

Essential services to the Android platform:– ActivityManager Service

– PackageManager Service

– PowerManager Service

– etc.

Hardware access services:– Telephony Service

– Location Service

– Bluetooth Service

– etc.

Framework Libraries:

Provide API to services:– Activity Manager

– Package Manager

– Power Manager

– Location Manager

– Sensor Manager

– Telephony Manager

– etc.

Applications

System apps:

Supplied with the platform– Email application

– SMS application

– Contacts

– Phone

– Browser

– etc.

Third-party apps:

Apps produced by third-party developers– Evernote

– Facebook

– Dropbox

– Feedly

– Chrome

– etc.20

Android Stack

General Overview

Linux Kernel:

– Application Sandboxing

Android Middleware:

– IPC Reference Monitor

Linux Kernel Level

Native Userspace Level

Application Framework Level

Application Level

Linux DAC

Subject

user: user_xgroup: group_g

Object

Owner:owner: user_y

group: group_g

ACL:owner: rwx (7)

group: rw- (6)

others: r-- (4)

Action:write

•Process

•File•Socket

Application Sandboxing

Each app during installation:

– receives a distinct UID

– receives a distinct primary GID

– may receive membership in additional groups

UID and primary GID do not change during app’s life on a device

Each app process runs under its own UID

All app resources are owned by its UID

AID (Android ID) == UID26

System Defined AIDs

UID range 1000-9999 is reserved

The values used to control access to:

– some system components (radio, camera, etc.)

• through running system processes with specified identities

• through assigning system components (unix-sockets, files, drivers) certain owners and permissions

– networking capabilities (paranoid networking patches)

The values used in Android are hardcoded in android_filesystem_config.h

System Defined AIDs

system/core/include/private/android_filesystem_config.h

System Component Protection

Camera

/dev/cam

Owner:owner: root (0)

group: camera (1006)

ACL:owner: rw- (6)

group: rw- (6)

others: --- (0)

Paranoid Networking Patches

Vanilla Linux: by default all processes have access to networking capabilities

Mobile: access to network is considered as dangerous functionality

– may drain your battery

– may send private data

Android: Applications run in sandboxes => Limitations on network functionality must be implemented at the Application Sandbox level => Linux Kernel should be modified

kernel/include/linux/android_aid.h

kernel/net/ipv4/af_inet.c

Can you describe other ways

of application sandboxing?

Linux Kernel Level

Application Level

Android Boot Process

Android Filesystem

Does not comply with Filesystem Hierarchy Standard

Has standard Linux files as /dev, /proc, /sys, /etc, /mnt, etc.

Has Android-specific directories as /system, /data and /cache

Android Filesystem

Security

Security at the Native Userspace Level is provisioned through:

– Setting certain filesystem permissions to files and sockets

– Running certain processes under specified credentials

– Controlling who can send commands through opened sockets and who can run current executables

Filesystem Permissions

Files, drivers, unix-sockets ownership and permissions are set:

– during the building of the system ROM {1}

– /init process {2}

– /init.rc file(s) {3}

– /ueventd.rc file(s) {4}

System ROM {1}

System ROM

– system.img

– userdata.img

– cache.img

system.img, userdata.img, cache.img obtained during the building of the Android operating system

– At the compilation time must be defined:

• User and group names

• Filesystem ownership and permissions

Android System Usernames {1}

Filesystem Definitions {1}

Android-Specific Folders {1}

Mounting points for images:

– /system system.img

– /data userdata.img

– /cache cache.img

Core of Android:

– /system – contains Android OS except Linux Kernel (located on /boot)

– /data – stores user data or information that changes over the time

– /cache – is used to store frequently accessed data and OTA updates

/init {2}

Run ueventd

daemon

Create filesystem nodes, mount

filesystems, and assign

permissions

Parse and execute init.rc

Configuration init.rc File(s) {3}

Configuration files are parsed and executed by /init program

Written in Android Init Language

Contain Action Lists executed when certain triggers are occurred

Set: system variables, parameters, filesystemowners and permissions, etc.

Run: main system daemons

init.rc >600 configuration lines

system/core/rootdir/init.rc

Excerpt of init.rc {3}

system/core/rootdir/init.rc

Daemon ueventd {4}

Responsible for system and device events

At the beginning replays the kernel ueventhotplug events specified in uevent.rc files

Running Processes with Credentials

service media /system/bin/mediaserver

class main

user media

group audio camera inet net_btnet_bt_admin net_bw_acct drmrpc

ioprio rt 4

Sockets

Processes

Linux Kernel Level

Application Level

System Services

Provide core functionality of the Android platform

Implemented mostly in Java, some using native code

Most of them run as separate threads within system_server process

Define the interfaces (e.g, IPowerManager for PowerManagerService) used from other services and applications

Inter Process Communication

Android IPC

Posix System V IPC (semaphores, shared memory and message queues) are not supported by Android’s libcimplementation (Bionic)

Uses Unix domain sockets for some special cases (e.g., communication with Zygote daemon)

Binder Framework

– relies on special /dev/binder driver

– provides the ether for ICC mechanisms (e.g., Intents)

– link-to-death

– sync/async remote method invocation

– provides ability to send file descriptors across processes

– communication between the processes is organized according to synchronous client-server model

Binder Communication Model

Aleksandar Gargenta. Deep Dive into Android IPC/Binder Framework. 55

System Service Discovery

How a Client can discover a Service?

Each Service is a Binder object, which is assigned with 32-bit value random, unique over the system token

The token acts as a handle for the Service (having this handle it is possible to interact with the Service)

How can a Client discover the value of this token?

Binder Context Manager

Special Binder Service with a known in advance token value = 0

Context Manager may be imagined as a name service:

– CM provides a handle to a Service using the name of the Service

– Each Service before being exposed needs to be registered with CM

Binder Context Manager == Service Manager in Android

Binder Security

The Binder driver allows only single Context Manager registration

Does not impose any security by itself, but:

– Binder tokens can act as a security access token (e.g., wakelock example)

– Binder driver to each transaction adds UID and PID of the sender process

Receiver may get UID and PID values:

– android.os.Binder.getCallingUid()

– android.os.Binder.getCallingPid()

Application Framework Security

Application1 wants vibration functionality

Vibration can drain phone’s battery

– Only approved applications should have this functionality

– How to protect vibrate() method from being called from any app?

android.os.Binder.getCallingUid() in set of allowed uids

checkCallingOrSelfPermission(permission)

Permission Check Example

The check is performed in system_serverprocess => client process cannot influenceon the check (e.g., through Java reflection)

Permissions

Special labels that guard access to protected functionality

– Built-in permissions (framework)

– Custom permissions (system and user apps)

Permissions are granted upon installation

Permissions are not equal in security sense!

– criticality(install packages) > criticality (send SMS) > > criticality(vibrate)

PackageManagerService (system service) is responsible for managing permissions assigned to different applications and system components

Permission Granting

Developer:

During the development

declares in the

AndroidManifest.xml, which

permissions are required for

his application to operate

properly

Example: android.permission.SEND_SMS

Owner of the phone:

During installation is

acquainted with these

required permissions and

decides either to grant these

permissions to the

application or not to grant

and, thus, prohibit the

installation of the application

Permission Protection Level

• Normal – automatically granted

– access to (sometimes annoying but) harmless features, like changing the wallpaper

• Dangerous– user granted

– access to SMS sending facility, to phone number, contacts, camera, etc.

• Signature (I case)– developer controlled

– used to enable interactions among the developer apps

• Signature (II case)– Device manufacturer controlled

• System|Signature– Google/device manufacturer controlled

Built-in Permissions

Code Signing

All Android applications and framework resources need to be signed

There are 4 keys defined in AOSP:

– platform

– shared

– media

– releasekey (testkey)

AndroidManifest.xml with built-in permissions is within framework-res.apk signed with platform key

Package Manager Check

Kernel Permission Mapping

frameworks/base/data/etc/platform.xml

Linux Kernel Level

Application Level

Android Applications

Types:

– System applications

– Third-party applications

Consist of components, which are declared in AndroidManifest.xml

No central start point (no main() method)

Permissions are enforced on the Android Framework level

Application Components

Broadcast receiver:

• Message box to receive messages from other

components and to react to them

Content provider:

• Data sharing interface

Activity:

• User Interface element

Service:

• Background

processing

Application Interaction

Description

writting

picking

sendingBook list

Personal Library

Service

Content Provider

Service

Content Provider

Gallery

Service

Content Provider

PersonalLibrary.apk Email.apk Gallery.apk

Intents

Intents are messages between components of the system

Three out of four app component are activated using Intents

Developer can explicitly specify the receiver of the message (explicit intent) or can ask the system to choose appropriate component for processing specified action (implicit intent)

iOs8 will introduce similar functionality (Extensibility)

Intent Resolution

Explicit Intents

Explicit intents are used for application-internal messages

Required:

Component name

Optional:

Action

Category

Optional

Extras

Android Manifest

Describes

contents of the

package:

•Components

•Required permissions

•The classes that

implement each of the

components

•Some other features

of app and

components

(sharedUid,

processes, etc.)

Custom Permissions

Application Build Process

Device

Compilation

Packaging

SigningDevelopercertificate

Android Project

assets

AndroidManifest.xml

resources

source code

Android Package (.apk)

assets

AndroidManifest.xml

uncompiled resources

resources.

Literature Overview

1. N. Elenkov. “Android Security Internals”. No Starch Press,

expected October 2014

2. K. Yaghmour. “Embedded Android”. O’Reilly Media (2013)

3. J. Drake et al. “Android Hacker's Handbook”. Wiley (2014)

4. J. Levi. “Android Internals: A Confectioner's Cookbook”.

expected August 2014, http://newandroidbook.com/

5. Y. Zhauniarovich. “Android Security (and Not) Internals”. Web

(2014), http://zhauniarovich.com/files/asani/asani.pdf

6. E. Fernandes. “Instant Android Systems Development How-

to”. Packt Publishing Ltd (2013)

What the most critical security

problems do you see in Android?

Critical Problems: My View

Permission system

– Overprivileged applications

– Users do not understand permissions

– “All-or-nothing approach” with permission granting

Private information collection

Malware

– Repackaging

– Application vetting

Permission System

Private Information

Android Malware

Our Solutions

Overprivileged Applications

Is the principle of least privilege respected? Not always.

– Applications reimplement the functionality already available (Facebookwill open links in its internal browser)

– Developers request permissions not required for the app operation

A. Felt et al “Android Permissions Demystified” at CCS’2011

– Stowaway is a tool to check which permissions the actually app requires

– From 940 analyzed apps 32.7% are overprivileged

Most common unnecessary permissions are:

– ACCESS_NETWORK_STATE 16%

– READ_PHONE_STATE 13%

– ACCESS_WIFI_STATE 8%

– WRITE_EXTERNAL_STORAGE 7%

A more recent mapping of permissions to API in the paper “PScout: Analyzing the Android Permission Specification” by Kathy Au et al.

Stowaway Example

Do Users Understand Permissions?

WAKE_LOCK

USE_CREDENTIALS

MANAGE_ACCOUNTS

AUTHENTICATE_ACCOUNTS

WRITE_SETTINGS

com.android.vending.BILLING

Do Users Understand Permissions?

A. Felt et al “Android permissions: User attention, comprehension and behavior” in SOUPS-2012

– Surveyed 300 Android users and interviewed 25 of them

– Key findings:

• 17% of participants paid attention to permissions during installation

• 42% of interviewed participants were unaware of existence of permissions

• Very low rate of permission comprehension: only 3% were able to correctly answer to the questions on permission understanding

Solutions

Reconsider “all or nothing” approach

– Add “prompt” permissions

– Provide users with better permission explanation

Provide a possibility to disable permissions at runtime and depending on context

– CRePE*

– CyanogenMod

* M. Conti et al. “CRePE: A System for Enforcing Fine-Grained Context-Related

Policies on Android”. In IEEE TIFS, 2012

Permission System

Private Information

Android Malware

Our Solutions

Example: Private Information

IMEI (International Mobile Station Equipment Identity) – is a unique number to identify a phone

In Android to get it use: TelephonyManager.getDeviceId()

Requires permission: android.permission.READ_PHONE_STATE

Motivation

Sensitive user information may be gathered by:

Advertising frameworks and other libraries embedded into apps

Third-party app developers– Brightest Flashlight app (50+ million installations, traced

user location in almost real-time)

– 20 out of 30 popular apps potentially misuse private users’ information*

Adversaries**– using repackaging of popular apps

– developing apps that conceal their malicious behavior

* W. Enck et al. “TaintDroid: An Information-Flow Tracking System for Realtime

Privacy Monitoring on Smartphones”. In Proc. Of OSDI‟10

** Y. Zhou, X. Jiang. “Dissecting Android malware: Characterization and Evolution”.

In Proc. of S&P ‟12

TaintDroid

W. Enck et al 'TaintDroid: an information flow tracking system for realtime privacy monitoring on smartphones', in OSDI-2010

– TaintDroid is a system for dynamic taint tracking in Android.

– When tainted data is sent over the network, TaintDroid logs this fact

Studied 30 popular apps, some of them indeed misuse sensitive data

– 2 apps send SIM card ID

– 15 apps send location data to ad servers

– None of the apps tells this in the EULA

Solutions

Fake information

– MockDroid*

– App Ops (Android 4.3, 4.4, removed in 4.4.2)

Provide a possibility to separate personal and work data; filter our private information

– MOSES**

Trusted Application Stores

– TruStore***

* A. Beresford et al. “MockDroid: Trading Privacy for Application Functionality on

Smartphones”. In Proc. of Hotmobile’11, 2011

** Y. Zhauniarovich et al. “MOSES: Supporting and Enforcing Security Profiles on

Smartphones”. In IEEE TDSC, 2014

*** Y. Zhauniarovich et al. “DEMO: Enabling Trusted Stores for Android”. In Proc. of

CCS‟13, 2013.

Permission System

Private Information

Android Malware

Our Solutions

Malware Analysis

Y. Zhou, X. Jiang “Dissecting Android Malware: Characterization and Evolution” in IEEE S&P-2012

– Analyzed 1260 malware samples categorized in 49 families

Malware was analyzed by:

– Installation type

– Activation method

– Type of payload

– Use of permissions

Installation Types

Repackaging – piggyback malicious payloads into popular applications

Update attack – malware includes an update component that will fetch or download the malicious payloads at runtime

Drive-by download – malware tries to force users to download “interesting” or “feature-rich” apps.

Others – spyware, fake apps, trojans, apps with root exploit

Android Malware

Repackaging

Dynamic Update Attack

Repackaging

assets

AndroidManifest.xml

resources.

Developersignature

Signing

Developer

certificate (same)

Adversary

certificate(different)

Rebranding(good)

Plagiarizing(bad)

Device

Repackaging

App repackaging is very easy on Android:

– Fetch an app Disassemble Change Assemble Sign with own certificate Publish

The code of the application can be easily changed

– smali/backsmali, AndroGuard, dex2jar, etc.

Plagiarizing is used to:

– steal advertising revenues (14% of ad revenues)*

– collect user database (10% of user base)*

– malware distribution (86% of Android malware samples use this distribution channel)**

* C.Gibler et al. “Adrob: examining the landscape and impact of Android application

plagiarism”. In Proc. of MobiSys ‟13

Solutions

Repackaging:

– Search and delete repackaged applications

• FSquaDRA by Y. Zhauniarovich (DBSec 2014)

– Resource-based comparison

• DNADroid by J. Crussell et al. (ESORICS 2012)

– PDG subgraph isomorphism

• Juxtapp by S. Hanna et al. (DIMVA 2012)

– k-grams of opcodes hashing feature vector Jaccard distance

• AndroGuard

– Similarity score based on NCD = extract opcode sequences for methods compress compare methods based on NCD

– One central store with plagiarism detection service

Android Malware

Repackaging

Dynamic Update Attack

Dalvik VM

Dynamic Updates

assets

AndroidManifest.xml

resources.

DexFile.loadDex

Method.invokecode files

(jar, dex,…)

1. Dynamic Class Loading (DCL)

2. Reflection

Motivation

In Android, code loaded dynamically has the same privileges as original

Static analyzers cannot fully inspect an app in the presence of dynamic code features (AndroGuard, Stowaway, PScout etc.)

Heavily used by malware to conceal malicious behavior

Dynamic code update features are used:– In legitimate applications

• Google Play: 19% - DCL, 88% - reflection

• Third-party markets: 6% - DCL, 74% - reflection

– In malicious applications

• Malware dataset: 20% - DCL, 81% - reflection

Solutions

White-listing of the code loaded dynamically

– Time lag

– Huge whitelists

– Requires analysis of the loaded code

Application vetting

* S. Poeplau et al. “Execute This! Analyzing Unsafe and Malicious Dynamic Code

Loading in Android Applications”. In Proc. of NDSS’14, 2014

Application Vetting

Application vetting is the process of performing background check of apps before proposing them to end-users

Application vetting can be used to:

– ensure only approved apps are loaded on employee’s device (in the enterprise context)

– find repackaged applications

– reveal malicious applications

Google Bouncer since Feb. 2012

An app submitted to Google Play is run in a simulated environment

– Checking for known malware behavior patterns

It is a static environment

– J. Oberheide and C. Miller in June 2012 present the data of the simulated environment which can be used by malware to detect when they are scanned

• Same Gmail account, same contact list, same pictures on the phone, same processor emulator, same IP block

• They got this data by obtaining a remote access to their app which was being analyzed by the Bouncer

It is vulnerable to dynamic JavaScript code updates

– In July 2012 N. Percoco and S. Schulte uploaded an SMS app which also harvested user information and was capable of launching a DDoS attack

– It was not detected by the Bouncer, because the malicious code was uploaded after the app was verified

• Developers can remotely add new features to apps already accepted on Google Play and modify how the file looks, all without going through the approval or update process again.

8/27/2014

Permission System

Private Information

Android Malware

Our Solutions

FSquaDRA

TruStore

MOSES: Motivation

Same device multiple virtual environment (e.g., in BYOD scenarios)

Demand to increase the control over the capabilities of third-party apps, e.g., prohibit access to location

Lack for context-based enforcement of security policies on Android

Absence of remote control over virtual environments by the owners

MOSES: State Of the Art

Secure containers

– e.g., Aurasium by R.Xu et al. (USENIX Security ’12)

– usually, 2 virtual environment (private and work)

– app rewriting usage

Mobile paravirtualization

– e.g., L4Android by M.Lange et al. (ACM SPSM ’11)

– predefined number of operation modes

– battery-consuming solutions

Linux containers

– e.g., Cells by J.Andrus et al. (ACM SOSP ’11)

– switching requires user interaction

– virtual environments are hard-coded

MOSES: Problem

Issue: How to provide several virtual environments

on the same device

– users are not willing to carry several devices

that separate data and apps belonging to different usage contexts

– app developers should not rewrite their apps according to new rules

managed by different owners

– e.g., working environment is controlled by company administrators

avoiding energy demanding (para)virualizationsolutions?

– smartphones require long working time without recharging

MOSES: Idea

IDEA: Provide a possibility to create virtual

environments (or Security Profiles (SP))

through policy-based framework so that

applications in one SP cannot access the

data of the same app in another SP. Ensure

the control over Security Profiles to the

owners. Equip SPs with an ability to enforce

fine-grained policies.

MOSES: Architecture

MOSES Configuration:

Security Profile Creation

create_profile “private” in_mode “permissive” with_priority “50”;

allow_apps “*”;

add_sr “browser_deny_receive_from_google” on_position “10”; activate_in_context “home”;

Context Definition

create_context “home”;condition [(latitude=“55”) AND (longitude=“11”) AND (radius=“1000m”)];

Special Rule Creation

create_sr “browser_deny_receive_from_google”;

action “deny”;

package “com.google.android.browser”;

operation “receive internet data”;

target “google*”;perform [];

MOSES: Contributions

First policy-based solution for virtual environments on Android

Manual and context-based Security Profiles activation

Security Profiles and Contexts are not predefined, users can configure them dynamically

Possibility to confine applications using fine-grained security policies

Compatible with existing applications

Y. Zhauniarovich, G. Russello, M. Conti, B. Crispo, E. Fernandes.

“MOSES: Supporting and Enforcing Security Profiles on Smartphones”.

In IEEE TDSC, to appear in 2014.

G. Russello, M. Conti, B. Crispo, E. Fernandes , Y. Zhauniarovich.

“Demonstrating the Effectiveness of MOSES for Separation of Execution

Modes”. In Proc. of CCS‟12, 2012.

Our Solutions

FSquaDRA

TruStore

Motivation

App repackaging is very easy on Android:– Fetch an app Disassemble Change Assemble

Sign with own certificate Publish

The code of the application can be easily changed– smali/backsmali, AndroGuard, dex2jar, apktool, etc.

Plagiarizing is used to:– steal advertising revenues (14% of ad revenues)*

– collect user database (10% of user base)*

– malware distribution (86% of Android malware samples use this distribution channel)**

* C.Gibler et al. “Adrob: examining the landscape and impact of Android application

plagiarism”. In Proc. of MobiSys ‟13

Problem Statement

Issue: How to detect repackaged Android applications

– 1.1+ million apps on Google Play *

– 190+ third-party markets **

– quadratic complexity

in effective way?

– need for a similarity metric to what extent one app is similar to another

* N. Viennot et al. “A Measurement Study of Google Play”. In Proc. of SIGMETRICS „14

** T. Vidas, N. Christin. “Sweetening Android Lemon Markets: Measuring and

Combating Malware in Application Marketplaces”. In Proc. of CODASPY „13

FSquaDRA: Idea

Repackaged apps want to maintain the “look and feel” of the originals

– Opera Mini fake: 230 of 234 files are the same

IDEA: compare apps based on the included resource files (same files same apps)

FSquaDRA: Approach

Compute hashes of all files inside two apps

Calculate Jaccard index for the extracted hashes:

Compare the obtained value with a threshold

PROBLEM: How to compute hashes efficiently?

Hi – set of hashes of files in apk i

Speeding Up Hash Calculations

As a part of application signing process SHA1 digest of each file inside apk is calculated

FSquaDRA: Evaluation

Dataset:

– 55779 apk samples

– from 8 markets including Google Play

Pairwise comparison of all apps in the dataset

Objectives:

– plagiarizing rates for apps signed with different certificate

– rebranding rates for apps signed with the same certificate

Evaluate Efficiency and Effectiveness

Evaluation: Pairwise Comparison

Evaluation: Efficiency

FSquaDRA is implemented as a single-threaded Java program

– not really optimized

We ran experiments on a commodity laptop (2.9 GHz Intel Core i7, 8GB RAM)

– 15,10 hours to load hashes into memory

– 64,41 hours to compute similarity score for all app pairs

On average 6700 app pairs per second

Evaluation: Effectiveness

Metrics:

– False Positives? For apps FSquaDRA considers repackaged, are they actually repackaged?

– False Negatives? For apps FSquaDRA considers different, are they really not repackaged?

Approaches:

– analyze FSquaDRA on a dataset of repackaged apps

– compare FSquaDRA metrics with the state-of-the-art tools

Problems:

– no public dataset with repackaged apps

– only one public tool: AndroGuard

Effectiveness: Evaluation Setup

AndroGuard – open-source tool by A. Desnos:– computes code-based similarity metric

– slow (65 sec to compare an app pair on average)

– does not produce symmetric values

We use average score of (A,B) and (B,A) as the similarity score for AndroGuard (ags)

For each selected bin: – randomly picked 100 app pairs with different

certificates and 100 app pairs with the same certificate;

– calculated their AndroGuard similarity score (ags)

– compared with FSquaDRA similarity score (fss)

Effectiveness: Plagiarizing Results

(different certificates, fss>0)

Correlation: 0.7919

Difference (fss-ags):

-mean: -0.0412

-st. dev.: 0.1862

-median: -0.0480

Red: line of best fit

Blue: LOWESS

(locally weighted

scatterplotsmoothing line)

Effectiveness: Rebranding Results

(same certificates, fss>0)

Correlation: 0.5807

Difference (fss-ags):

-mean: -0.2761

-st. dev.: 0.2704

-median: -0.2518

Red: line of best fit

Blue: LOWESS

(locally weighted

scatterplotsmoothing line)

FSquaDRA: Features

The first solution detecting repackaged apps based on resource files

Our resource-based similarity score is highly correlated with the code-based similarity score of AndroGuard (0.79 for plagiarizing, 0.58 for rebranding)

Faster than any known competitor

– DNADroid by J. Crussell et al. (ESORICS 2012) - 0.012 app pair/sec

• PDG subgraph isomorphism

• Hadoop MapReduce framework with a server and 3 desktops

– Juxtapp by S. Hanna et al. (DIMVA 2012) - 49.4 app pair/sec

• k-grams of opcodes hashing feature vector Jaccard distance

• Intel Xeon CPU (8 cores) , 8GB of RAM

– Our approach - 6700 app pair/sec

Open-source *

129* https://github.com/zyrikby/FSquaDRA

Our Solutions

FSquaDRA

TruStore

TruStore: Motivation

No possibility to prohibit the installation of uncertified applications in BYOD scenarios

Large number of third-party markets (Google Play, Yandex.Store, F-Droid, etc.)

Users trust more to the markets that perform application vetting

TruStore: Problem

Issue: How to support an attestation service on the Android platform maintaining

the openness of the ecosystem,

– all markets should have the same possibility to distribute their apps

– a user decides to which markets she trusts more

backward compatibility with already developed apps?

– app developers should not rewrite their apps according to new rules

TruStore: Idea

Apple centralized architecture

IDEA: If an application has passed the

vetting process of a market, sign it with the

market certificate. Ensure on the client-side

that only applications signed with the

approved certificates can be installed on the

device.

PROBLEM: Android has open ecosystem

TruStore: Approach

TruStore Client: Architecture

TruStore Client: Configuration

TruStore: Operation

TruStore: Contributions

We proposed an approach to support attestation services for the Android platform:

– supports the open nature of the Android ecosystem

– does not change current development, signing and publishing workflow

– can be applied to already developed applications

– allows to prohibit installation of uncertified apps in BYOD scenarios

Y. Zhauniarovich, O. Gadyatskaya, B. Crispo. “DEMO: Enabling Trusted

Stores for Android”. In Proc. of CCS‟13, 2013.

Questions?

yury.zhauniarovich@unitn.it

http://zhauniarovich.com

(Some) References

1. Y. Zhauniarovich. “Android Security (and Not) Internals”. Web (2014),

http://zhauniarovich.com/files/asani/asani.pdf

2. E. Fernandes. “Instant Android Systems Development How-to”. Packt Publishing Ltd

(2013)

3. G. Russello, B. Crispo, E. Fernandes and Y. Zhauniarovich. “YAASE: Yet another

Android security extension”. In Proc. PASSAT/SocialCom, 2011.

4. M. Conti, B. Crispo, E. Fernandes, Y. Zhauniarovich. “CRePE: A System for Enforcing

Fine-Grained Context-Related Policies on Android”. In IEEE TIFS, 2012.

5. Y. Zhauniarovich, G. Russello, M. Conti, B. Crispo, E. Fernandes. “MOSES:

Supporting and Enforcing Security Profiles on Smartphones”. In IEEE TDSC, 2014.

6. http://www.idc.com/prodserv/smartphone-os-market-share.jsp

7. Y. Zhauniarovich, O. Gadyatskaya, B. Crispo, F. La Spina, E. Moser. “FSquaDRA:

Fast Detection of Repackaged Applications”. In Proc. of DBSec’14, 2014.

security of the android operating system - · pdf filesecurity of the android operating...

Documents

handouts android fall 2012 · android 2.2 (called froyo....

android mobile operating system

organizzazione didattica della facoltà di sociologia anno...

knowledge about android operating system

operating system: the power of android...keywords: android,...

operating system android

arxiv:1610.00307v2 [cs.cv] 25 apr 2017 · moin nabi2...

android application and android operating system

presentation on android operating system

© 2015 albert-learning.com android operating system android...

operating system and...

© 2014 wheresjenny.com android operating system android...

android operating system project

android, computer, operating system

cop 4600 – summer 2014 introduction to operating systems...

android vs others operating system

sistem operasi android (mobile operating system)

evolution of android operating system

introduction android software development. operating system

synapseindia android apps (operating system)