Mobile Application Security on Android

1. Mobile Application Security on Android Originally presented by Jesse Burns at Black Hat 2009

2. What is Android? • Smart Phone Operating System • Based on the Linux kernel • Expanded to support cellular based communication • GSM, CMDA • Java like middleware

3. More Android • Open Source • Mostly Apache v2 license • Linux kernel is GPLv2 • Free • Open API’s • If Google uses them, so can developers

4. Applications • Built from for “components” • Activity • Service • Content Provider • Broadcast Receiver • Run in own VM sandbox using unique UID

5. More on Apps • Use explicitly defined permissions • Communicate through Intents • Intents are Inter-Process Communications • Applications register which Intents they wish to handle

6. Signatures • applications must be signed, but are usually self-signed • proves no relationship with Google, but • creates chain of trust between updates and among applications

7. Permissions I • >100 defined by the system • Declared at install time in Manifest.xml • Disclosed by PackageInstaller, protected by root ownership

8. Permissions II • applications can define arbitrary new perms • normal • dangerous • signature • signatureOrSystem

9. Permission III • Permissions checked at runtime • SecurityException thrown if permission denied

10. Intents • Core of Android IPC • Can cross security boundaries • Generally defined as a goal action and some data

11. Intent II • Used to: • Start an Activity • Broadcast events or changes • Start, stop, or communicate with background Services • Access data held by ContentProviders • Call backs to handle events

12. Intent Filters • Used to determine recipient of Intent • Can be overridden • Provide no security • Intents can explicitly define receiver

13. Activities • The user interface consists of a series of Activity components. • Each Activity is a “screen”. • User actions tell an Activity to start another Activity, possibly with the expectation of a result.

14. Activity II • The target Activity is not necessarily in the same application. • Directly or via Intent “action strings”. • Processing stops when another Activity is “on top”. • Must be able to handle malformed intents • Don’t start Intents that contain sensitive data

15. Activity III • Starting an Activity from an Intent

16. Activity IV • Forcing an Activity to start

17. Activity V • Protecting Activities

18. Broadcasts • Act as recievers for multiple components • Provide secure IPC • Done by specifying permissions on BroadcastReceiver regarding sender • Otherwise, behave like activities in terms of IPC

19. Broadcast II • Still need to validate input just in case • Sticky Broadcasts • Persistent • Apps require special permissions to create/destroy sticky broadcasts • No guarantee of persistence • Can’t define permission • Don’t send sensitive data

20. Services • Run in background • Play music, alarm clock, etc • Secured using permissions • Callers may need to verify that Service is the correct one

21. Services II • Verification: • Check Service’s permissions res = getPackageManager().checkPermission(permToCheck, name.getPackageName());

22. ContentProviders • Generally SQL backend • Used to share content between apps • Access controlled through permission tags

23. ContentProviders II • Apps can be dynamically authorized access • Possible security hole • Must protect against SQL injection • Sanitize input using parameterization

24. Intent Reflection • Intents may be sent when app is called • App sends Intent as app and not as caller: reflection • May exceed caller’s permissions • Use PendingIntent instead, intent correctly identified as coming from caller

25. File System • Internally standard Linux file systems – yaffs2, ext* • Support stand Unix permissions • Vulnerabilities if permissions not set correctly • Sensitive data could be read • Other programs could write junk/waste space

26. File System II • Consider what files need what protections • Config files: not writeable • Log files: not world readable • Mass storage formatted as FAT, no Unix permissions support • All data world readable • Consider encryption

27. Binder • Kernel module that provides secure IPC on top of the standard Linux shared memory architecture • Includes interface to Parceable • Parceable objects are passed by Binder • Can also move file descriptors, and other Binders

28. Binder II • Efficient, secure IPC • Check caller’s permissions / identity • Only selectively give out interface • Once given out, interface can be disseminated freely • All Binders are globally unique