35th IEEE Symposium on Security and Privacy (Oakland'14)
Upgrading Your Android, Elevating My
Malware: Privilege Escalation Through
Mobile OS Updating
Luyi Xing1, Xiaorui Pan1, Rui Wang2, Kan Yuan1, and XiaoFeng
Wang1
1Indiana
University Bloomington
2Microsoft Research
左昌國
2014/05/12 Seminar @ ADLab, CSIE, NCU
2
Outline
• Introduction
• Pileup Exploits
• Finding Pileups
• Measurement and Evaluation
• Conclusions
3
Introduction
• Mobile OS Updating (Android)
• More complex
• Sandboxed apps
• Lots of sensitive user data
• Updating live system
• More often
• More files
• 15,525 files from
4.0.4 to 4.1.2
• Less steps (for user)
• Press one button
4
Introduction
• Android Updating
• Download upgrading image through OTA (Over the Air)
• Reboot to recovery mode
• Replace some system files, such as bootloader, Package Manager
Service (PMS), and APKs under /system directory
• Reboot to the new OS
• Update other components
5
Introduction
• What PMS does when upgrading Android OS
• Install or reinstall all system apps under /system, and then 3rdparty apps under /data/app
• Register an app’s permissions, shared UID, activities, intent
filters, ……
• Decide what to do when a conflict occurs (duplicated attr. or prop.)
• Build a structure mSettings for existing apps, and include:
• mPackages
• mUserIds
• mSharedUsers
• mPermissions
• etc.
• Check the mSettings when installing a new system package
• If having conflicts, decide case by case.
6
Introduction
• What’s wrong with PMS?
• Conservative strategy
• Avoid improperly replacing existing properties
• Maintain old user data
• Same logic for both system upgrading and normal app installation
• When conflict occurs upon upgrading…
• If PMS chooses wrong attributes or properties to keep…
7
Pileup Exploits
• Adversary Model
• Malicious apps have been installed on the victim’s devices
• Such malware can be uploaded to Google Play and 3rd-party
markets
• The malware appears less dangerous than some legitimate apps
• No dangerous permissions needed
• The victim’s devices are going to be updated
• Such updates come with new security-critical privileges and
capabilities
8
Pileup Exploits
• Permission Harvesting and Preempting
• Shared UID Grabbing
• Data Contamination
• Denial of Services
9
Pileup Exploits – Permission Harvesting
and Preempting
• Permission protection levels (link)
• normal
• dangerous
• signature
• signatureOrSystem
• system
• development
• PMS problematically handles the permissions inherited
from the old system
10
Pileup Exploits – Permission Harvesting
and Preempting
Before
updating
Updating to new OS
PMS
Installed
malware
Claimed for
permissions of
new OS or
apps
Installing
System apps
Declare new
permissions
PMS
Installing
apps
3rd-party
Reinstalling the
old malware
Old OS can not
recognize these
permissions
Automatically
grant the
permissions
No report
Without user’s
consent
These permissions
are restricted below
“dangerous” level
11
Pileup Exploits – Permission Harvesting
and Preempting
Before
updating
Updating to new OS
PMS
PMS
Installed
malware
Declared and
defined the
permissions the
same as those
of new system
apps
Old OS lets the
malware
declare them
Without user’s
intervention
Building
mSettings
for old apps
mPermissions
Installing
System apps
Installing
apps
3rd-party
check
Skip if
conflicts
Declare new
permissions
“signature” - OK
“system” - OK
Lower to “normal” – OK
Change the description – OK
Example:
CertInstaller
Google Cloud Messaging Demo
PMS
Reinstalling the
old malware
Automatically
declare and grant
permissions
Without user’s
consent
12
Pileup Exploits – Permission Harvesting
and Preempting
13
Pileup Exploits – Shared UID Grabbing
• Shared UID (android:sharedUserId) (link)
• If 2 apps use the same sharedUserId, the OS will assign them
the same UID when being installed.
• Application with the same user ID can access each other's data
and, if desired, run in the same process.
14
Pileup Exploits – Shared UID Grabbing
Before
updating
Installed
malware
Declared
sharedUID
the same as
that of the new
system app
Signed by 3rdparty
Updating to new OS
PMS
PMS
Building
mSettings
for old apps
Installing
System apps
mSettings
Check
sharedUID
pkgSetting
If equals, load the
setting and verify the
signature
Cancel if
the verification failed
Shared UID Grabbing: DEMO
Cancel
installing
PMS
Installing
apps
3rd-party
Reinstalling the
old malware
Download another
app to replace the
canceled system
app
15
Pileup Exploits – Shared UID Grabbing
16
Pileup Exploits – Data Contamination
• Android keeps the data for both system and 3rd-party apps
under directory /data/data/<PackageName>
• This directory is owned by a unique Linux UID
17
Pileup Exploits – Data Contamination
Before
updating
Updating to new OS
PMS
PMS
Installed
malware
Used package
name the same
as that of the new
system app
Building
mSettings
for old apps
mSettings
/data/data/
<PackageName>
Data of the
malware
Installing
System apps
Check
<PackageName>
∵Both sharedUIDs
are empty.
Load the malware’s setting
Data Contamination:
Demo1 – inject scripts to caches
Demo2 – bookmark phishing
Demo3 – Login CSRF
Installing
apps
3rd-party
conflict
pkgSetting
If found the same SharedUID is
<PackageName>, empty
compare sharedUID
SharedUID is
empty
PMS
pkgSetting
Cancel
installing the
malware
18
Pileup Exploits – Denial of Services
• A permission typically can only be defined before an app
has been installed.  exception: Permission Tree
• Permission tree (link)
• An app can define a base name (root) of a tree of permissions.
• Once declaring the tree, the app controls the whole name space
defined by the root.
• During runtime, the app can add individual permission within the
tree.
19
Pileup Exploits – Denial of Services
Before
updating
Installed
malware
Declared
permissiontree
that covers
permissions of
the new
system app
Updating to new OS
PMS
PMS
Building
mSettings
for old apps
Installing
System apps
PMS
Installing
apps
3rd-party
Check
mPermissiontrees
Declare new
permissions
If found covering,
registration will fail
permission.ADD_VOICEMAIL
google.apps.permission.GOOGLE_AUTH
 google.apps.permission
Reinstalling the
old malware
20
Pileup Exploits – Denial of Services
• Blocking Google Play Services
• From Android 2.3 to 4.0, after all apps’ installation complete,
Google Play is then downloaded and installed as a 3rd-party app.
• A malware on 2.3.6 could use the same package name as Google
Play, and blocks the installation of Google Play when upgrading to
4.0
• Many apps rely on Google Play Services
21
Finding Pileups
• SecUP Architecture
22
Finding Pileups
• Detecting Update Flaws
• Manually built reference PMS (AOSP 4.0.4)
• Every other version of PMS is compared to the reference PMS, and
is automatically annotated
• Reuse when possible
• Automatically create new annotation
• Manual adjustments if needed
23
Finding Pileups
• Assertions for pileup detection
• Generally, 2 security constraints for PMS:
• A non-system app and its dynamic content should not gain any more
privileges on the new OS than they have on the old Android.
• A non-system app should not compromise the integrity and the
availability of the new Android (e.g. changing the settings and data)
24
Finding Pileups
• If Assertion (1) is FALSE and Assertion (2) is TRUE
• (Assertion (1) == FALSE)  pkgSetting is originally from
non-system app
• (Assertion (2) == TRUE)  attribute in pkg is assigned to the
original value of pkgSetting right after init
 A non-system old app is affecting the new system app
25
Finding Pileups
• If Assertion (3) is FALSE
1. ((bp.pkgFlags & 1) != 0) == FALSE  non-system old app
2. (bp.sourcePkg.equals(pkg.pkgName)) == FALSE  the old
app name is NOT equal to the new system app name
 If new permission name exists on old OS, and it is from nonsystem old app, and the <PackageName> is not equal
26
Finding Pileups
• Finding Exploit Opportunities
• Different Android versions, manufacturers, device models, and
carriers (Wireless Service Provider) are affected under different
exploit opportunities.
Image scan
• Compare system attributes and properties on 2 consecutive versions
from the same manufacturer, device model, region, and carrier.
• Find out those newly added permissions or other attributes and props.
27
Finding Pileups
• Pileup Scanner (Google Play)
• The app only asks for the INTERNET permission.
1. Gather information from android.os.Build
2. Query the database for the exploit opportunites
3. Call API getInstalledPackages to get the names of installed
packages, and use getPackageInfo to retrieve the information
28
Measurement and Evaluation
• Android image collection
• 38 images for Google Nexus devices
• Nexus7, Nexus10, Nexus Q, Galaxy Nexus, Nexus S
• From 2.3.6 to 4.3
• 3,511 images for Samsung devices
• 217 devices models, 267 carriers
• From 2.3 to 4.3
• Source code of AOSP versions and customized versions
• 1,522 from Samsung, 377 from LG, 1,593 from HTC
29
Measurement and Evaluation
• Limitation
• Permission harvesting
• Registration of non-system app’s property
• Assertions do not cover
• Google Play Services DoS
• Google Play is installed under the /data/app directory on Android 4.0.4
•  3rd-party
30
Measurement and Evaluation
• Measurement of Opportunities
• From the 38 Google and 3,511 Samsung images
• 741 update instances
31
Measurement and Evaluation
• Sensitive permissions  at least dangerous protection level
• Restrictive  above dangerous
32
Measurement and Evaluation
• At least one new shared UID was added in 50% update instances
33
Measurement and Evaluation
• Impacts of customizations
• Though Google and AOSP make the biggest system overhaul from
2.3.X to 4.0.X and show a trend of less aggressive updating
afterwards, Samsung continues to bring in more new stuffs.
34
Measurement and Evaluation
• 4.0 - 4.1
• DCM (Docomo), TMB (T-Mobile)
• 4.1 - 4.2
• DBT (Deutsche Bundespost Telekom), INU, SER
35
Measurement and Evaluation
• Evaluating Scanner
• Effectiveness:
• Install top 100 free apps from Google Play
• Install system apps that could be updated through Google Play
• Install a set of attack apps
• Update Android version one by one, until 4.3
All malicious apps detected and no false positives
• Performance
36
Conclusion
• Android update, in order to ensure the smooth process
without endangering user assets, becomes error-prone.
• This paper reported the first systematic study of the
problem.
• Revealed Pileup vulnerabilities
• Performed large-scale measurement to confirm the presence of
such flaws in all Android versions.
• To mitigate the threat, this paper proposed SecUP to
detect Pileup vulnerabilities.