Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating

1. 35th IEEE Symposium on Security and Privacy (Oakland'14) Upgrading Your Android, Elevating My Malware: Privilege Escalation Through Mobile OS Updating LuyiXing1, XiaoruiPan1, RuiWang2, KanYuan1, and XiaoFengWang1 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 3rd-party 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 PMS Installing 3rd-party apps Installing System apps Installed malware Claimed for permissions of new OS or apps Declare new permissions Reinstalling the old malware Old OS can not recognize these permissions Automatically grant the permissions These permissions are restricted below “dangerous” level No report Without user’s consent

11. Pileup Exploits – Permission Harvesting and Preempting Before updating Updating to new OS PMS PMS PMS Installed malware Installing System apps Building mSettings for old apps Installing 3rd-party apps Declared and defined the permissionsthe same as those of new system apps check Declare new permissions mPermissions Skip if conflicts Reinstalling the old malware Old OS lets the malware declare them “signature” - OK “system” - OK Lower to “normal” – OK Change the description – OK Automatically declare and grant permissions Without user’s intervention Without user’s consent Example: CertInstaller Google Cloud MessagingDemo

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 Updating to new OS PMS PMS PMS Installed malware Installing System apps Building mSettings for old apps Installing 3rd-party apps Declared sharedUID the same as that of the new system app Check sharedUID Reinstalling the old malware pkgSetting mSettings If equals, load the setting and verify the signature Download another app to replace the canceled system app Signed by 3rd-party Cancel installing Cancel if the verification failed Shared UID Grabbing: DEMO

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 PMS Installed malware Installing System apps Installing 3rd-party apps Building mSettings for old apps Used package name the same as that of the new system app Check <PackageName> conflict pkgSetting mSettings Cancel installing the malware SharedUID is empty If found the same <PackageName>, compare sharedUID SharedUID is empty /data/data/ <PackageName> Data of the malware ∵Both sharedUIDs are empty. Load the malware’s setting pkgSetting Data Contamination: Demo1 – inject scripts to caches Demo2 – bookmark phishing Demo3 – Login CSRF

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 Updating to new OS PMS PMS PMS Installed malware Installing System apps Building mSettings for old apps Installing 3rd-party apps Declared permissiontree that covers permissions of the new system app Check Reinstalling the old malware Declare new permissions mPermissio-ntrees If found covering, registration will fail permission.ADD_VOICEMAIL google.apps.permission.GOOGLE_AUTH  google.apps.permission

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 non-system 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.