mobile platform security models john mitchell cs 155 spring 2014
Post on 15-Dec-2015
218 Views
Preview:
TRANSCRIPT
2
Outline
Introduction: platforms and attacksApple iOS security modelAndroid security modelWindows 7, 8 Mobile security model
7
Mobile Operating Systems
Mobile OS Vulnerabilities Mobile OS Exploits
Source: IBM X-Force, Mar 2011
8
Two attack vectors
Web browser
Installed apps
Both increasing in prevalence and sophistication
source: https://www.mylookout.com/mobile-threat-report
9
Mobile malware attacks
Unique to phones: Premium SMS messages Identify location Record phone calls Log SMS
Similar to desktop/PCs: Connects to botmasters Steal data Phishing Malvertising
10
Mobile malware examples
DroidDream (Android) Over 58 apps uploaded to Google app market Conducts data theft; send credentials to attackers
Ikee (iOS) Worm capabilities (targeted default ssh pwd) Worked only on jailbroken phones with ssh installed
(could have been worse)
Zitmo (Symbian,BlackBerry,Windows,Android) Propagates via SMS; claims to install a “security
certificate” Captures info from SMS; aimed at defeating 2-factor auth Works with Zeus botnet; timed with user PC infection
11
Comparison between platforms
Operating system (recall security features from lecture 5) Unix Windows
Approval process for applications Market: Vendor controlled/Open App signing: Vendor-issued/self-signed User approval of permission
Programming language for applications Managed execution: Java, .Net Native execution: Objective C
12
Outline
Introduction: platforms and attacksApple iOS security modelAndroid security modelWindows 7 Mobile security model
14
iOS Platform
Kernel: based on Mach kernel like Mac OS XCore OS and Core Services: APIs for files, network, … includes SQLite, POSIX threads, UNIX socketsMedia layer: supports 2D and 3D drawing, audio, videoCocoa Touch: Foundation framework, OO support for collections, file management, network operations; UIKit
Implemented in C and Objective-C
15
iOS Application Development
Apps developed in Objective-C using Apple SDKEvent-handling model based on touch eventsFoundation and UIKit frameworks provide the key services used by all iOS applications
16
Apple iOS Security
Device security Prevent unauthorized use of the device
Data security Protect data at rest; device may be lost or
stolen
Network security Networking protocols and encryption of data
in transmission
App security Secure platform foundation
Reference: http://images.apple.com/iphone/business/docs/iOS_Security.pdf
17
Device Security: passcodes
Strong passcodesPasscode expirationPasscode reuse historyMaximum failed attemptsOver-the-air passcode enforcementProgressive passcode timeout
18
Data Security
Hardware encryptionRemote wipeLocal wipeEncrypted Configuration ProfilesEncrypted iTunes backups
19
Network Security
Current accepted network security protocols IPSec, L2TP, PPTP VPN SSL VPN via App Store apps SSL/TLS with X.509 certificates WPA/WPA2 Enterprise with 802.1X
20
App Security
Runtime protection System resources, kernel shielded from user apps App “sandbox” prevents access to other app’s
data Inter-app communication only through iOS APIs Code generation prevented
Mandatory code signing All apps must be signed using an Apple-issued
certificate
Application data protection Apps can take advantage of built-in hardware
encryption
21
Limit app’s access to files, preferences, network, other resourcesEach app has own sandbox directoryLimits consequences of attacksSame privileges for each app
iOS Sandbox
22
Comparison
iOS Android Windows
Unix x
Windows
Open market
Closed market x
Vendor signed x
Self-signed
User approval of permissions
Managed code
Native code x
23
Outline
Introduction: platforms and attacksApple iOS security modelAndroid security modelWindows 7, 8 Mobile security model
24
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 Also: video stuff, Bluetooth, vibrate phone,
etc.
26
Android market
Self-signed appsPermissions granted on user installationOpen Bad applications may show up on market Shifts focus from remote exploit to privilege
escalation
27
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
29
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
30
Exploit prevention
100 libraries + 500 million lines new code 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 Developed and contributed by Bojinov, Boneh
31
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 announces permission
requirement Create a whitelist model – user grants access
But don’t want to ask user often – all questions asked as install time
Inter-component communication reference monitor checks permissions
32
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
34
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
35
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
36
Comparison: iOS vs Android
App approval process Android apps from open app store iOS vendor-controlled store of vetted apps
Application permissions Android permission based on install-time
manifest All iOS apps have same set of “sandbox”
privileges
App programming language Android apps written in Java; no buffer
overflow… iOS apps written in Objective-C
See also: http://palisade.plynt.com/issues/2011Oct/android-vs-ios/
37
Comparison
iOS Android Windows
Unix x x
Windows
Open market x
Closed market x
Vendor signed x
Self-signed x
User approval of permissions
x
Managed code x
Native code x
38
Outline
Introduction: platforms and attacksApple iOS security modelAndroid security modelWindows Phone 7, 8 security model
39
Windows Phone 7, 8 security
Secure boot All binaries are signedDevice encryptionSecurity model with isolation, capabilities
Windows Phone 7 security model
Least Privilege Chamber
(LPC)
Trusted Computing Base (TCB)
Elevated Rights
Standard Rights
DynamicPermissions
(LPC)
FixedPermissions
ChamberTypes
Central repository of rules3-tuple {Principal, Right, Resource}
Chamber boundary is security boundaryChambers defined using policy rules4 chamber types, 3 fixed size, one can be expanded with capabilities (LPC)
Expressed in application manifestDisclosed on MarketplaceDefines app’s security boundary on phone
Policy system
Chamber Model
Capabilities
Windows Phone 8 security model
Least Privilege Chamber
(LPC)
Trusted Computing Base (TCB)
DynamicPermissions
(LPC)
Similar to WP7
WP8 chambers are built on the Windows security infrastructureServices and Application all in chambers
WP8 has a richer capabilities list
42
Windows Phone OS 7.0 security model
Principles of isolation and least privilegeEach chamber Provides a security and isolation boundary Is defined and implemented using a policy
system
The security policy of a chamber Specifies the OS capabilities that processes
in that chamber can access
43
Isolation
Every application runs in own isolated chamber All apps have basic permissions, incl a storage file Cannot access memory or data of other
applications, including the keyboard cache.
No communication channels between applications, except through the cloud Non-MS applications distributed via marketplace stopped in background When user switches apps, previous app is shut
down Reason: application cannot use critical resources or
communicate with Internet–based services while the user is not using the application
44
Four chamber types
Three types have fixed permission setsFourth chamber type is capabilities-driven Applications that are designated to run in
the fourth chamber type have capability requirements that are honored at installation and at run-time
45
Overview of four chambers
Trusted Computing Base (TCB) chamber unrestricted access to most resources can modify policy and enforce the security
model. kernel and kernel-mode drivers run in the
TCB Minimizing the amount of software that runs
in the TCB is essential for minimizing the Windows Phone 7, 8 attack surface
46
Overview of four chambers
Elevated Rights Chamber (ERC) Can access all resources except security
policy Intended for services and user-mode drivers
Standard Rights Chamber (SRC) Default for pre-installed applications that do
not provide device-wide services Outlook Mobile is an example that runs in
the SRC
Least Privileged Chamber (LPC) Default chamber for all non-Microsoft
applications LPCs configured using capabilities (see next
slide)
47
Granting privileges to applications
Goal: Least Privilege Application gets capabilities needed to perform all its
use cases, but no more
Developers Use the capability detection tool to create the capability
list The capability list is included in the application manifest
Each application discloses its capabilities to the user, Listed on Windows Phone Marketplace. Explicit prompt upon application purchase Disclosure within the application, when the user is
about to use the location capability for the first time.
50
.NET Code Access Security
Default Security Policy is part of the .NET Framework
Default permission for code access to protected resources
Permissions can limit access to system resources.
Use EnvironmentPermission class for environment variables access permission.
The constructor defines the level of permission (read, write,…)
Deny and Revert The Deny method of the permission class denies
access to the associated resource The RevertDeny method will cause the effects of any
previous Deny to be cancelled
51
Example: code requires permission
class NativeMethods{ // This is a call to unmanaged code. Executing this
method // requires the UnmanagedCode security permission.
Without // this permission, an attempt to call this method will
throw a // SecurityException: [DllImport("msvcrt.dll")] public static extern int puts(string str); [DllImport("msvcrt.dll")] internal static extern int _flushall();}
52
Example: Code denies permission not needed
[SecurityPermission(SecurityAction.Deny, Flags = SecurityPermissionFlag.UnmanagedCode)] private static void MethodToDoSomething() { try { Console.WriteLine(“ … "); SomeOtherClass.method(); } catch (SecurityException) { … } }
53
calls
.NET Stackwalk
Demand must be satisfied by all callers Ensures all code in causal chain is
authorized Cannot exploit other code with more
privilege
Code B
Code C Demand P
B has P?
A has P?
calls
Code A
54
Stackwalk: Assert
The Assert method can be used to limit the scope of the stack walk Processing overhead decreased May inadvertently result in weakened
security
55
Comparison between platforms
Operating system Unix Windows
Approval process for applications Market: Vendor controlled/Open App signing: Vendor-issued/self-signed User approval of permissions
Programming language for applications Managed execution: Java, .Net Native execution: Objective C
56
Comparison
iOS Android Windows
Unix x x
Windows x
Open market x
Closed market x x
Vendor signed x
Self-signed x x
User approval of permissions
x 7-> 8
Managed code x x
Native code x
top related