Permission in Android Security: Threats and solution
•Als PPTX, PDF herunterladen•
7 gefällt mir•3,219 views
Possible threats found and mitigation
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Permission in Android Security: Threats and solution
Ähnlich wie Permission in Android Security: Threats and solution (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Permission in Android Security: Threats and solution
- 2. Permissions in Android Security: Threats and Solutions Permissions Threats Solutions Conclusion and Future Work
- 3. Permissions Allow apps to access resources Limited access to resources Installation time User approval
- 4. System Permissions URI Permissions Self-declare Permissions Permissions Type
- 5. System Permissions URI Permissions Self-declare Permissions Permissions Type Owned by system Allow access to system resources <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.app.myapp" > <uses-permission android:name="android.permission.RECEIVE_SMS" /> <uses-permission android:name="android.permission.INTERNET" /> </manifest>
- 6. System Permissions URI Permissions Self-declare Permissions Permissions Type version name Version number API Level Total Permissions KitKat 4.4 19 145 Jelly Bean 4.3 18 134 4.2 17 130 4.1 16 130 Ice Cream Sandwich 4.0.3 15 124 4.0 14 122 Honeycomb 3.2 13 117 3.1 12 116 3.0 11 116 Gingerbread 2.3.4 10 115 2.3.3 9 115 Froyo 2.2 8 112
- 7. System Permissions URI Permissions Self-declare Permissions Permissions Type Owned by system Allow access to data without grant permission to access content provider Email app and document/pdf reader app
- 8. System Permissions URI Permissions Self-declare Permissions Permissions Type Owned by apps Allow processes to access apps resources <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.me.app.myapp" > <permission android:name="com.me.app.myapp.permission.CHANGE_ROOT_PASSWD" android:label="@string/label_changeRootPasswd" android:description="@string/description_changeRootPasswd" android:permissionGroup="android.permission-group.PERSONAL_INFO" android:protectionLevel="dangerous" /> </manifest>
- 10. Permissions Request Flow 1. Install an app 2. System check permissions in AndroidManifest.xml 3. System ask user for approval User Approve ? System grants all permissions System cancel the installation System continue to installation process and App is installed System denies all permissions No Yes
- 12. Permissions Threats A: an App No INTERNET permission B: another App INTERNET permission A: Malicious App No INTERNET permission Android System Services INTERNET Rejected B: Vulnerable App INTERNET permission INTERNET INTERNET Accepted AcceptedPermission Re-delegation Over-privilege Permission inheritance
- 13. Permissions Threats Flashlight App Permission list: FLASHLIGHT INTERNET ACCESS_FINE_LOCATION READ_CONTACT B: Social Media App Permission list: INTERNET ACCESS_FINE_LOCATION READ_CONTACT READ_PROFILE CAMERA Over Privilege App Permission Re-delegation Over-privilege Permission inheritance
- 14. Flashlight App Permission list: FLASHLIGHT Social Media App Permission list: INTERNET ACCESS_FINE_LOCATION READ_CONTACT READ_PROFILE CAMERA UID: 0123-4567-8910 UID: 0123-4567-8910 Permissions Threats Flashlight App Permission list: FLASHLIGHT INTERNET ACCESS_FINE_LOCATION READ_CONTACT READ_PROFILE CAMERA UID: 0123-4567-8910 Social Media App Permission list: INTERNET ACCESS_FINE_LOCATION READ_CONTACT READ_PROFILE CAMERA FLASHLIGHT UID: 0123-4567-8910 Permission Re-delegation Over-privilege Permission inheritance
- 15. Solutions Permission Re-delegation Over-privilege Permission inheritance
- 16. Solutions Type of solution • System modification / Hook modification and services • Android services • Non-android application Implementation level • System/Kernel • Application • Separate system Run-time mode • Static • Dynamic
- 17. Permission Re-delegation Over-privilege Permission inheritance Solutions Name Type of Solution Implementation Running mode IPC Inspection System modification System Dynamic Quire System modification System Dynamic
- 18. Solutions Name Type of Solution Implementation Running mode Webifest Manifest file Application Static Stowaway Non-android apps Separate system Static Pscout Non-android apps Separate system Static RefineDroid Non-android apps Separate system Static Mr. Hide Android service Application Dynamic Dr. Android Non-android apps Separate system Static Apex System modification System Static SAINT System modification System Static and Dynamic Analysis Tool Non-android apps Separate system Static Permission Re-delegation Over-privilege Permission inheritance
- 19. Solutions Sign with different keys • Android apps • Application • Static Permission Re-delegation Over-privilege Permission inheritance
- 20. Solutions - Complete Matrix Threats Proposed Solution Type of Solution Implementation Level Solution Running mode Ref Permission Re- delegation IPC Inspection System modification System level Dynamic [9] Quire System modification System level Dynamic [18] Over Privilege Webifest website manifest file Application level Static [11] Stowaway Non-android application Separate system Static [12] PScout Non-android application Separate system Static [13] RefineDroid Non-android application Separate system Static [14] Mr. Hide Android service Application level Dynamic [14] Dr. Android Non-android application Separate system Static [14] Apex System modification System level Static [20] SAINT System modification System level Static and Dynamic [17] Static analysis tool Non-android application Separate system Static [23] Permission inheritance Sign apps with different keys android apps Application level Static [16]
- 21. Conclusio n 3 threats found Numbers of solutions Different implementation level
- 22. Future Work Combination of solutions Are solutions implemented? Cost matrix of solutions: performance, speed, power consumption, complexity
Hinweis der Redaktion
- The <protectionLevel> attribute is required, telling the system how the user is to be informed of applications requiring the permission, or who is allowed to hold that permission, as described in the linked documentation.The <permissionGroup> attribute is optional, and only used to help the system display permissions to the user. You will usually want to set this to either a standard system group (listed in android.Manifest.permission_group) or in more rare cases to one defined by yourself. It is preferred to use an existing group, as this simplifies the permission UI shown to the user.Note that both a label and description should be supplied for the permission. These are string resources that can be displayed to the user when they are viewing a list of permissions (android:label) or details on a single permission ( android:description). The label should be short, a few words describing the key piece of functionality the permission is protecting. The description should be a couple sentences describing what the permission allows a holder to do. Our convention for the description is two sentences, the first describing the permission, the second warning the user of what bad things can happen if an application is granted the permission.
- The default value. A lower-risk permission that gives requesting applications access to isolated application-level features, with minimal risk to other applications, the system, or the user. The system automatically grants this type of permission to a requesting application at installation, without asking for the user's explicit approval (though the user always has the option to review these permissions before installing).A higher-risk permission that would give a requesting application access to private user data or control over the device that can negatively impact the user. Because this type of permission introduces potential risk, the system may not automatically grant it to the requesting application. For example, any dangerous permissions requested by an application may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities. A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user's explicit approval. A permission that the system grants only to applications that are in the Android system image or that are signed with the same certificate as the application that declared the permission. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. The "signatureOrSystem" permission is used for certain special situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.
- IPC Inspection. IPC Inspection runs by modifying android framework, to defend permission re-delegation attacks by depreciate application permission after received communication from less privileged apps. Felt et al. [9] discovered on their case study that IPC Inspection helps to mitigate attacks.Quire. Dietz et al. [18] proposed a modified android system by perform trail and record call-chain request made by applications. It also add trusted signature with simple cryptography function to protect propagated data through the RPC for authentication. The author modify android IPC to suit the Quire IPC design, so that tracking call-chain happens.
- Kirin. Kirin is a tool to identify whether an app consider to be malware or not by examine the requested permission with a set of security rules. With KirinSemanticLanguage. Enck et al. [10] able to define the security rules. Kirin runs as android service, and requires alteration to android system to call Kirin if any apps perform installation.Webifest. Amrutkar et al. [11] proposed Webifest, android manifest file to define permissions for page in mobile browser, the file sent through HTTPS connection to avoid man-in-the-middle attacks to change the requested permissions. Browser will parser the permissions into normal and dangerous categories, which normal does not requires user consent. The granting mechanism for such requests is in run-time instead of install-time.Stowaway. Tool developed by Felt et al. [12] to detect over-privilege apps. Android does not provide comprehensive document on permissions, it may lead to developer to use more permissions on an app. Therefore the author use Kirin to map API’s call to permissions, and compare with apps permissions to detect over-privilege permissions. Stowaway maps only API’s calls on android version 2.2. It still involve human for testing due to inconsistency between permissions and the APIs. Kirin runs on separate system.PScout. PScout is the work of Au et al. [13], it was the next generation tool of Stowaway, and it has similar function, to maps APIs to permissions. Hence it not only works on android version 2.2, but also works on android version 2.2 to version 4.0.RefineDroid. RefineDroid is a static analysis tool, built to validate the taxonomy that separates android permissions into 4 categories based on the protected resources. It analyzes apps’ Dalvikbytecode. RefineDroidis parts of solutions proposed by Jeon et al. [14]. Mr. Hide. Jeon et al. [14] proposed solution to enforce a new fine-grained permissions over an app, it runs as android service. Furthermore, apps will no longer able to have direct access to sensitive android APIs without pass through Mr. Hide. Mr. Hide works together with RefineDroidand Dr. Android.Dr. Android. Dr. Android is parts of proposed solutions from Jeon et al. [14], works together with RefineDroidand Mr. Hide. It provides functions to modify the app’s Dalvikbytecode to use Mr. Hide and injects hidelibcode to apps. Futhermore, It modifies app’s manifest to remove android permissions, add hidelib permissions and modify declared program entry points. Last, It modifies resource file that define user interface layout so that hidelibclasses with user interface element are referenced as needed.Apex. Nauman et al. [20] proposed a policy enforcement framework, an extension to the existing android framework with a minimal modification, to allow user selectively grants or denies permissions and set a constraint for applications to access android resources based on pre-defined policy. Furthermore, At run-time, Apex implement access confinement, such that applications only allow to use specific resources they need to access, or to run at specific time range, or use at specific location, or even limit applications usage by number of times they have been used.SAINT. Another work by Ongtang et al. [17] to control installation-time permissions requests with policies, to control communication between applications interfaces and to confine applications access based on run-time. SAINT able to restrict application access with access-based constraint. By restricting based on the resources access, SAINT will prevent unwanted access at certain condition, even they are granted with the permissions. SAINT is a modified android system.Static analysis tool. Batyuk et al. [23] proposed a static analysis tool to provide in-depth analysis and comprehensible report to users. Furthermore, the author proposed to reverse engineering the app, modify the binary, remove unwanted permissions while keep maintaining its core functionality.
- Sign apps with different keys. Barrera et al. [16] suggest to sign each application with different keys, to avoid apps to have same developer key. Apps with shared key may allow android system assigns the same UID. If there are apps with shared UID, the apps may suffer from Permission Inheritance or Retroactive Permission Inheritance.