Security Philosophy. Humans have difficulty understanding risk

Transcription

1 Android Security

2 Security Philosophy Humans have difficulty understanding risk Safer to assume that Most developers do not understand security Most users do not understand security Security philosophy cornerstones Need to prevent security breaches from occurring Need to minimize the impact of a security breach Need to detect vulnerabilities and security breaches Need to react to vulnerabilities and security breaches swiftly

3 Android Security Architecture Security goals Protect user data Protect system resources (hardware, software) Provide application isolation Foundations of Android Security Application Isolation and Permission Requirement Mandatory application sandbox for all applications Secure inter-process communication (IPC) System-built and user-defined permissions Application signing

4 Android Software Stack

5 Android software stack Each component assumes all supporting components below are properly secured. All code above the Linux Kernel is restricted by the Application Sandbox Linux kernel is responsible for app sandboxing Sandboxing application mutually distrusting principals Default access to only its own data The app Sandbox apps can talk to other apps only via Intents (message), IPC, and ContentProvider and ContentResolver To escape sandbox, permissions is needed

6 1. Security at the Linux kernel A user-based permissions model Process isolation: Each application has its sandbox based on separation of processes: to protect user resources from each another; each runs in its own Linux process to secure Inter- Process communication (IPC) Ex: Prevents user A from reading user B's files Ensures that user A does not access user B's CPU, memory resources Ensures that user A does not access user B's devices (e.g. telephony, GPS, Bluetooth)

7 Application Sandbox The Android system assigns a unique user ID (UID) to each Android application and runs it as that user in a separate process. The developer of that application has ensured that it will not do anything the phone s user didn t intend Application A is not allowed to do something malicious like read application B's data or dial the phone without permission. All libraries, application runtime, and all applications run within the Application Sandbox in the kernel.

8 Permissions and Encryption Permissions In Android, each application runs as its own user. Unless the developer explicitly exposes files to other applications, files created by one application cannot be read or altered by another application. Password Protection Android can require a user-supplied password prior to providing access to a device. In addition to preventing unauthorized use of the device, this password protects the cryptographic key for full filesystem encryption.

9 Encryption Encryption Android 3.0+ provides full filesystem encryption, so all user data can be encrypted in the kernel The encryption key is protected by using a key derived from the user password, preventing unauthorized access to stored data without the user device password. For a lost or stolen device, full filesystem encryption on Android devices uses the device password to protect the encryption key, so modifying the bootloader or operating system is not sufficient to access user data without the user s device password.

10 2. Android Application Security Application framework Almost all Android applications are written in the Java and run in the Dalvik virtual machine. Android application deployed in.apk a single file. Android middleware is base on the Linux kernel. It provides several native libraries and a Dalvik virtual machine (DVM) instead of Java virtual machine (JVM) for its applications runtime environment where application isolations is enforced. The Java written Android middleware provides development APIs and the system service, all basic phone device functionalities

11 Configurations of Android applications The AndroidManifest.xml file is the configuration file of the Android application. It specifies the components in the application and external libraries it uses. It tells the system what to do with activities, services, broadcast receivers, and content providers in an application. It declares permissions it requests as well as permissions that are defined to protect its own components. The client must be granted such permission in order to run the application. Without user s consent application will not be installed

12 Android Permission Model Applications have no permissions by default Permissions list: Manifest.permission Applications declare the permissions they require Android system prompts the user for consent at the time the application is installed in AndroidManifest.xml, add one or more <uses-permission> tags e.g., <uses-permission android:name= "android.permission.receive_sms" /> granting permissions in the code

13 Android Permission Model Permissions are the core concepts in the Android security to control the access from one application component to another. All permissions are set at install time and can t change until the application is reinstalled. Android s permission only restricts components to access resources E.g. an application needs the READ_CONTACTS permission to read the user s address book If a public component doesn t explicitly declare any access permission, Android permits any application to access it.

14 Component A s ability to access components B and C is determined by comparing the access permission labels on B and C to the collection of labels assigned to application where A is in.

15 3. Secure coding in Android s Inter-Application If Sender does not correctly specify recipient Attacker can intercept the message A B If Component does not restrict from whom it can receive messages Attacker can inject code C

16 IPC - Intents Link applications and form the foundation of the message passing system Are messages containing a recipient and data (optional) Used for intra- and inter-app communication and system-wide notifications (system broadcast Intents) Are divided into explicit and implicit Explicit: specifies a definite application Implicit: specifies a kind or categories Are delivered to components

17 IPC - Components Activities Started with intents Can return data All UI is defined in an activity Services Started with intents Background; no UI Other components bind to Allows binder to invoke service s methods (must be declared in the interface) Broadcast receivers (3 types) Work on intents, which may be sent to multiple apps Background; no UI Normal sent to all registered receivers at once Ordered sent to receivers in order; any app can halt progression of message; apps can set their own priority level Sticky remain accessible after initial delivery; available to be re-broadcast to future (new) receivers Content providers Databases addressable by an URI Used for internal (app s own) data needs Can be used to share data between apps

18 IPC - Components Activities, Services, and Broadcast Receivers can send/receive Intents Intents (explicit & implicit) can Start Activities Start, stop, and bind Services Broadcast information to Broadcast Receivers To receive Intents, component must be declared in the manifest By default, components can only receive internal Intents

19 IPC Exporting Components Public components can receive Intents from other apps Is public (exported) if either: EXPORTED flag is set At least one Intent filter Intent can contain Component name, an action, data, a category, extra data Intent filter constrains incoming Intents by Action: a general operation to be performed Data: specifies the type of data Category: additional information about the action No rule against multiple applications specifying the same Intent filter Intent filters ARE NOT a security mechanism

20 IPC - Permissions Caller must have a certain permission Core system API does e.g., <uses-permission android:name="android.permission.call_phone" ></uses-permission> Can specify a protection level

21 IPC Protection Levels Normal Granted automatically Dangerous Granted during installation. If user does not accept, installation fails. Signature Granted only if requesting app is signed by the same developer that defined the permission Useful for restricting component access to those apps under the control of the same developer SignatureOrSystem Granted if meet the Signature requirement OR if installed in the system application folder Market apps cannot install into the system app folder Device manufacturers or end-users can manually install into the system app folder

22 Attacks Only consider attacks on exported components Consider non-exported components and exported components with a Signature (or higher) permission level to be private and not susceptible to the below attacks Type 1 - Intents sent to the wrong application Can leak data Broadcast theft, activity hijacking, and service hijacking Type 2 Receiving external Intents Data corruption, code injection Malicious broadcast injection, malicious activity launch, malicious service launch

23 Type 1 Broadcast Theft Broadcasts (via implicit Intent) vulnerable to eavesdropping and denial of service attacks Eavesdropping Risk when app sends public broadcast Can listen to all public broadcasts by creating a wide intent filter No user feedback to sender that broadcast has been read Denial of Service Ordered broadcast vulnerable Attacker sets priority to highest level Can cancel broadcast Can inject malicious code or data After all broadcast receivers receive the data, it is sent back to the initial sender Eve Alice Carol Bob Eavesdropping Eve Alice Carol Bob Denial of Service

24 Type 1 Activity Highjacking Malicious Activity launched in place of desired Activity Either used as an irritation or phishing If multiple Activities have the same Intent filter, then user is notified to select the correct Activity. If highjacking is successful, a False Response attack may then happen The attacker may return malicious code or data to the user Alice Activity/Service Highjacking Alice Eve Eve Bob Bob False Response

25 Type 1 Service Highjacking Malicious Service bound to in place of desired Service Can steal data, lie about tasks If multiple Services have the same Intent filter, Android selects one at random! If highjacking is successful, a False Response attack may then happen The attacker may return malicious code or data to the user Alice Activity/Service Highjacking Alice Eve Eve Bob Bob False Response

26 Type 2 Malicious Broadcast Injection Blindly trusts an incoming Broadcast Broadcast receivers most vulnerable when register to receive system actions, which makes the component public Can be explicitly called Will fall for malicious broadcast if Service doesn t check the Intent s action It should contain an action string that only the system can add Alice Intent Spoofing Eve

27 Type 2 Malicious Activity Launch Exported Activities can be launched by Intents (explicit or implicit) Launching an Activity can cause three types of attacks Affect state, modify data Trick the user into thinking they are changing settings in Malicious Activity, but are really changing settings in the victim Activity Leak information by returning a result to the malicious code Alice Intent Spoofing Eve

28 Type 3 Malicious Service Launch Exported Services can be started and bound to A malicious Service launch is similar to a malicious Activity lanuch Since Services relay on input data, there a greater chance to put the Service at risk Alice Intent Spoofing Eve

29 Some Recommendations Use caution with implicit Intents and exporting Components Use explicit Intents to send private data Use explicit Intents for internal communication Returned results should be checked for authenticity Avoid exporting Components The same Component should not handle both internal and external Intents Intent filters are not security measures

30 Android developers should securing user data and avoiding the introduction of security vulnerabilities. Always assign a least permision to a application Cost-Sensitive APIs A cost sensitive API is any function that might generate a cost for the user or the network. The Android platform has placed cost sensitive APIs in the list of protected APIs controlled by the OS. The user will have to grant explicit permission to thirdparty applications requesting use of cost sensitive APIs for SIM Card Access, Device Metadata, Sensitive Data via Input Devices or Personal Information These APIs include: Telephony SMS/MMS(Multimedia Message Service ) Network/Data In-App Billing

31 4. Application Signing Code signing allows developers to identify the author of the application and to update their application without creating complicated interfaces and permissions. Every application that is run on the Android must be signed by the developer. When an application (APK file) is installed onto an Android device, the Package Manager verifies that the APK has been properly signed with the certificate included in that APK. If the certificate (or, more accurately, the public key in the certificate) matches the key used to sign any other APK on the device, the new APK has the option to specify in the manifest that it will share a UID with the other similarly-signed APKs. Applications that attempt to install without being signed will rejected by either Google Play or the package installer on the Android device.

32 Android App Signature All Android applications must be signed, but are usually self-signed 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 proves no relationship with Google does not have central control over the app s signature certificates creates chain of trust between updates and among applications In signature schemes, the private key is used to sign a app or message; anyone can check the signature using the public key.

33 Android requires every application to be signed. The main purpose of application signing is to distinguish applications from one to another. Developers sign apps with their own private keys. The private keys are supposed to stay secret and known only to their owners. After a signed application is installed on the phone, the system is able to use its signature information to distinguish it from other application. Signature shows the authorship and trust for application All Android applications must be signed, but are self-signed

34 Signature

35 Cont. All.apk files must be signed with a certificate identifies the author of the application. does not need to be signed by a certificate authority allows the system to grant or deny applications access to signature-level permissions request to be given the same Linux identity as another application. If the public key matches the key used to sign any other APK, the new APK may request to share a UID with the other APK.

36 SMS Vulnerabilities SMS Short Messaging System Very commonly used protocol Used to send "Text Messages GSM (Global System for Mobile Communication) 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.

37 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