Introduction to Mobile Security Dominic Chen ddchen@cmu Carnegie

Introduction to Mobile Security Dominic Chen [email protected] Carnegie Mellon University

Goals What’s different about mobile security? – Non-homogeneous hardware architecture – Device capabilities – Attacker goals – Software ecosystems 2

Processor Architecture 3

Device Capabilities Connectivity – GPS – Cellular Network (GSM/CDMA) – WiFi – NFC Sensors – Accelerometer – Gyroscope – Ambient Light – Compass – Barometer – Fingerprint sensor Battery-powered 4

Malware Types 2.54% 1.98% 1.62% 0.59% 0.50% 0.64% 2.72% 3.44% 7.37% 57.08% 21.52% Trojan (SMS) RiskTool Adware Trojan Monitor Backdoor Trojan (Financial) Exploit HackTool Trojan (Downloader) Others 5

Software Ecosystem Resource-limited devices – Compute – Power Event-driven programming – No main() method – State transitions via callbacks Well-defined interfaces – Application lifecycle – Access to user data Centralized software distribution – Can only download applications from a single source – Vendor takes responsibility for filtering content 7

Overview Architectural complexity – New attack vectors Mobile operating systems – Operating system safety protections – Software development and distribution model Common problems with real-world software – Cryptographic misuse – Personal information leakage Current research techniques 8

Block Diagram (Nexus 5) 9

Block Diagram (Baseband) 10

Baseband Processor Separate processor or core that manages radio functionality (why?) Typically runs a proprietary real-time operating system – Apple iPhone: Nucleus RTOS, ThreadX – Qualcomm: Advanced Mobile Subscriber Software (AMSS/REX OS) L4A Pistachio microkernel 11

Boot Process 12

ARM TrustZone 13

ARM TrustZone Provides a separate hardware-enforced execution environment – x86 protection rings (0, 3) Applications – Digital rights management – Secure key storage – Mobile payments – Secure boot management (Q-Fuses) – Kernel integrity monitoring 14

ARM TrustZone Qualcomm Secure Execution Environment (QSEE) – Contains separate kernel with separate memory space – Has privileged access to all hardware and the non-secure world – Interfaces with the non-secure world via the privileged Secure Monitor Call (SMC) instruction 15

Case Studies Baseband Attacks: Remote Exploitation of Memory Corruptions in Cellular Protocol Stacks, Ralf-Philpp Weinmann (WOOT 2012) – Memory corruption in various baseband stacks led to injection/execution of arbitrary code Reflections on Trusting TrustZone, Dan Rosenberg (BlackHat 2014) – Integer overflow vulnerability led to arbitrary write of secure memory TrustNone, Sean Beaupre (11/28/15) – Signed comparison on unsigned user input led to arbitrary read/write of secure memory 16

Overview Architectural complexity – New attack vectors Mobile operating systems – Operating system safety protections – Software development and distribution model Common problems with real-world software – Cryptographic misuse – Personal information leakage Current research techniques 17

Introduction: Android Originally developed by startup in 2003 – Bought out by Google in 2005 – Publicly released in 2007 Mostly released under open source license – Proprietary device-specific drivers distributed in binary form – Access to Play Store and Google applications requires licensing agreement Fire OS, Baidu, Yandex.Store, etc 18

Version History 19

Security Model Utilizes a modified version of the Linux kernel – Changes are slowly being merged back upstream UNIX permission model for applications – Mandatory sandbox as separate users (distinct UID) Limited interface for inter-process communication Applications are cryptographically signed and verified 20

Architecture: Android 21

Safety Enhancements Android 1.5 – Stack overflow protection (-fstack-protector) – Safe integer operations (-lsafe iop) – Double free protection – Memory allocation integer overflow protection Android 2.3 – Format-string protections (-Wformat-security) – Data execution protection (DEP) – NULL pointer dereference protection (vm.mmap min addr) Android 4.0 – Address Space Layout Randomization (ASLR) 22

Safety Enhancements Android 4.1 – Position Independent Executables (PIE) – Read-only relocations (-Wl,-z,relro –Wl,-z,now) Android 5.0 – Default full disk encryption – Mandatory PIE – SELinux Android 6.0 – Verified boot – USB access control – Monthly security patches 23

Permission Model Capability-based access control model Categorized into various functional groups – Bluetooth – Camera – Location (fine/coarse-grained) – Network/data connection – SMS/MMS – Telephony User receives permission prompt at install-time – All-or-nothing 24

Permission Model 25

Permission Model 26

Permission Model Starting with Android 6.0 (Marshmallow), permissions are queried at run-time – Allows users to deny individual permissions – Was briefly available for Android 4.4.0 – 4.4.2 3rd party solutions – Xposed Framework (requires root) 27

Application Structure Written in Java – Interpreted by Dalvik bytecode virtual machine Uses just-in-time (JIT) techniques to compile native code – Replaced with Android Runtime (ART) in 5.0 Introduces ahead-of-time (AOT) compilation instead of JIT Can also call into native code – Uses Java Native Interface (JNI) to interface with C/C libraries 28

Application Structure Activity – Portions of the application’s user interface Login window, registration interface, etc. Service – Performs background processing Download a file, play music, etc. Broadcast Receiver – Handlers for global messages Boot completed, power disconnected, etc. Content Provider – Manages access to structured data User calendar, contacts, etc. 29

Case Studies Stagefright, Zimperium (2015) – Integer overflow vulnerabilities in system multimedia library leads to remote code execution Fixed in November monthly security patch Master Key, Bluebox Security (2013) – Structure of Android application packages allows manipulation of contents without invalidating digital signatures 30

Introduction: iOS Originally developed in 2005 – Publicly released in 2007 Based off of the Macintosh XNU kernel – Supports memory-protection features ASLR, DEP, etc. – UNIX-like 31

Security Model All applications must be signed by Apple – Unless system is jailbroken to remove checks Individual applications are encrypted and sandboxed from one another Code integrity is verified during execution – Makes injection of shellcode difficult 32

Architecture: iOS 33

Application Structure Written in Objective-C or Swift – Compiled by Clang/LLVM into native code – Adds automatic reference counting for garbage collection in Swift Transitioning to open source later this year Uses Model-View-Controller (MVC) design paradigm – Applications objects are model, view, or controller – Abstracts data from logic and presentation 34

Application Approvals Applications are typically submitted by developers to App Store for inclusion These undergo a review process for unwanted behavior or policy violations – Objectionable content – Game emulators – Internal API’s Techniques – Static analysis – Manual review 35

Enterprise Provisioning Enterprise developer certificates allow bypass of the App Store – Designed for deployment of internal applications to employees Historically, have also been used to bypass platform security – Game emulators – Jailbreaking – Malware 36

Case Studies XcodeGhost, Alibaba (2015) – Modified version of Xcode uploaded to a Chinese file sharing service inserted malicious code into binaries Pangu8, Pangu Team (2015) – Heap overflow in kernel battery gauge service for iOS 8 led to arbitrary writes of kernel memory limera1n, George Hotz (2010) – Heap overflow in bootloader USB protocol implementation led to arbitrary writes of memory 37

Overview Architectural complexity – New attack vectors Mobile operating systems – Operating system safety protections – Software development and distribution model Common problems with real-world software – Cryptographic misuse – Personal information leakage Current research techniques 38

Common Problems Developers are not experts in implementing or using cryptography – Tendency to copy-paste “template” code – Need to disable certain cryptographic features for ease of debugging Developers tend to inadvertently or maliciously request extraneous permissions – Can use user information for advertising or analytics 39

Cryptographic Misuse 1. Usage of ECB mode for encryption 2. Usage of static IV’s in CBC mode 3. Usage of hardcoded symmetric encryption keys 4. Usage of low iterations for password-based encryption 5. Bad seeding of random-number generators 40

Cryptographic Misuse CryptoLint, Manuel Egele et al. (CCS 2013) 1. Extract a control flow graph of an application 2. Identify calls to sensitive cryptographic API’s 3. Perform static backward slicing to evaluate security rules Allows for automatic detection of cryptographic misuse 41

Case Study 42

Password Manager (2010) private String encrypt(byte [] key, String clear) { byte [] encrypted; byte [] salt new byte[2]; . Random rnd new Random(); //Cipher cipher Cipher.getInstance("AES"); Cipher cipher Cipher.getInstance("AES/ECB/PKCS7Padding", "BC"); cipher.init(Cipher.ENCRYPT MODE, skeySpec); rnd.nextBytes(salt); cipher.update(salt); encrypted cipher.doFinal(clear.getBytes()); 43

Password Manager ( 6 days) private String encrypt(byte [] key, String clear) { byte [] encrypted; byte [] salt new byte[2]; . Random rnd new Random(); Cipher cipher Cipher.getInstance("AES/CBC/PKCS7Padding", "BC"); byte [] iv {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; IvParameterSpec ivSpec new IvParameterSpec(iv); cipher.init(Cipher.ENCRYPT MODE, skeySpec, ivSpec); rnd.nextBytes(salt); cipher.update(salt); encrypted cipher.doFinal(clear.getBytes()); 44

Password Manager ( 2yrs, 5mo) private String encrypt(byte [] key, String clear) { . Random rnd new Random(); Cipher cipher Cipher.getInstance("AES/CBC/PKCS7Padding", "BC"); byte [] iv new byte[16]; rnd.nextBytes(iv); IvParameterSpec ivSpec new IvParameterSpec(iv); cipher.init(Cipher.ENCRYPT MODE,skeySpec,ivSpec); encrypted cipher.doFinal(clear.getBytes()); . 45

Password Manager (key) public static byte [] hmacFromPassword(String password) { byte [] key null; . Mac hmac Mac.getInstance("HmacSHA256"); hmac.init (new SecretKeySpec ("notverysecretiv".getBytes("UTF-8"), "RAW")); hmac.update(password.getBytes("UTF-8")); key hmac.doFinal(); . return key; 46

Developer Education 47

48

Case Study TaintDroid, William Enck et al. (OSDI 2010) – Dataset of 30 randomly selected popular applications – Flagged 105 TCP connections for containing tainted privacy-sensitive information Leakage of device IMEI Leakage of device location 49

Overview Architectural complexity – New attack vectors Mobile operating systems – Operating system safety protections – Software development and distribution model Common problems with real-world software – Cryptographic misuse – Personal information leakage Current research techniques 50

Program Analysis Taint Analysis – Mechanism for identifying data flows in an application Concepts: – Basic Blocks – Control Flow Graphs – Call Graphs 51

Basic Block Sequence of instructions executed consecutively – Only the first instruction can be reached from outside the block – Only the last instruction may transition outside the block 52

Basic Block 1. x y 2. z t 3. x y z i z 4. z t i 5. jmp 1 6. jmp 3 3 basic blocks 53

Control Flow Graph Each vertex is a basic block There is an edge between two vertexes if there may be a transfer of control between the blocks Typically limited to a single function or procedure (intraprocedural) 54

Control Flow Graph a readline() x 0 if (a 5) { t “gt” x 42 } else { t “lte” x 7 } print(“input was ” t “ 5”) a readline(); x 0 if (a 5) t “gt” x 42 t “lte” x 7 print( ) 55

Call Graph Each node is a function There is an edge between nodes if a function calls another 56

Call Graph void orange() { green(); red(); } orange void red() { . } red void green() { green(); orange(); } green 57

Taint Analysis Technique or identifying movement of data in an application – Sources: Originations of privacy sensitive information, e.g. address book API – Sinks: Destinations of network communication, e.g. socket API Determine what flows occur between sources and sinks 58

Challenges Object-oriented languages encapsulate data as objects in memory – Callbacks and local functions are used to transfer data – Need to perform and propagate type recovery Class hierarchy – Determine relationships between parent and child classes – Identify overridden and virtual functions Handle dynamic object introspection – e.g. Reflection 59

Backward/Forward Slicing Identify all instructions that may influence a given variable – Program point – Variable Can be performed in both directions 60

Backward/Forward Slicing int main() { int x, y, z; x 5 2 * 6; y getchar(); z 8 10 % 3; y x z * 5; if (z 9) { x 2 * z 1; } else { x 4 * z - 1; } y 10 * y 3; return foo(x); } 61

Usage Identify sources of data that is used in cryptographic API’s – Constant values – Uninitialized data Identify sinks of data that originate from user data – Address book – Calendar – IMEI 62

Conclusion Architectural complexity – New attack vectors Mobile operating systems – Operating system safety protections – Software development and distribution model Common problems with real-world software – Cryptographic misuse – Personal information leakage Current research techniques 63

Questions? 64

END