security of the android operating system - · pdf filesecurity of the android operating...
TRANSCRIPT
Security of the Android
Operating System
Yury [email protected]
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
2
Outline
General Bits and Pieces
Android Architecture
Android Security Internals
Security Problems and Solutions
What is the codename of the
following Android version?
4
General Bits and Pieces
Android Architecture
Android Security Internals
Security Problems and Solutions
Mobile Operating Systems
6
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
7
History of Android (2002-2007)
8
• 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
History of Android (2007-2009)
9
• 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)
History of Android (2010-2013)
10
• 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
12
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?
13
General Bits and Pieces
Android Architecture
Android Security Internals
Security Problems and Solutions
Android Stack
15
Linux Kernel
Linux Kernel is used:
Memory management
Process management
Security module
Networking
etc
Android Enhancements:
Ashmem
Power management
Binder IPC
Logger
etc
16
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
SSL
The core of web browser
Bionic libc
17
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
etc.
18
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.
19
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
– Dropbox
– Feedly
– Chrome
– etc.20
Android Stack
21
General Bits and Pieces
Android Architecture
Android Security Internals
Security Problems and Solutions
General Overview
Linux Kernel:
– Application Sandboxing
Android Middleware:
– IPC Reference Monitor
23
Android Security Internals
Linux Kernel Level
Native Userspace Level
Application Framework Level
Application Level
Linux DAC
25
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
27
System Defined AIDs
28
system/core/include/private/android_filesystem_config.h
System Component Protection
29
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
30
Paranoid Networking Patches
kernel/include/linux/android_aid.h
31
Paranoid Networking Patches
kernel/net/ipv4/af_inet.c
32
Can you describe other ways
of application sandboxing?
33
Android Security Internals
Linux Kernel Level
Native Userspace Level
Application Framework Level
Application Level
Android Boot Process
35
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
36
Android Filesystem
37
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
38
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}
39
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
system/core/include/private/android_filesystem_config.h
40
Android System Usernames {1}
41
system/core/include/private/android_filesystem_config.h
Filesystem Definitions {1}
42
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
43
/init {2}
44
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
45
Excerpt of init.rc {3}
system/core/rootdir/init.rc
46
Daemon ueventd {4}
Responsible for system and device events
At the beginning replays the kernel ueventhotplug events specified in uevent.rc files
47
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
48
Sockets
49
Processes
50
Android Security Internals
Linux Kernel Level
Native Userspace Level
Application Framework 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
52
Inter Process Communication
53
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
54
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?
56
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
57
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()
58
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?
59
android.os.Binder.getCallingUid() in set of allowed uids
checkCallingOrSelfPermission(permission)
Permission Check Example
60
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
61
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
62
Permission Protection Level
63
• 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
64
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
65
Package Manager Check
66
Kernel Permission Mapping
frameworks/base/data/etc/platform.xml
67
Android Security Internals
Linux Kernel Level
Native Userspace Level
Application Framework 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
69
Application Components
70
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
71
Description
writting
Cover
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
72
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
Data
Category
Extras
Flags
Implicit Intents
Implicit intents are often used to activate components in other applications
Required:
Component name = blank
Action
Data
Category
Optional
Extras
Flags
73
Android Manifest
74
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
75
Application Build Process
76
Device
Compilation
and
Packaging
SigningDevelopercertificate
Android Project
assets
AndroidManifest.xml
resources
source code
Android Package (.apk)
assets
AndroidManifest.xml
uncompiled resources
.dex
files
resources.
arsc
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)
77
General Bits and Pieces
Android Architecture
Android Security Internals
Security Problems and Solutions
What the most critical security
problems do you see in Android?
79
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
80
Security Problems and Solutions
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.
82
Stowaway Example
83
Do Users Understand Permissions?
WAKE_LOCK
USE_CREDENTIALS
MANAGE_ACCOUNTS
AUTHENTICATE_ACCOUNTS
WRITE_SETTINGS
com.android.vending.BILLING
84
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
85
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
86
* M. Conti et al. “CRePE: A System for Enforcing Fine-Grained Context-Related
Policies on Android”. In IEEE TIFS, 2012
Security Problems and Solutions
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
88
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
89
* 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
90
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***
91
* 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.
Security Problems and Solutions
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
93
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
94
Security Problems and Solutions
Android Malware
Repackaging
Dynamic Update Attack
Repackaging
96
Android Package (.apk)
assets
AndroidManifest.xml
uncompiled resources
.dex
files
resources.
arsc
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)**
97
* C.Gibler et al. “Adrob: examining the landscape and impact of Android application
plagiarism”. In Proc. of MobiSys ‟13
** Y. Zhou, X. Jiang. “Dissecting Android malware: Characterization and Evolution”.
In Proc. of S&P ‟12
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
98
Security Problems and Solutions
Android Malware
Repackaging
Dynamic Update Attack
Dalvik VM
Dynamic Updates
100
Android Package (.apk)
assets
AndroidManifest.xml
uncompiled resources
.dex
files
resources.
arsc
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
101
Solutions
White-listing of the code loaded dynamically
– Time lag
– Huge whitelists
– Requires analysis of the loaded code
Application vetting
102
* 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
103
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
Security Problems and Solutions
Permission System
Private Information
Android Malware
Our Solutions
Security Problems and Solutions
Our Solutions
MOSES
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
107
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
108
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
109
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.
110
MOSES: Architecture
111
MOSES Configuration:
Security Profile Creation
112
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”;
MOSES Configuration:
Context Definition
113
create_context “home”;condition [(latitude=“55”) AND (longitude=“11”) AND (radius=“1000m”)];
MOSES Configuration:
Special Rule Creation
114
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
115
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.
Security Problems and Solutions
Our Solutions
MOSES
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)**
117
* C.Gibler et al. “Adrob: examining the landscape and impact of Android application
plagiarism”. In Proc. of MobiSys ‟13
** Y. Zhou, X. Jiang. “Dissecting Android malware: Characterization and Evolution”.
In Proc. of S&P ‟12
Problem Statement
Issue: How to detect repackaged Android applications
fast
– 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
118
* 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)
119
FSquaDRA: Approach
Compute hashes of all files inside two apps
Calculate Jaccard index for the extracted hashes:
120
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
121
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
122
Evaluation: Pairwise Comparison
123
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
124
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
125
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)
126
Effectiveness: Plagiarizing Results
(different certificates, fss>0)
127
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)
128
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
Security Problems and Solutions
Our Solutions
MOSES
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
131
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
132
TruStore: Idea
133
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
134
TruStore Client: Architecture
135
TruStore Client: Configuration
136
TruStore: Operation
137
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
138
Y. Zhauniarovich, O. Gadyatskaya, B. Crispo. “DEMO: Enabling Trusted
Stores for Android”. In Proc. of CCS‟13, 2013.
Questions?
http://zhauniarovich.com
139
(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.
140