Mobile Security

1. Mobile Security NSF Workshop on Mobile Security June 27, 2014

2. Pillars of Mobile Operating System (OS) Security • Traditional Access Control • Seek to protect devices using techniques such as passwords and idle-time screen locking. • Encryption • conceal data on the device to address device loss or theft. • Application Provenance • Stamp each application with identity of its author and made it tamper resistant (e.g., digital signature). A consumer/user can decide to use or not to use the application based on the identity of the author. • Application Security • limits applications ability to access sensitive data or systems on a device. • Permissions-based access control: grants set of permissions to each application

3. Traditional Access Control Apple iOS • iOS provides traditional access control security options which include password configuration options such as strength of passcode, maximum number of failed login attempts, password expiration, and password update frequency. Android • Android provides password configuration options, which are similar with iOS.

4. Effectiveness of Traditional Access Control Apple’s iOS • The access control feature of the iOS provides a reasonable level of security for the devices data in the event of loss or theft. • The iOS is comparable to traditional windows-based desktops in this scenario. Android • The password policy system is sufficient to protect devices against novice attacks.

5. Encryption Apple iOS • The iOS uses a hardware accelerated AES-256 encryption to encrypt all data stored in the flash memory of the device. • The iOS protects specific additional data items, such as email using an additional layer of encryption. • Within 10 seconds of the device locking, the decryption keys for files in device are discarded. Android • Earlier versions of android contain no encryption capability. A simple jailbreak of an android phone, or theft of device’s SD card can lead to significant loss of data. • Android 3.0+ provides full file system encryption using device password to protect the encryption key.

6. Application Provenance Apple iOS • Developers register with Apple company and pay annual license fees before releasing applications (apps) to users of iPhone, iPod, or iPad. • Developers are required to “digitally sign” each app with an apple-issued digital certificate before its release. This signing process prevents tampering of published apps and ties developers’ identity with assurance of their apps. • If an app is found malicious, the app is removed from the app store, but no automated mechanism has been implemented to remove theapp from devices. Android • Android OS only installs and runs apps that have been properly signed with a digital certificate. • Developers do not need not apply a digital certificate from Google and they can use self-generated certificates. • Malware can be distributed by authors using anonymous digital certificate, and Google has no way to track back to the author. • However, Google requires a $25 fee paid by credit card in order to put an app on Android market, which allows Google to associate the payee with the digital certificate, reducing changes of distribution of malicious apps. It assumes that they use their own credit card.

7. Effectiveness Application Provenance Apple iOS • Apple’s approach is effective as • The developer must register and pay to obtain a signing certificate from apple, which makes it easy to trace and identify if any malicious activities are performed. • Every application is tested before submission to the app store. • Apple’s code signing model prevents tampering with published apps. Android • Since no single authority evaluates or verifies all Android apps, attackers are more likely to release attacks without worrying of being caught.

8. Application (App) Security Apple iOS • iOS operating system isolates each app from other apps on the system. • The apps are not allowed to modify or view each other’s data, or even know existence of other apps. They cannot access the OS kernel, nor install privileged driver’s or obtain root level administrator access to the device. • The apps are also isolated from the phone’s SMS, emails and email attachments. Android • Like iOS, Android employs a strong isolation system. It not only isolates apps from each other but also prevents apps from accessing or modifying the OS kernel, ensuring the app doesn’t get admin control over a device.

9. Effectiveness of Application (App) Security Apple iOS • The iOS denies access under all circumstances to many of the device’s sensitive subsystems. • This increases the security of iOS based devices since it relieves the user from security decision-making process. • But it potentially limits the utility of certain classes of iOS apps. Android • The Android permission system relies on the user to make all policy decisions and decide whether an apps requested combination of permission is safe or not.

10. Examples of Isolation in Bring Your Own Devices (BYOD) Blackberry Balance • Allows organizations to create isolation between personal and work environments on a device. • Keeps personal applications, files and network separate from the work environment. • When Balance is enabled, workspace is automatically encrypted, leaving personal environment unencrypted. Windows Phone 8 - Unified Extensible Firmware Interface • It is used for secure boot so that devices do not load rooted or unauthorized system images. • The data between apps are shared in the cloud and not on the device.

11. Security Strength

12. Android Architecture Application provenance App security Permission-based access control Inter-process communication Process Isolation

13. Android Security Design Security goals • Protect user data • Protect system resources (hardware, software) Foundations  of  Android  Security     • Process and application Isolation by Linux Kernel • System-built and user-defined permissions • Secure inter-process communication • Application provenance

14. 1. Process Security from Linux Kernel • Each component assumes that the components below are properly secured. • Linux  kernel  is  responsible sandboxing application • Mutually distrusting principals • Default access to only its own data • Process isolation • All code above the Linux Kernel is restricted by the Application Sandbox • Each application is sandboxed to run on its own process • All libraries and applications run within their own sandboxes.

15. Android process isolation • The process isolation prevents process A from accessing process B’s CPU, memory resources, and devices such as telephony, GPS, and bluetooth. • The apps  can  only talk  to other  apps  through Intents (message) , Inter-process Communication, or ContentProviders (data storage). • To  escape the sandbox,  permissionsare needed.

16. 2. Android Application Security(Application framework) • Almost all Android applications are written in the Java and run in the Dalvik virtual machine. .java -> .class -> .jar -> .dex Android application deployed in a single .apkfile. • Permissions are the core concepts in the Android security to control the access from one application component to another. • The AndroidManifest.xml file is the configuration file of Android application. • It instructs system what to do with activities, services, broadcast receivers, and content providers in an application. • It declares permissions. • Without user’s consent, an application will not be installed.

17. AndroidManifest.xml • Each application can declare the required permissions • If a public component doesn’t explicitly declare any access permission, Android permits any application to access it. <?xml version="1.0" encoding="utf-8"?><manifest . . . >    <application . . . >        <activity android:name="com.example.project.myActivity"<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>

18. 3. Security for Inter-Process Communication • Core components of an application — activities, services, and broadcast receivers — can send/receive messages, called 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 AndroidManifest.xml

19. Intents • Intent: notification from one process to another • Implicit: can be received by anyone Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.example.com")); startActivity(intent); • Explicit: has one specific recipient and indicate exactly which activity class Intent intent = new Intent(this, ActivityABC.class); i.putExtra("Value", "This value for ActivityABC"); startActivity(intent);

20. Intent Filters • To inform the system which implicit intents they can handle, activities, services, and broadcast receivers can have one or more intent filters. • Each filter describes a capability of the component, a set of intents that the component is willing to receive. • It selects intents of a desired type, while filtering out unwanted intents

21. Security Risks in Android’s Inter-Process Communication • Type 1: If the sender does not correctly specify recipient (can send to anyone), attackers can intercept messages and lead to attacks such as Broadcast theft, activity and service hijacking. • Type 2: If a component does not restrict from whom it can receive messages (can receive from anyone), attacker can inject code. The attack can result in data corruption, code injection, malicious broadcast injection, malicious activity launch, malicious service launch.

22. Recommendations for Inter-Process Communication Use caution with implicit Intents Use explicit Intents to send private data Returned results should be checked for authenticity Always assign a least permission to a application Users have to grant explicit permission to third-party applications requesting use of cost sensitive APIs including Telephony, messaging, networking, in-app billing, etc.

23. 4. Application Provenance • Android requires every application to be signed with its developer’s private key. • It is self-signed. Why self signing? Market ties identity to developer account. • Therefore, no application is trusted. • After a signed application is installed on the phone, the system is able to use its signature information to distinguish it from other application.

24. 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.

25. Security threat #1 Trojan Horse Example (1) • Vicky, a top-level manager • A file Market on the new products release • John, subordinate of Vicky • A file called “Stolen” • An application with two hidden operations • Read operation on file Market • Write operation on file Stolen

26. Security threat #1 Trojan Horse Example (2) Trojan Code

27. Security threat #1 Trojan Horse Example (3) Trojan Code

28. Hands-on Lab #3 • Hide Trojan Horse in tic-tac-toe Game • Permissions • READ_CONTACTS • WRITE_CONTACTS • RECEIVE_BOOT_COMPLETED (The attack begins when the phone starts. ) • Attack actions • Read contacts from a phone • Delete all contact information

29. Security threat #2: Mobile Malware (1) Malicious logic Mobile Trojan 5556 5554

30. Security threat #2: Mobile Malware (2) Malicious logic Mobile Trojan 5554 sends a short MSG to 5556 Victim 5554 infected by Mobile Trojan

31. Security threat #2: Mobile Malware (3) Malicious logic Mobile Trojan Receiver of Victim replies to 5554 Nothing happened at Victim 5554

32. Security threat #2: Mobile Malware (4) Malicious logic • Mobile Malware Defense • use a "ContentObserver" to listen to any actions on the • internal database of Android.

33. Hands-on Lab #4 • Start two emulators • 5554:Test • 5556:Test2 • Infect 5554:Test • Send message to 5556:Test2 through victim 5554:Test

34. Security threat #3: Injection • Injection attacks trick an application into including unintended commands in the data send to an interpreter. • Interpreters • Interpret strings as commands. • Ex: SQL, shell (cmd.exe, bash), LDAP, XPath • Key Idea • Input data from the application is executed as code by the interpreter.

35. User ‘ or 1=1-- Pass Firewall DB Server Web Server Security threat #3: SQL Injection Attacker • App sends form to user. • Attacker submits form with SQL exploit data. • Application builds string with exploit data. • Application sends SQL query to DB. • DB executes query, including exploit, sends data back to application. • Application returns data to user. Form

36. Security threat #3: SQL Injection Example (1) Unauthorized Access Attempt: password =’ or 1=1 -- SQL statement becomes: select count(*) from users where username = ‘user’ and password = ‘’ or 1=1 -- Checks if password is empty OR 1=1, which is always true, permitting access.

37. Security threat #3: SQL Injection Example (2) User ID: ` OR ``=`` -- Password: abc Because anything after the -- will be ignored, the injection will work even without any specific injection into the password predicate.

38. SQL Injection Countermeasures: Prepared Queries (1) Example in Perl: $sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;"); $sth->execute($email); $emailis the data obtained from the user's form, and it is passed as positional parameter #1 (the first question mark), and at no point do the contents of this variable have anything to do with SQL statement parsing. Quotes, semicolons, backslashes, SQL comment notation - none of this has any impact, because it's "just data". There simply is nothing to subvert, so the application is be largely immune to SQL injection attacks. bound parameters, which are supported by essentially all database programming interfaces. In this technique, an SQL statement string is created with placeholders - a question mark for each parameter - and it’s compiled ("prepared", in SQL parlance) into an internal form. Later, this prepared query is "executed" with a list of parameters.

39. SQL Injection Countermeasures: Prepared Queries (2) Insecure version Statement s = connection.createStatement(); ResultSetrs = s.executeQuery("SELECT email FROM member WHERE name = " + formField); // *boom* Secure version PreparedStatementps = connection.prepareStatement( "SELECT email FROM member WHERE name = ?"); ps.setString(1, formField); ResultSetrs = ps.executeQuery(); There also may be some performance benefits if this prepared query is reused multiple times (it only has to be parsed once), but this is minor compared to the enormous security benefits. This is probably the single most important step one can take to secure a web application. bound parameters in Java

40. Hands-on #5 • Inject SQLite Database of Android • Attacks: • 1’ or ‘1’=‘1 • 1’ or username not null • Countermeasures String m_argv[] = {m_id}; cursor=db.rawQuery("SELECT * FROM usertable WHERE _id= ? ",m_argv );