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

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

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

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

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

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 6

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

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

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

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

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 11

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

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. 13

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 14

Activity III  Starting an Activity from an Intent 15

Activity IV  Forcing an Activity to start 16

Activity V  Protecting Activities 17

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 18

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 19

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

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

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

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

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 24

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 25

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 26

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 27

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 28