Understanding Android Security

1. Understanding Android Security MarioČagalj University of Split 2013/2014.

2. Introduction Application Security for the Android Platform by Jeff Six Android Security Underpinnings by Marko Gargenta Produced by Mario Čagalj

3. Why Should You Care? • As a developer you write mobile apps that • Allow people to access their social media accounts • Manage their email accounts and calendars in the cloud etc. • One day you read that personal details for thousands of users were compromised and posted online • Passwords, personal preferences, photos, etc. • Shortly after, you learn that a malicious Android app was looking for unsecured database instances, like the one used in your app • Who is to blame?Obviously you, the developer!

4. Why Should You Care? • Android app and poor use of the SSL/TLS protocol to protect transmitted data • Updated its virus signatures via a broken SSL connection (failed to verify hostnames) • Hackers were able to create a virus signature for the anti-virus app itself and sent it to the phone Why Eve and Mallory Love Android:An Analysis of Android SSL (In)Security by Fahl et al., ACM CCS’12

5. What is Security About? • Security is all about managing risk • Risk = Vulnerability + Threat + Consequences • Vulnerability – unintended and undesirable action • Threat – something/someone who can exploit a vulnerability • Consequences – incurred loss • Open mobile platforms imply a high risk • Malware, physical access to device (loss/theft), wireless comm. • Lots of personal data on mobile devices • Detailed profiling of end users (high economic incentives)

6. Your Role • As a developer you should be able to evaluate risk and act accordingly, i.e., implement secure (Android) apps • The very first step is to understand how Android works • You need to understand how your app will/will not interact with other apps and the Android system itself

7. Android Architecture

8. Android Software Stack Unlocking Android by Frank Ableson, Charlie Collins and Robi Sen

9. Android Security Framework • Android operating system security objectives • Protect user data • Protect system resources (including the network) • Provide application isolation • To achieve these objectives, Android provides the following security features • Robust security at the OS level through the Linux kernel • Application sandbox for all apps (application isolation) • Secure interprocess communication • Application signing • Application-defined and user-granted permissions

10. Linux Security Objectives • Linux kernel is the foundation of the Android platform • Linux is a multiuser operating system, with the main security objective to mutually isolate different users • Prevents user A from reading user B’s file • Ensures that user A does not exhaust user B’s memory/CPU resources • Central to Linux and Android security are concepts of • Discretionary Access Control (DAC) – used to isolate apps (Linux) • Mandatory Access Control (MAC) – used to mediate the establishment of inter-component/application communication (Android middleware)

11. Access Control Computer Security: Principles and Practice by William Stallings and Lawrie Brown Access Control: Principles and Practice by Ravi S. Sandhu and Pierangela Samarati Information Security and Trust: Access Control by Yingjiu Li Produced by Mario Čagalj

12. Access Control • Constraints what a user can do directly, as well as what programs executing on behalf of the users are allowed to do, with the goal to • Prevent activity that could lead to breach of security • Protect against accidental and malicious threats by regulating the reading, writing and execution of data and programs • Central element of computer security

13. Access Control (AC) Principles • AC is enforced by a reference monitor which mediates every attempted access by a user/process to system objects • Reference monitorconsults access rights/authorization database in to check if user is authorized for the requested operation Authorization database Security admin. Access control Authentication Objects Reference monitor User Auditing

14. Access Control Policies • Discretionary Access Control (DAC) • User-oriented security policy (based on identity of requestor) • Entity has rights to enable another entity to access a resource • Mandatory Access Control (MAC) • Access permissions are defined by a system itself (e.g. RECEIVE_SMS) • Based on comparing security labels of system resources with security clearances/permissions of entities accessing the resources • Cleared entity cannot pass on access rights to another entity • Other policies are outside of our scope

15. Access Control Elements • Subject – entity that can access objects • A process representing user/application • Object – access controlled resource • E.g. files, directories, records, processes, memory segments, pages, directory trees, mailboxes etc. • Access right – a way in which subject accesses an object • E.g. read, write, execute, delete, create, search

16. Discretionary Access Control (DAC)

17. Discretionary Access Control • User-oriented security policy (based on ID of requestor) • Discretionary because an owning entity has rights to enable another entity to access a resource • General approach as used in operating systems is that of an access matrix • Lists subjects in one dimension (rows) • Lists objects in the other dimension (columns) • Matrix entries specify access rights of subjects to objects

18. Access Matrix: Example Objects File 4 File 1 File 2 File 3 OwnReadWrite OwnReadWrite User A Access rights Read Write Read OwnReadWrite Subjects User B OwnReadWrite Read ReadWrite User C

19. Access Control Lists (ACL) • Used to efficiently store the access matrix File 1 File 4 File 4 File 1 File 2 File 3 OwnReadWrite OwnReadWrite User A Read Write Read OwnReadWrite File 2 User B OwnReadWrite Read ReadWrite User B User B User B User A User C User B User B User A User C User C OwnReadWrite ReadWrite Read OwnReadWrite Read Write OwnReadWrite Read OwnReadWrite File 3

20. Access Control Lists (ACL) • Access rights stored with objects • Linux and Windows use ACLs to protect files/processes

21. Linux Access Matrix: Example owner Objects Dir 2 File 1 File 2 Dir 1 rwx Access rights r – read file or directory w – write to file or directory x – execute file or search directory rwx rwx -wx user (u) r-- rwx rwx --- group (g) Subjects rw- --- rwx --- other (o)

22. Linux Discretionary Access Control • 3 types of users (subjects) • u – user who owns a file • g – group user (all the members of the group g) • o– all other users • 3 types of permissions (accessrights) • r– read file or directory • w – write to file or directory • x – execute file or search directory • Given a file (object), each of the 3 access rights can be set for any of 3 the types of usersby the file owner (u) • Almost everything in Linux is viewed as a file

23. Linux Discretionary Access Control /home/mcagalj$ ls -l -h total 468K -rw-r--r-- 1 mcagaljfesb 212K 2008-05-16 11:52 amrnb-6.1.0.1.tar.bz2 drwxr-xr-x 3 mcagaljfesb 4.0K 2011-02-03 16:24 bkup -rw------- 1 mcagaljfesb 542 2007-05-22 10:26 Drafts -rw-r--r-- 1 mcagaljfesb 0 2010-12-06 10:32 finger drwx------ 3 mcagaljfesb 4.0K 2012-12-04 21:37 mail drwx------ 1916 mcagaljfesb 228K 2011-11-05 22:35 Maildir drwxr-xr-x 2 mcagaljfesb 4.0K 2006-08-01 15:26 MailFolders drwxr-xr-x 34 mcagaljfesb 4.0K 2013-12-19 15:48 public_html

24. Linux Security Model • Each user in a Linux system is assigned a unique user ID (UID) and a group ID (GID) when they are created • Each user UID’sresource is assigned the same UID • process, file, directory, etc. /home/mcagalj$ id uid=10239(mcagalj) gid=201(fesb) groups=201(fesb) /home/mcagalj$ id uid=10239(mcagalj) gid=201(fesb) groups=201(fesb) /home/mcagalj$ps -o pid,ppid,args,uid -p 6822 PID PPID COMMAND UID 6822 6820 sshd: mcagalj@pts/1 10239

25. Linux Security Model • Each user UID’sresource is assigned the same UID, GID • process, file, directory, etc. user’s primary group /home/mcagalj$ id uid=10239(mcagalj) gid=201(fesb) groups=201(fesb) /home/mcagalj$ps -o pid,ppid,args,uid,euid,fsuid,gid -p 6822 PID PPID COMMAND UID EUID FSUID GID 6822 6820 sshd: mcagalj@pts/1 102391023910239201 /home/mcagalj$ ls -l -h total 468K drwx------ 3 mcagaljfesb 4.0K 2012-12-04 21:37 mail drwx------ 1916 mcagaljfesb 228K 2011-11-05 22:35 Maildir drwxr-xr-x 2 mcagaljfesb 4.0K 2006-08-01 15:26 MailFolders drwxr-xr-x 34 mcagaljfesb 4.0K 2013-12-19 15:48 public_html

26. Linux Security Model • Each User’sresource is assigned the same UID • process, file, directory, etc. • Every process running on a Linux system, executes on behalf of a given Userwho is identified by a unique UID • Thus, the process may do what this User is allowed to do • The process may access the Files that its User-owner may access • On each access by a user or process to a given resource, the Linux kernel enforces the access control policy based on the access rights and the requestor’s UID/GUID • The Linux kernel acts as a reference monitor

27. Android Application Isolation (Sandboxing)

28. Android Application Sandboxing • The application sandbox specifies which system resources the application is allow to access • On Android, sandboxing is enforced by the Linux kernel • Each application is isolated in its own sandbox • Each app is assigned a unique userID (UID) and runs as that user (UID) in a separate process • On Android each app is effectivelly a different user • Some exceptions are possible (e.g., android:sharedUserId) Linux kernel Linux process Dalvik VM Android app

29. Android Application Sandboxing • When an Android package is installed • A new user ID (UID) is created • All data stored by the app have the same UID (e.g., dir, files, DBs, etc.) <package name="com.example.hellofesb“ codePath="/data/app/HelloFESB.apk“ …userId="10051"> <sigs count="1"> <cert index="4" key="3082030d30820…37cf0aa3a31243230f4e48f"/> </sigs> </package> PackageManagerpackages.xml file root@generic_x86:/data/data # ll | grep 'fesb' drwxr-x--x u0_a51u0_a51 2014-01-15 03:26 com.example.hellofesb root@generic_x86:/data/data/com.example.hellofesb # ll drwxrwx--x u0_a51u0_a51 2014-01-15 03:26 cache drwxrwx--x u0_a51u0_a51 2014-01-15 03:26 files owner group

30. Android Application Sandboxing • When an Android package is installed • A new user ID (UID) is created • All data stored by the app have the same UID (e.g., dir, files, DBs, etc.) • The new app (the corresponding process) runs under the same UID <package name="com.example.hellofesb“ codePath="/data/app/HelloFESB.apk“ …userId="10051"> <sigs count="1"> <cert index="4" key="3082030d30820…37cf0aa3a31243230f4e48f"/> </sigs> </package> PackageManagerpackages.xml file root@generic_x86:/data/data/com.example.hellofesb # ps | grep 'fesb' u0_a51 1983 924 257736 31060 fffffff b76eff2b com.example.hellofesb owner

31. Android Application Sandboxing • By default, app cannot adversely affect other apps, processes • E.g. read/write user data, modify other apps'/system' files and settings, access network, keep the device awake, etc. userID (UID) The restrictions apply even to native code that runs outside of the Dalvik VM!

32. Demo: Android Filesystem Isolation …# ps | grep 'hellofesb' u0_a56 1889 … com.example.hellofesb …# ll -rw-rw---- u0_a56 … FESB.txt …# ps | grep 'hellofesb' u0_a56 1889 … com.example.hellofesb …# ll -rw-rw---- u0_a51 … FESB.txt

33. Benefits of Application Sandboxing • In 2008 the Web browser vulnerability discovered • By Charlie Miller, Mark Daniel, and Jake Honoroff of ISE • The first commercial Android phone, the T-Mobile G1 by HTC, shipped with the vulnerability • The impact:”...Upon visiting the malicious site, the attacker can run any code they wish with the privileges of the web browser application...The Android security architecture is very well constructed and the impact of this attack is somewhat limited by it. ... attacker will have access to any information the browser may use, such as cookies ... saved passwords, etc. ... However, [he] can not control other, unrelated aspects of the phone, such as dialing the phone directly. This is in contrast, for example, with Apple's iPhone which does not have this application sandboxing feature...” http://securityevaluators.com/knowledge/case_studies/android/index.php

34. Android Filesystem Isolation: Cautionary Note • Data written to external storage (such as SD cards) lacks Linux discretionary access control • Any file written to external storage is accessible by any app on the device (and by any other external device supporting such storage) • Consider encrypting such files/data

35. Playing Outside the Sandbox • Android provides permission system that restricts what apps can do if they want to play outside the sandbox • Apps statically declare permissions they need • The Android system prompts the user for consent at install-time • More on permissions in the next lecture… root@generic_x86:/ # pm list permissions -g group:android.permission-group.NETWORK … permission:android.permission.NFC permission:android.permission.CHANGE_WIFI_STATE permission:android.permission.ACCESS_WIFI_STATE permission:android.permission.INTERNET

36. Playing Outside the Sandbox • Apps can explicitly share resources/data via • ContentProviders, Intents, Inter-Process Communication (IPC), local network sockets, or the file system ICC – Inter-Component CommunicationDAC – Discretionary Access ControlMAC – Mandatory Access Control

37. Android Application Signing

38. Application Signing • All Android apps mustbe digitally signed prior to installation • The developer signs the corresponding *.apk file using his/her digital certificate (i.e., the corresponding private key) • Android uses the digital certificate as a means of • Identifying the developer of an application • Used to ensure the authenticity of future application updates (same origin policy) • Establishing trust relationships between applications • Applications signed with the same certificate can share, for example, the user ID (i.e., file system resources) and runtime process

39. Android Application Package File (APK) • APK is the file format used to distribute and install apps and middleware onto Android OS • APK files are ZIP archives based on JAR (Java ARchive format) • Bundle together compiled Android classes (.dex), metadata (in META-INF/ directory) and resources the code uses C:\FESB\teaching\2013_2014\AndroSec\code>aapt list HelloFESB.apk res/drawable/fesb_button.xml res/layout/activity_main.xml res/menu/main.xml AndroidManifest.xml resources.arsc res/drawable-hdpi/ic_launcher.png res/drawable-mdpi/ic_launcher.png res/drawable-xhdpi/ic_launcher.png res/drawable-xxhdpi/ic_launcher.png classes.dex META-INF/MANIFEST.MF META-INF/CERT.SF META-INF/CERT.RSA

40. APK Meta Information (META-INF/) • META-INF/ files hold necessary information (crypto hashes, certificate and signature) to verify the package integrity • The signing process is based oncryptographic hash functions (e.g., SHA1) and public-key cryptography C:\...\META-INF>more CERT.SF SHA1-Digest-Manifest: bFgRd0zf0ZHRZOr71smRiPIoo+I= Name: res/drawable-xhdpi/ic_launcher.png SHA1-Digest: iXOQFkCAFFovdXQunW5Lj2sge4k= Name: AndroidManifest.xml SHA1-Digest: SzwnLPA+WyeFvnDNHiognCbm7to= … Name: res/layout/activity_main.xml SHA1-Digest: /izaF34OgiteuhCmykT3c82WmQs= Name: classes.dex SHA1-Digest: tW37HMcEZ0S4daTE9i65fL5DoMk= C:\...\META-INF>more MANIFEST.MF Name: res/drawable-xhdpi/ic_launcher.png SHA1-Digest: vWrq4ApK74D3ktrs7+elAA8A1a8= Name: AndroidManifest.xml SHA1-Digest: zdtiD7i7BR8in+Iu1oE3Hv3GlnY= … Name: res/layout/activity_main.xml SHA1-Digest: cg8ZwPxIycCc6xS0P6DEjhCBusA= Name: classes.dex SHA1-Digest: IBvlm6sUhzUibItLsfEdRAnQ0zg=

41. APK Meta Information (META-INF/) • META-INF/ files hold necessary information (crypto hashes, certificate and signature) to verify the package integrity • The signing process is based oncryptographic hash functions (e.g., SHA1) and public-key cryptography C:\...\META-INF>keytool -printcert -file CERT.RSA Owner: CN=Android Debug, O=Android, C=US Issuer: CN=Android Debug, O=Android, C=US Serial number: 33ac9dfa Valid from: Thu Jan 09 16:41:38 CET 2014 until: Sat Jan 02 16:41:38 CET 2044 Certificate fingerprints: MD5: A3:12:E2:09:D7:AF:88:AC:6F:0A:BF:C8:79:82:4A:86 SHA1: 95:1C:B1:D0:4E:3D:57:FA:89:39:54:27:35:DC:25:53:8B:62:24:D0 SHA256: A3:32:FB:6F:4D:37:5D:A3: ... :07:26:03:6C:EA:91:06:FC:9D Signature algorithm name: SHA256withRSA Version: 3

42. Cryptographic Hash Functions andPublic-Key Cryptography

43. Secure (Cryptographic) Hash Functions • A hash function accepts a variable-size input message m and produces a fixed-size message digest (a hash value) ... Message m of a variable length ... Hash function hm = H(m) Hash value/message digest/hash code (fixed length)

44. Secure (Cryptographic) Hash Functions • A hash function accepts a variable-size input message m and produces a fixed-size message digest (a hash value) C:\...\META-INF>openssl sha1 -binary ..\AndroidManifest.xml | openssl base64 zdtiD7i7BR8in+Iu1oE3Hv3GlnY= C:\...\META-INF>openssl sha1 -binary ..\AndroidManifest_MODIFIED.xml | opens sl base64 7FK0VT/21ki6OMw+WPYBLunahI0= C:\...\META-INF>more MANIFEST.MF … Name: AndroidManifest.xml SHA1-Digest: zdtiD7i7BR8in+Iu1oE3Hv3GlnY= …

45. Hash Function Requirements • Hash functions produce a unique fingerprint of a message m • Easy to generate a hash value for any input message m • One-way property • Given hash value h, computationally infeasible to find m such that H(m) = h • Virtually impossible to find a message given the hash code/value • Weak-collision resistance • Given m, it is practically impossible to find msuch thatH(m) = H(m) • Strong-collision resistance • Practically impossible to find a pair (m, m)such thatH(m) = H(m)

46. Authentication with a Hash Function • An example of the use of a hash function to authenticate a given message m Destination Source H m m ll Compare E H D E[K, H(m)] Hash function K K Encryption algorithm Decryption algorithm

47. Hash Functions • Given the properties, a hash value (message digest) can prove both source and message integrity • SHA is the most widely used hash algorithm • SHA-1 gives 160-bit hash value (some attacks discovered recently) • SHA-256, SHA-384, SHA-512 provide improved size and security • Other hash functions MD2, MD4 (not in use) and MD5 (insecure, but still in use)

48. Some Applications of Hash Functions • Password hashing • Store a password hash value instead of the password itself • Attacker cannot invert the hash function (one-way property) • Ensuring integrity of a piece of software (Android) • Efficient digital signatures • Digital currency (Bitcoins)

49. Public-Key vs. Symmetric Encryption • Symmetric key encryption KEnc = KDec • Public-key encryption KEnc ≠ KDec Ciphertext Plaintext Plaintext Encryption Decryption Message Channel Key Channel KEnc KDec Key Generation

50. Public-Key Encryption • Public-key cryptography is asymmetric • Involves the use of two separate keys (symmetric only one) • Public key (all have access to it) and private key (only known by the owner) • If one key is used for encryption, the other one is used for decryption (both keys can be used for both encryption and decryption)