Android Security Dan Lo Facts 6 88 billion

Android Security Dan Lo

Facts • • 6. 88 billion people 1. 48 billion Internet enabled PCs 4. 10 billion mobile phones Mobile phone replacement rate o 12 -18 month average o 1. 1 billion mobile phones are purchased per year o 13. 5% of mobile phone sales are smartphones • The number of smartphones will soon compare with the number of Internet enabled PCs [1] [2] [1] [3] [4] [5] [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/ITUD/icteye/Reporting/Show. Report. Frame. aspx? Report. Name=/WTI/Information. Technology. Public&RP_int. Year=2008&RP_int. Language. ID=1 [3] [4] http: //www. infonetics. com/pr/2009/2 h 08 -mobile-wifi-phones-market-research-highlights. asp [5] http: //www. gartner. com/it/page. jsp? id=985912

2016 Top Ten Mobile Threats 1. Improper Platform Usage • 2. Android intent, platform permissions, misuse of Touch. ID Insecure Data Storage • 3. Insecure data storage and unintended data leakage Insecure Communication • 4. Poor handshaking, incorrect SSL versions, etc. Insecure Authentication • 5. Failing to identify the user at all when that should be required Insufficient Cryptography • 6. Cryptography was attempted, but it wasn't done correctly Insecure Authorization • 7. failures in authorization (e. g. , authorization decisions in the client side) Client Code Quality • 8. catch-all for code-level implementation problems in the mobile client Code Tampering • 9. binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification Reverse Engineering • 10. Software such as IDA Pro gives he attacker insight into the inner workings of the application. Extraneous Functionality • developers include hidden backdoor functionality

Android Software Stack

Android software stack • Each component assumes that the components below are properly secured. • All code above the Linux Kernel is restricted by the Application Sandbox • Linux kernel is responsible 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 Content. Providers • To escape sandbox, permissions is needed

Camera Architecture

Example Email Application

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)

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. • When launching a new Activity, the new process isn’t going to run as the launcher but with its own identity with the permission specified by the developer. • The developer of that application has ensured that it will not do anything the phone’s user didn’t intend. Any program can ask Activity Manager to launch almost any other application, which runs with that application’s UID. • Ex. application A is not allowed to do something malicious like to 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.

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 file system encryption.

Encryption • Encryption Android 3. 0+ provides full filesystem encryption, so all user data can be encrypted in the kernel • 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.

Android Application Security (Application framework) • Almost all Android applications are written in the Java and run in the Dalvik virtual machine. However, applications can also be written in native code. . java ->. class ->. jar ->. dex Android application deployed in a single. apk file. • Android middleware is based 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 isolation is enforced. • The Java written Android middleware provides development APIs, the system service, all basic phone device functionalities

Configurations of Android applications • The Android. Manifest. xml file is the configuration file of 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

Android Security Basics - Android Manifest • Applications have no permission required by default • Each application can declare the requi. RED permissions <? xml version="1. 0" encoding="utf-8"? > <manifest. . . > <application. . . > <activity android: name="com. example. project. my. Activity" <intent-filter> <action android: name="android. intent. action. MAIN" /> <category android: name="android. intent. category. LAUNCHER" /> </intent-filter>. . . </activity> <activity> …. . </activity> <uses-permission android: name="android. permission. SEND_SMS" /> <uses-permission android: name="android. permission. INTERNET" />. . . </application> </manifest>

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 installation time and can’t change until the application is reinstalled. • Android’s permission only restricts components from accessing 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.

Built-in Permission • Default Android Permissions Policy: No app can do anything to adversely Install/uninstall/modify other apps, use other apps private components, access network, users data (contacts, SMS, email), use cost sensitive APIs (phone calls, send SMS, …) • Built-in Android Permissions CALL_PHONE, CAMERA, INTERNET, READ_CONTACTS, READ_LOGS, READ_SMS, RECEIVE_SMS, R SEND_SMS, WRITE_SMS • Caller must have a certain permission • e. g. , <uses-permission android: name="android. permission. CALL_PHONE"> </uses-permission>

Signature • Decided by the system without the users’ involvement. To be granted a signature permission, the requesting application must be signed by the same key as the application that the permission protects. • 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 Signature. Or. System Granted if requesting app meets the Signature requirement OR if app is installed in the system application folder

Security for Inter-Process Communication In addition to any Linux-type process communication mechanisms such as file system, local sockets, signals Android provides new IPC mechanisms: Binder Remote procedure call( RPC) mechanism (Remote method invocation) designed for in-process and cross-process calls. https: //developer. android. com/reference/android/os/Binder. html. Secured by caller permission or identity check.

Cont. • AIDL (Android Interface Definition Language) is an IDL language used to generate code that enables two processes on an Android-powered device to talk using inter-process communication (IPC). • Ex. an Activity needs to call methods on an object in another process (for example, a service), you would use AIDL to generate code to marshall the parameters. • The AIDL IPC mechanism is interface-based, similar to COM or CORBA, but lighter weight. It uses a proxy class to pass values between the components

Intents • An Intent is a simple notification message object that represents an "intention" to do something. • It is serialized when it is sent. The message consists of the data together with the action operation that will be performed. • Intent filters are used to filter out unwanted intents so that users are informed by interested ones only. • For example, if your application wants to display a web page, it expresses its "Intent" to view the URL by creating an Intent instance and handing it off to the system. The system locates the Browser that knows how to handle that Intent, and runs it; or to broadcast interesting events (such as a notification) system-wide.

Cont. Intent: notification from one process to another directed intent: has one specific recipient broadcast intent: can be received by anyone intent filter: a list of intents an activity/service is interested in for example, a application wants to make a phone call: Intent my. Call. Intent = new Intent(Intent. Action_CALL); my. Call. Intent. set. Data(Uri. parse(“tel: 123456789”); start. Activity(my. Call. Intent); • •

Cont. • “Three of the core components of an application — activities, services, and broadcast receivers — are activated through messages, called intents. Intent messaging is a facility for late run-time binding between components in the same or different applications. ” • “The Android system finds the appropriate activity, service, or set of broadcast receivers to respond to the intent, instantiating them if necessary”.

Security Risks in Android’s Inter-Application • Attacker can intercept the message If sender does not correctly specify recipient, can hijack activity, service, broadcast via intent to lead to a malicious target • Attacker can inject code If Component does not restrict from whom it can receive messages

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 and service hijacking • Type 2 – Receiving external Intents • Data corruption, code injection • Malicious broadcast injection, malicious activity launch, malicious service launch

Type 1 – Broadcast Theft • Broadcasts (via implicit Intent) vulnerable to eavesdropping and denial of service attacks • Eavesdropping • A public broadcast can be intercepted by attacker because a loose intent filter leaves a hole and no confirmation checking

• Denial of Service • Ordered broadcast vulnerable • Attacker resets its priority to highest level to alter the broadcast receiving order which cancer or inject malicious code or data

Type 1 – Activity and Service Highjacking • Malicious a/service is activated instead of desired components such as by Phishing • Android will select a best matched one If multiple activities have the same Intent filter spec so that The attacker may return malicious code or data to the user

Type 2 – Malicious Injection Activity • A malicious activities can be activated by Intents (explicit or implicit) as results of injection • tamper data or Leak sensitive information Broadcast • Broadcast receivers registers with a malicious broadcast provider and take system action to make itself open to public • An system action string that only the system can add may be injected

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

Android developers should securing user data and avoiding the introduction of security vulnerabilities. Always assign a least permission 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 • Network/Data • In-App Billing

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. • Applications that attempt to install without being signed will rejected by either Google Play or the package installer on the Android device.

• On Android, application signing is the first step to placing an application in its Application Sandbox. The signed application certificate defines which user id is associated with which application; different applications run under different user IDs. • Application signing ensures that one application cannot access any other application except through well-defined IPC. • 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.

• 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 protection level • Signature shows app persistence: Check: app is changed or updated with diff sig. • Signature shows the authorship and trust for application • All Android applications must be signed, but are self-signed • Why self signing? Market ties identity to developer account • No applications are trusted.

Android App Signature • What does signing determine? • Shared UID for shared keys • Self-updates Google doest 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.

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.

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.

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, bluesnarfing

Information Misuse by Apps • Phone identifiers: phone number, IMEI (device identifier), IMSI (subscriber identifier), and ICC-ID (SIM card serial number). • Phone identifiers are frequently leaked through plaintext requests. • Phone identifiers are used as device ﬁngerprints. • Phone identifiers, specially the IMEI, are used to track individual users. • Phone identifiers are sent to advertisement and analytics servers.

Reference • Android Security, CEG 436: Mobile Computing • Prabhaker Mateti • Android Security Overview, source. android. com/tech/security/ • Nils, “Building Android Sandcastles in Android’s Sandbox, ” Oct 2010, Black. Hat • William Enck, Damien Octeau, Patrick Mc. Daniel, and Swarat Chaudhuri, “A Study of Android Application Security”, 20 th USENIX Security, Aug 2011 • Android Security Overview http: //source. android. com/tech/security/index. html • “Analyzing Inter-Application Communication in Android” by Chin, Felt, Greenwood, and Wagner (UC Berkeley) • http: //www. comdroid. org/ • Donald E Frederick, Android’s Inter-Application Model and Security Risks, 8/20/2012