1 / 71

TBD Android Security and Privacy #2

TBD Android Security and Privacy #2. Prabhaker Mateti. TBD. Mix of slides from various sources TBD Properly merge. Android Security Policy. Android focuses on Inter Component Communication (ICC) AndroidManifest.xml can define an access control policy

Download Presentation

TBD Android Security and Privacy #2

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TBD Android Security and Privacy #2 PrabhakerMateti

  2. TBD • Mix of slides from various sources • TBD Properly merge Android Security

  3. Android Security Policy • Android focuses on Inter Component Communication (ICC) • AndroidManifest.xml can define an access control policy • Each component can be assigned an access permission label • Each application requests a list of permission labels (fixed at install) Android Security

  4. Public and Private Components • Components can be public or private. Default is dependent on “intent-filter” rules. • Components may unknowingly become accessible to other applications. • <activity android:name=“…” android:exported=“false” /> Android Security

  5. Manifest • If the manifest file does not specify an access permission on a public component, any component in any application can access it. • Components without access permissions should be exceptional cases, and inputs must be scrutinized (consider splitting components). • <receiver … android:permission=…> … </receiver> Android Security

  6. Intent • The code broadcasting an Intent can set an access permission restricting which Broadcast Receivers can access the Intent. • Always specify an access permission on Intent broadcasts (unless explicit destination). Android Security

  7. PendingIntent objects allow another application to “finish” an operation for you via RPC. Execution occurs in the originating application’s “process” space. • Used in a number of system APIs (Alarm, Location, Notification) • Implication: The remote application can fill in unspecified values. May influence the destination and/or data integrity. Allows a form of delegation • Best Practice: Only use Pending Intents as “delayed callbacks” to private Broadcast Receivers/Activities and always fully specify the Intent destination. Android Security

  8. Content Providers have two additional security features • Separate “read” and “write” access permission labels • URI permissions allow record level delegation Android Security

  9. A component (e.g., Service) may arbitrarily invoke the checkPermission() method to enforce ICC. You can add reference monitor hooks Android Security

  10. The system uses permission labels to mediate access to certain resource APIs. • android.permission.INTERNET label Android Security

  11. Permission requests are not always granted. • normal - always granted • dangerous - requires user approval • signature - matching signature key • signature or system - same as signature, but also system apps • Users may not understand implications when explicitly granting permissions. • Use signature permissions for application “suites” and dangerous permissions otherwise • Include informative descriptions Android Security

  12. Relatively straightforward model with policy defined in the manifest file ... but many exceptions • Some thought is needed to avoid ... • “Spoofing” Intent messages (FriendReceiver) • Privacy leaks (e.g., FRIEND_NEAR broadcast) • The policy expands into the code • Broadcast permissions, checkPermission(), etc • Keeping malicious applications from acquiring permissions is tricky Android Security

  13. Install-time Verification • Android does not have a way to holistically evaluate system and application policy or specify security goals. For example, to evaluate if the system and installed applications fulfill some security requirement. • Will granting a permission break the phone’s security? • Kirin - enhanced installer http://siis.cse.psu.edu • Extracts policy from the manifest files of all applications • Uses Prolog to generate automated proofs of compliance of provided “policy invariants” • Evaluation performed at install-time, and therefore does not impact runtime performance Android Security

  14. Vulnerability Study of the Android Ryan Selley, Swapnil Shinde, Michael Tanner, Madhura Tipnis, Colin Vinson (Group 8)

  15. Security Architecture - Overview Android Security

  16. Scope of Vulnerabilities • Refinements to MAC Model • Delegation • Public and Private Components • Provision - No Security Access to Public Elements • Permission Granting Using User's Confirmation •    Solutions ??? •           Precautions by Developers •  Special Tools for Users Android Security

  17. Known Vulnerabilities • Image Vulnerablities • GIF • PNG • BMP • Web Browser Android Security

  18. GIF Image Vulnerability • Decode function uses logical screen width and height to allocate heap • Data is calculated using actual screen width and height • Can overflow the heap buffer allowing hacker can allow a hacker to control the phone Android Security

  19. PNG Image Vulnerability • Uses an old libpng file • This file can allow hackers to cause a Denial of Service (crash) Android Security

  20. BMP Image Vulnerability • Negative offset integer overflow • Offset field in the image header used to allocate a palette • With a negative value carefully chosen you can overwrite the address of a process redirecting flow Android Security

  21. Web Browser Vulnerability • Vulnerability is in the multimedia subsystem made by PacketVideo • Due to insufficient boundary checking when playing back an MP3 file, it is possible to corrupt the process's heap and execute arbitrary code on the device • Can allow a hacker to see data saved on the phone by the web browser and to peek at ongoing traffic • Confined to the "sandbox" Android Security

  22. General Mobile Phone Vulnerabilities • GSM • SMS • MMS • CDMA • Bluetooth • Wireless vulnerabilities Android Security

  23. GSM Vulnerabilities • GSM • Largest Mobile network in the world • 3.8 billion phones on network • David Hulton and Steve Muller • Developed method to quickly crack GSM encryption • Can crack encryption in under 30 seconds • Allows for undetectable evesdropping • Similar exploits available for CDMA phones Android Security

  24. SMS Vulnerabilities • SMS • Short Messaging System • Very commonly used protocol • Used to send "Text Messages" • GSM uses 2 signal bands, 1 for "control", the other for "data". • SMS operates entirely on the "control" band. • High volume text messaging can disable the "control" band, which also disables voice calls. • Can render entire city 911 services unresponsive. Android Security

  25. MMS Vulnerabilities • MMS • Unsecure data protocol for GSM • Extends SMS, allows for WAP connectivity • Exploit of MMS can drain battery 22x faster • Multiple UDP requests are sent concurrently, draining the battery as it responds to request • Does not expose data • Does make phone useless Android Security

  26. Bluetooth Vulnerabilities • Bluetooth • Short range wireless communication protocol • Used in many personal electronic devices • Requires no authentication • An attack, if close enough, could take over Bluetooth device. • Attack would have access to all data on the Bluetooth enabled device • Practice known as bluesnarfing Android Security

  27. Hackers for Android • Hackers make Android stronger • White hats want to plug holes • Example • Browser Threat reported by Independent Security Evaluators • Jailbreak hole fixed by Google over-the-air Android Security

  28. Securing a mobile platform from the ground up Rich Cannings <richc@google.com> Alex Stamos <alex@isecpartners.com>

  29. Overview • Why care about mobile security? • What is Android? • How do I develop on Android? • Android Market • What about Security? • Cornerstones of Android security • Prevention • Minimization • Detection • Reaction Android Security

  30. Overview • Why care about mobile security? • What is Android? • How do I develop on Android? • Android Market • What about Security? • Cornerstones of Android security • Prevention • Minimization • Detection • Reaction Android Security

  31. Some Statistics • 6.77 billion people[1] • 1.48 billion Internet enabled PCs[2] • 4.10 billion mobile phones[1] • Mobile phone replacement rate • 12-18 month average[3] • 1.1 billion mobile phones are purchased per year[4] • 13.5% of mobile phone sales are smartphones[5] • The number of smartphones will soon compare with the number of Internet enabled PCs [1] http://en.wikipedia.org/wiki/List_of_countries_by_number_of_mobile_phones_in_use (based on The World Factbook) [2] http://www.itu.int/ITU-D/icteye/Reporting/ShowReportFrame.aspx?ReportName=/WTI/InformationTechnologyPublic&RP_intYear=2008&RP_intLanguageID=1 [3]  [4] http://www.infonetics.com/pr/2009/2h08-mobile-wifi-phones-market-research-highlights.asp [5] http://www.gartner.com/it/page.jsp?id=985912 Android Security

  32. Mobile Security is Getting Interesting • Techniques for desktop analysis are more useful to smart phones • Mobile networks can now be easily manipulated •  From phones: • Miller, Lackey, Miras at BlackHat 2009 • From false base stations: • http://openbts.sourceforge.net/ Android Security

  33. Mobile Security Matures We are now seeing attacks against all layers of mobile infrastructure: • Applications • Platform • OS • Baseband • Network Android Security

  34. Mobile Security Matures We are now seeing attacks against all layers of mobile infrastructure: • Applications • Platform • OS • Baseband • Network Mobile devices must be treated as fully fledged computers. Do not assume they are "special". Android Security

  35. Overview • Why care about mobile security? • What is Android? • How do I develop on Android? • Android Market • What about Security? • Cornerstones of Android security • Prevention • Minimization • Detection • Reaction Android Security

  36. The Android Platform • Free, open source mobile platform • Source code at http://source.android.com • Any handset manufacturer or hobbyist can install • Any developer can use • SDK at http://developer.android.com • Empower users and developers Android Security

  37. The Android Technology Stack • Linux kernel • Relies upon 90+ open source libraries • Integrated WebKit based browser • SQLite for structured data storage • OpenSSL • BouncyCastle • libc based on OpenBSD • Apache Harmony • Apache HttpClient • Supports common sound, video and image codecs • API support for handset I/O • Bluetooth, EDGE, 3G, wifi • Camera, Video, GPS, compass, accelerometer,            sound, vibrator Android Security

  38. Overview • Why care about mobile security? • What is Android? • How do I develop on Android? • Android Market • What about Security? • Cornerstones of Android security • Prevention • Minimization • Detection • Reaction Android Security

  39. Android Development • Java applications are composed of: • Activities • Visual user interface for one focused endeavor Android Security

  40. Android Development • Java applications are composed of: • Activities • Visual user interface for one focused endeavor • Services • Runs in the background for an indefinite period of time Android Security

  41. Android Development • Java applications are composed of: • Activities • Visual user interface for one focused endeavor • Services • Runs in the background for an indefinite period of time • Intents • Asynchronous messaging • URL dispatching on steroids • Glues many Activities and Services together to make an application • Provides interactivity between applications Android Security

  42. Example Email Application Android Security

  43. Application Lifecycle • Designed to protect battery life Android Security

  44. Application Lifecycle • Designed to protect battery life • Activities live on a stack Android Security

  45. Application Lifecycle • Designed to protect battery life • Activities live on a stack Android Security

  46. Application Lifecycle • Designed to protect battery life • Activities live on a stack • Background activities can be killed at any moment Android Security

  47. Application Lifecycle • Designed to protect battery life • Activities live on a stack • Background activities can be killed at any moment • The platform makes it easy for developers to code applications that are killed at any moment without losing state • Helps with DoS issues Android Security

  48. Android Market • Connects developers with users • Darwinian environment • Good applications excel  • Bad applications forgotten • ~10,000 applications on Market • Balance of openness and security • Not the only way to install apps • Not a walled garden • Developers self-sign applications • For updating • Uses Java's keytool and jarsigner Android Security

  49. Application Signing Why self signing? • Market ties identity to developer account • CAs have had major problems with fidelity in the past • No applications are trusted.  No "magic key" What does signing determine? • Shared UID for shared keys • Self-updates Android Security

  50. Overview • Why care about mobile security? • What is Android? • How do I develop on Android? • Android Market • What about Security? • Cornerstones of Android security • Prevention • Minimization • Detection • Reaction Android Security

More Related