mobile application security on android l.
Skip this Video
Loading SlideShow in 5 Seconds..
Mobile Application Security on Android PowerPoint Presentation
Download Presentation
Mobile Application Security on Android

Loading in 2 Seconds...

play fullscreen
1 / 28

Mobile Application Security on Android - PowerPoint PPT Presentation

  • Uploaded on

Mobile Application Security on Android. Originally presented by Jesse Burns at Black Hat 2009. What is Android?. Smart Phone Operating System Based on the Linux kernel Expanded to support cellular based communication GSM, CMDA Java like middleware. More Android. Open Source

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Mobile Application Security on Android' - brad

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
mobile application security on android
Mobile Application Security on Android

Originally presented by Jesse Burns at Black Hat 2009

what is android
What is Android?
  • Smart Phone Operating System
  • Based on the Linux kernel
  • Expanded to support cellular based communication
    • GSM, CMDA
  • Java like middleware
more android
More Android
  • Open Source
    • Mostly Apache v2 license
    • Linux kernel is GPLv2
  • Free
  • Open API’s
    • If Google uses them, so can developers
  • Built from for “components”
    • Activity
    • Service
    • Content Provider
    • Broadcast Receiver
  • Run in own VM sandbox using unique UID
more on apps
More on Apps
  • Use explicitly defined permissions
  • Communicate through Intents
  • Intents are Inter-Process Communications
  • Applications register which Intents they wish to handle
  • applications must be signed, but are usually self-signed
    • proves no relationship with Google, but
    • creates chain of trust between updates and among applications
permissions i
Permissions I
  • >100 defined by the system
  • Declared at install time in Manifest.xml
  • Disclosed by PackageInstaller, protected by root ownership
permissions ii
Permissions II
  • applications can define arbitrary new perms
    • normal
    • dangerous
    • signature
    • signatureOrSystem
permission iii
Permission III
  • Permissions checked at runtime
  • SecurityException thrown if permission denied
  • Core of Android IPC
  • Can cross security boundaries
  • Generally defined as a goal action and some data
intent ii
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
intent filters
Intent Filters
  • Used to determine recipient of Intent
  • Can be overridden
  • Provide no security
    • Intents can explicitly define receiver
  • 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.
activity ii
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
activity iii
Activity III
  • Starting an Activity from an Intent
activity iv
Activity IV
  • Forcing an Activity to start
activity v
Activity V
  • Protecting Activities
  • 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
broadcast ii
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
  • Run in background
  • Play music, alarm clock, etc
  • Secured using permissions
  • Callers may need to verify that Service is the correct one
services ii
Services II
  • Verification:
    • Check Service’s permissions

res = getPackageManager().checkPermission(permToCheck, name.getPackageName());

  • Generally SQL backend
  • Used to share content between apps
  • Access controlled through permission tags
contentproviders ii
ContentProviders II
  • Apps can be dynamically authorized access
    • Possible security hole
  • Must protect against SQL injection
    • Sanitize input using parameterization
intent reflection
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
file system
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
file system ii
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
  • 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
binder ii
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