Spring 2017 CS 155 Mobile Device and Platform

Spring 2017 CS 155 Mobile Device and Platform Security Part II John Mitchell

Guest Lecture Tuesday June 6 Diogo Mnica, Director of security at Docker Topics include container security and what it is like working as a security engineer Diogo a very good speaker. Please show your appreciating and come to class. We will include topics on the final exam

Two lectures on mobile security Introduction: platforms and trends Threat categories Physical, platform malware, malicious apps Defense against physical theft Malware threats System architecture and defenses

Tues Apple iOS security features and app security model Android security features and app security model Security app development WebView secure app and web interface dev

Device fragmentation Thurs ANDROID History and early decisions Android history

Android, Inc founded by Andy Rubin around 2005 Worked with HTC-built device with a physical keyboard Scrapped Blackberry-like phone when iPhone came out First Android phone HTC Dream, Oct 2008 (T-Mobile G1): touchscreen and keyboard Open-source software project Backed and acquired by Google

HTC Dream First phone had Android 1.6 (Donut) 3.15 megapixel rear camera with auto-focus 3.2 inch touchscreen Gmail, Google Maps,

Search, Google Talk, You Tube, calendar, contacts, alarm Android ecosystem Open-source software distributed by Google Increase number of users and devices linked to core Google products

Multiple hardware vendors Can customize software for their products Open marketplace for apps App market Self-signed apps

App permissions granted on user installation Open market Bad apps may show up on market Shifts focus from remote exploit to privilege escalation

ANDROID PLATFORM Device locking and permissions Device lock and unlock Similar PIN and fingerprint Fingerprint API lets users Unlock device

Securely sign in to apps Use Android Pay Purchase on Play Store Android permissions Example of permissions provided by Android android.permission.INTERNET android.permission.READ_EXTERNAL_STORAGE

android.permission.SEND_SMS android.permission.BLUETOOTH Also possible to define custom permissions Android permission model https://www.owasp.org/images/3/3e/Danelon_OWASP_EU_Tour_2013.pdf

ANDROID PLATFORM Platform security features Android Platform outline: Linux kernel, browser, SQL-lite database Software for secure network communication

Open SSL, Bouncy Castle crypto API and Java library C language infrastructure Java platform for running applications Dalvik bytecode, virtual machine Exploit prevention Open source: public review, no obscurity

Goals Prevent remote attacks, privilege escalation Secure drivers, media codecs, new and custom features Overflow prevention ProPolice stack protection First on the ARM architecture

Some heap overflow protections Chunk consolidation in DL malloc (from OpenBSD) ASLR Avoided in initial release Many pre-linked images for performance Later developed and contributed by Bojinov, Boneh

dlmalloc (Doug Lea) Stores meta data in band Heap consolidation attack Heap overflow can overwrite pointers to previous and next unconsolidated chunks Overwriting these pointers allows remote code execution

Change to improve security Check integrity of forward and backward pointers Simply check that back-forward-back = back, f-b-f=f Increases the difficulty of heap overflow ANDROID PLATFORM

App execution environment Application development concepts Activity one-user task Example: scroll through your inbox Email client comprises many activities Service Java daemon that runs in background

Example: application that streams an mp3 in background Intents asynchronous messaging system Fire an intent to switch from one activity to another Example: email app has inbox, compose activity, viewer activity User click on inbox entry fires an intent to the viewer activity, which then allows user to view that email

Content provider Store and share data using a relational database interface Broadcast receiver mailboxes for messages from other applications Security Features Isolation

Multi-user Linux operating system Each application normally runs as a different user Communication between applications May share same Linux user ID Access files from each other May share same Linux process and Dalvik VM

Communicate through application framework Intents, based on Binder, discussed in a few slides Battery life Developers must conserve power Applications store state so they can be stopped (to save power) and restarted helps with DoS

Application development process Application sandbox Application sandbox Each application runs with its UID in its own Dalvik virtual machine Provides CPU protection, memory protection Authenticated communication protection using Unix

domain sockets Only ping, zygote (spawn another process) run as root Applications announce permission requirement Create a whitelist model user grants access Dont interrupt user all questions asked as install time Inter-component communication reference monitor

checks permissions Android permission model https://www.owasp.org/images/3/3e/Danelon_OWASP_EU_Tour_2013.pdf Android Intents Msg between components in same or different app

Intent is a bundle of information, e.g., action to be taken data to act on

category of component to handle the intent instructions on how to launch a target activity Routing can be Explicit: delivered only to a specific receiver Implicit: all components that have registered to receive that action will get the message

Layers of security Each application executes as its own user identity Android middleware has reference monitor that mediates the establishment of inter-component communication (ICC) Source: Penn State group Android security paper Source: Penn State group, Android security tutorial

Security issues with intents Sender of an intent can verify that the recipient has a permission by specifying a permission with the method call Senders can use explicit intents to send the message to a single component (avoiding broadcasting)

Receivers have to handle malicious intents Attack: Permission redelegation Definition: an application without a permission gains additional privileges through another application Example of the confused deputy problem

Permission redelegation https://www.owasp.org/images/3/3e/Danelon_OWASP_EU_Tour_2013.pdf Permission redelegation https://www.owasp.org/images/3/3e/Danelon_OWASP_EU_Tour_2013.pdf

How could this happen? App w/ permissions exposes a public interface Study in 2011 Examine 872 apps 320 of these (37%) have permissions and at least one type of public component Construct attacks using 15 vulnerabilities in 5 apps

Reference Permission Re-Delegation: Attacks and Defenses, Adrienne Felt, Helen Wang, Alexander Moshchuk, Steven Hanna, Erika Chin, Usenix 2011 Example: power control widget Default widgets provided by Android, present on all devices

Can change Wi-fi, BT, GPS, Data Sync, Screen Brightness with only one click Uses Intent to communicate the event of switching settings A malicious app without permissions can send a fake Intent to the Power Control Widget, simulating click to switch settings https://www.owasp.org/images/3/3e/Danelon_OWASP_EU_Tour_2013.pdf

Vulnerable versions (in red) Principle of least privilege helps but is not a solution Apps with permissions need to manage security https://www.owasp.org/images/3/3e/Danelon_OWASP_EU_Tour_2013.pdf

Java Sandbox Four complementary mechanisms Class loader Separate namespaces for separate class loaders Associates protection domain with each class Verifier and JVM run-time tests NO unchecked casts or other type errors, NO array overflow

Preserves private, protected visibility levels Security Manager Called by library functions to decide if request is allowed Uses protection domain associated with code, user policy Stack Inspection Permission depends on

Permission of calling method Permission of all methods above it on stack Up to method that is trusted and asserts this trust method f

method g method h java.io.FileInputStream Stories: Netscape font / passwd bug; Shockwave plug-in Many details omitted here

ANDROID MALWARE . Android malware example Install malicious conference app Malware behavior triggered by C&C

server (Chuli) Chuli source-to-sink flows ANDROID WEB APPS . A Large-Scale Study of

Mobile Web App Security Patrick Mutchler, Adam Doupe, John Mitchell, Chris Kruegel, Giovanni Vigna Mobile Apps Mobile Apps

Mobile Apps Mobile Web Apps Mobile web app: embeds a fully functional web browser as a UI element JavaScript Bridge

Obj foo = new Object(); addJavascriptInterface(foo, f); Java JavaScript JavaScript Bridge

f.bar(); Java JavaScript Security Concerns Who can access the bridge? Everyone

Isolated in Browser No origin distinction in WebView f.bar(); Java JavaScript

Static Analysis How many mobile web apps? How many use JavaScript Bridge? How many vulnerable? Experimental Results 737,828 free apps from Google Play (Oct 13)

563,109 apps embed a browser 219,404 use the JavaScript Bridge 107,974 have at least one security violation Most significant vulnerabilities 1. Loading untrusted web content 2. Leaking URLs to foreign apps 3. Exposing state changing navigation to

foreign apps 1. Loading untrusted web content 2. Leaking URLs to foreign apps 3. Exposing state changing navigation to foreign apps You should restrict the web-pages that

can load inside your WebView with a whitelist. - Facebook only loading content from trusted sources into WebView will help protect users. - Adrian Ludwig, Google

1. Navigate to untrusted content // In app code myWebView.loadUrl(foo.com) ; // In app code

myWebView.load(foo.com); click! // In app code myWebView.load(foo.com); click!