Mobile Device Security

Adam C. Champion and Dong Xuan CSE 4471: Information Security

Based on materials from Tom Eston (SecureState), Apple, Android Open Source Project, and William Enck (NCSU)

Organization

•  Quick Overview of Mobile Devices •  Mobile Threats and Attacks •  Countermeasures

Overview of Mobile Devices •  Mobile computers:

–  Mainly smartphones, tablets –  Sensors: GPS, camera,

accelerometer, etc. –  Computation: powerful

CPUs (≥ 1 GHz, multi-core) –  Communication: cellular/4G,

Wi-Fi, near field communication (NFC), etc.

•  Many connect to cellular networks: billing system

•  Cisco: 7 billion mobile devices will have been sold by 2012 [1]

Organization

Organization

•  Quick Overview of Mobile Devices •  Mobile Threats and Attacks •  Countermeasures

Mobile Threats and Attacks •  Mobile devices make attractive targets: –  People store much personal info on them: email,

calendars, contacts, pictures, etc. –  Sensitive organizational info too… – Can fit in pockets, easily lost/stolen – Built-in billing system: SMS/MMS (mobile operator),

in-app purchases (credit card), etc. •  Many new devices have near field communications (NFC),

used for contactless payments, etc. •  Your device becomes your credit card

–  Location privacy issues •  NFC-based billing system vulnerabilities

Mobile Device Loss/Theft

•  Many mobile devices lost, stolen each year –  113 mobile phones lost/stolen every minute in the U.S.

[15] –  56% of us misplace our mobile phone or laptop each

month [15] – Lookout Security found $2.5 billion worth of phones

in 2011 via its Android app [16] –  Symantec placed 50 “lost” smartphones throughout

U.S. cities [17] •  96% were accessed by finders •  80% of finders tried to access “sensitive” data on phone

Device Malware

•  iOS malware: very little •  Juniper Networks: Major increase in Android

malware from 2010 to 2011 [18] •  Android malware growth keeps increasing ($$$) •  Main categories: [19] – Trojans – Monitoring apps/spyware – Adware – Botnets

•  We’ll look at notable malware examples

Device Search and Seizure

•  People v. Diaz: if you’re arrested, police can search your mobile device without warrant [26] – Rationale: prevent perpetrators destroying evidence – Quite easy to break the law (overcriminalization) [27] •  Crime severity: murder, treason, etc. vs. unpaid citations •  “Tens of thousands” of offenses on the books [26]

– Easy for law enforcement to extract data from mobile devices (forensics) [28]

Location Disclosure

•  MAC, Bluetooth Addresses, IMEI, IMSI etc. are globally unique

•  Infrastructure based mobile communication •  Peer-t-Peer ad hoc mobile communication

Organization

•  Quick Overview of Mobile Devices •  Mobile Threats and Attacks •  Countermeasures

Mobile Access Control •  Very easy for attacker to control a mobile device

if he/she has physical access – Especially if there’s no way to authenticate user – Then device can join botnet, send SMS spam, etc.

•  Need access controls for mobile devices – Authentication, authorization, accountability – Authentication workflow:

•  Request access •  Supplication (user provides identity, e.g., John Smith) •  Authentication (system determines user is John) •  Authorization (system determines what John can/cannot do)

Authentication: Categories

•  Authentication generally based on: –  Something supplicant knows

•  Password/passphrase •  Unlock pattern

–  Something supplicant has •  Magnetic key card •  Smart card •  Token device

–  Something supplicant is •  Fingerprint •  Retina scan

Authentication: Passwords

•  Cheapest, easiest form of authentication •  Works well with most applications •  Also the weakest form of access control – Lazy users’ passwords: 1234, password, letmein, etc. – Can be defeated using dictionary, brute force attacks

•  Requires administrative controls to be effective – Minimum length/complexity –  Password aging – Limit failed attempts

Authentication: Smart Cards/ Security Tokens

•  More expensive, harder to implement •  Vulnerability: prone to loss or theft •  Very strong when combined with another form

of authentication, e.g., a password •  Does not work well in all applications – Try carrying a smart card in addition to a mobile

device!

Authentication: Biometrics

•  More expensive/harder to implement •  Prone to error: – False negatives: not authenticate authorized user – False positives: authenticate unauthorized user

•  Strong authentication when it works •  Does not work well in all applications – Fingerprint readers becoming more common on

mobile devices (Atrix 4G)

Authentication: Pattern Lock •  Swipe path of length

4–9 on 3 x 3 grid •  Easy to use, suitable for

mobile devices •  Problems: [30]

–  389,112 possible patterns; (456,976 possible patterns for 4-char case-insensitive alphabetic password!)

–  Attacker can see pattern from finger oils on screen

Authentication: Comparison

Passwords Smart Cards Biometrics Pattern Lock Security Weak Strong Strong Weak Ease of Use Easy Medium Hard Easy Implementation Easy Hard Hard Easy Works for phones Yes No Possible Yes

– Deeper problem: mobile devices are designed with single-user assumption…

DiffUser (1) •  Current smartphone access

control focus: 1 user (admin) •  Hard to achieve fine-grained

mobile device management: –  Control app installation/gaming –  Parental controls –  Lend phone to friend

•  We design DiffUser, differentiated user access control model [31] –  Different users use smartphone

in different contexts –  User classification: admin,

“normal,” guest

Smartphone Privileges Admin Normal Guest

Personal Info

SMS ✔ ✔ ✘

Contacts ✔ ✔ ✘

Resource Access

WiFi ✔ ✔ Limit‼

GPS ✔ ✔ Limit‼

Bluetooth ✔ ✔ Limit‼

Apps

App Install ✔ Limit ✘

Sensitive Apps ✔ Limit ✘

Source: [31], Table 1.

DiffUser (2)

•  Implement our system on Android using Java •  Override Android’s “Home” Activity for multi-user

authentication, profile configuration

module checks different user profiles to control their accessrights.

We apply a capability-based access control model toDiffUser instead of access control lists (ACLs) for thefollowing reasons:

– ACLs are unsuitable for mobile phones. While ACLsare suitable for desktop OSes due to their file permissionsystems, e.g., NTFS, ext3, etc., mobile phone OSes eitherprovide no such permission systems or they use abstractionlayers for data and applications that hide file permissionsfrom end users. For examples, Symbian OS and WindowsMobile do not support file access control. In addition, thoughAndroid has a Linux-based file system with native filepermissions, these have no effect on the end user’s experi-ence. Android’s built-in application files are encapsulated as.apk files that are stored in the /system/app directoryand owned by root. Other applications are saved in the/data/app directory and owned by the system user.None of these is related to end users and they cannot bemapped to different uids as in traditional UNIX/Linuxsystems. Moreover, some data are saved in SQLite [12]database files and Android’s database implementation onlydifferentiates among applications.

– Smartphones usually have few users, so it is easier tomaintain user profiles as opposed to ACLs.

4.2. Prototype Implementation on Android

In this section, we present our Android prototype im-plementation. First, we describe the end-user interface andcorresponding model. Second, we discuss the access con-trol implementation based on Android’s built-in permissionmechanism. Finally, we analyze the relationship betweenpermissions and differentiated user profiles.

Android is the first free, open source, and fully cus-tomizable mobile platform. It offers a full software stackconsisting of an operating system, middleware, and keymobile applications as well as a rich set of APIs that allowthird-party developers to develop applications. It is based onthe Linux kernel and the system is divided into four layers:the kernel, libraries and runtime, application framework, andapplications. Different layers are implemented in differentlanguages. For example, Android’s system services such asdrivers and inter-process communication are written in C orC++, while all platform-related applications and services arewritten in Java and executed by the Dalvik virtual machine.Android’s advantage lies in its open source licensing andextensive programming documentation. The Android SDKprovides the tools and APIs necessary to develop applica-tions on the Android platform using Java.

Our prototype is implemented in Java with AndroidSDK 1.0. The development environment is Eclipse 3.1 withGoogle’s Android Developer Tools plugin. The debug toolsare Dalvik Debug Monitor Service (ddms), which manages

(a) (b)

(c)

Figure 2. A set of three interfaces: (a) Normal UserHome; (b) Login/Authentication ; and (c) User profileConfiguration

processes on the Android emulator or smartphone, and An-droid Debug Bridge (adb), which provides a command-lineinterface to programmers. The source code for our prototypeis about 72.3KB. As Android programs require configura-tion profiles and resources, which are another 225KB, theinstalled file on the phone is a 216KB Home.apk file.

Screenshots of the user interface are given in Figure 2.We load different applications according to users’ profiles.Our prototype includes a login Activity, a user profile con-figuration Activity and a main Home Activity. An Activityis the presentation layer of an Android application screen;its “lifecycle” has four stages—start, pause, resume, andterminate. An Activity provides event handling methods foreach of these stages that can be overridden. The user needsto authenticate himself at the login screen to obtain ad-ministrative privileges, including modifying system settings.The user configuration Activity provides the interface todetermine user access rights to SMS, contacts and GPS.These rights are stored in user profiles. We reprogram An-droid’s native Home Activity. After the system starts up, theHome Activity invokes the method loadapplication()to obtain information about all applications installed on thesystem, including related permissions, that is provided bythe system service PackageManagerService. We add

module checks different user profiles to control their accessrights.

We apply a capability-based access control model toDiffUser instead of access control lists (ACLs) for thefollowing reasons:

– ACLs are unsuitable for mobile phones. While ACLsare suitable for desktop OSes due to their file permissionsystems, e.g., NTFS, ext3, etc., mobile phone OSes eitherprovide no such permission systems or they use abstractionlayers for data and applications that hide file permissionsfrom end users. For examples, Symbian OS and WindowsMobile do not support file access control. In addition, thoughAndroid has a Linux-based file system with native filepermissions, these have no effect on the end user’s experi-ence. Android’s built-in application files are encapsulated as.apk files that are stored in the /system/app directoryand owned by root. Other applications are saved in the/data/app directory and owned by the system user.None of these is related to end users and they cannot bemapped to different uids as in traditional UNIX/Linuxsystems. Moreover, some data are saved in SQLite [12]database files and Android’s database implementation onlydifferentiates among applications.

– Smartphones usually have few users, so it is easier tomaintain user profiles as opposed to ACLs.

4.2. Prototype Implementation on Android

In this section, we present our Android prototype im-plementation. First, we describe the end-user interface andcorresponding model. Second, we discuss the access con-trol implementation based on Android’s built-in permissionmechanism. Finally, we analyze the relationship betweenpermissions and differentiated user profiles.

Android is the first free, open source, and fully cus-tomizable mobile platform. It offers a full software stackconsisting of an operating system, middleware, and keymobile applications as well as a rich set of APIs that allowthird-party developers to develop applications. It is based onthe Linux kernel and the system is divided into four layers:the kernel, libraries and runtime, application framework, andapplications. Different layers are implemented in differentlanguages. For example, Android’s system services such asdrivers and inter-process communication are written in C orC++, while all platform-related applications and services arewritten in Java and executed by the Dalvik virtual machine.Android’s advantage lies in its open source licensing andextensive programming documentation. The Android SDKprovides the tools and APIs necessary to develop applica-tions on the Android platform using Java.

Our prototype is implemented in Java with AndroidSDK 1.0. The development environment is Eclipse 3.1 withGoogle’s Android Developer Tools plugin. The debug toolsare Dalvik Debug Monitor Service (ddms), which manages

(a) (b)

(c)

Figure 2. A set of three interfaces: (a) Normal UserHome; (b) Login/Authentication ; and (c) User profileConfiguration

processes on the Android emulator or smartphone, and An-droid Debug Bridge (adb), which provides a command-lineinterface to programmers. The source code for our prototypeis about 72.3KB. As Android programs require configura-tion profiles and resources, which are another 225KB, theinstalled file on the phone is a 216KB Home.apk file.

Screenshots of the user interface are given in Figure 2.We load different applications according to users’ profiles.Our prototype includes a login Activity, a user profile con-figuration Activity and a main Home Activity. An Activityis the presentation layer of an Android application screen;its “lifecycle” has four stages—start, pause, resume, andterminate. An Activity provides event handling methods foreach of these stages that can be overridden. The user needsto authenticate himself at the login screen to obtain ad-ministrative privileges, including modifying system settings.The user configuration Activity provides the interface todetermine user access rights to SMS, contacts and GPS.These rights are stored in user profiles. We reprogram An-droid’s native Home Activity. After the system starts up, theHome Activity invokes the method loadapplication()to obtain information about all applications installed on thesystem, including related permissions, that is provided bythe system service PackageManagerService. We add

Source: [31], Figure 2. From left to right: “normal” user screen; user login and authentication; user profile configuration.

Mobile Device Information Leakage

•  Types of mobile device information sources: –  Internal to device (e.g., GPS location, IMEI, etc.) –  External sources (e.g., CNN, Chase Bank, etc.)

•  Third-party mobile apps can leak info to external sources [32] –  Send out device ID (IMEI/EID), contacts, location, etc. –  Apps ask permission to access such info; users can ignore! –  Apps can intercept info sent to a source, send to different destination!

•  Motives: –  Monitor employees’ activity using accelerometers (cited in [32]) –  Ads, market research (include user location, behavior, etc.) –  Malice

•  How do we protect against such information leakage?

Information Flow Tracking (IFT) •  IFT tracks each information

flow among internal, external sources –  Each flow is tagged, e.g.,

“untrusted” –  Tag propagated as information

flows among internal, external sources

–  Sound alarm if data sent to third party

•  Challenges –  Reasonable runtime, space

overhead –  Many information sources

Information leakage on mobile devices

“trusted”

“untrusted”

TaintDroid •  Enck et al., OSDI 2010 [32] •  IFT system on Android 2.1

–  System firmware (not app) –  Modifies Android’s Dalvik

VM, tracks info flows across methods, classes, files

–  Tracks the following info: •  Sensors: GPS, camera,

accelerometer, microphone •  Internal info: contacts, phone

#, IMEI, IMSI, Google acct •  External info: network, SMS

–  Notifies user of info leakage

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

TaintDroid• TaintDroid is a system-wide integration of taint

tracking into the Android platform

‣ Variable tracking throughout Dalvik VM environment‣ Patches state after native method invocation‣ Extends tracking between applications and to storage

• TaintDroid is a firmware modification, not an app6

Network Interface

Native System Libraries

Virtual Machine

Virtual Machine

Application Code Application CodeMsg

Secondary Storage

Message-level tracking

Variable-leveltracking

Method-leveltracking

File-leveltracking

Source: [33]

D2Taint (1) •  Motivation – Mobile device users access many information sources,

e.g. •  Online banks (like Chase) •  Social networking (like Facebook) •  News websites (like CNN)

– Different info sources: different sensitivity levels – Applications’ diverse variable access patterns

challenge tag propagation – Users’ info source access patterns change over time – Need to track many information flows with moderate

space, runtime overhead

D2Taint (2)

•  Differentiated and dynamic tag strategy [34] –  Information sources partitioned into differentiated

classes based on arbitrary criteria – Example (criterion=“info sensitivity level”):

•  Classes: “highly sensitive”, “moderately sensitive”, “not sensitive” •  Sources: Chase → “highly sensitive”; Facebook →

“moderately sensitive”; CNN → “not sensitive”

– Each class’s sources stored in a location info table •  Source indices (0, 1, …) ↦ source names (chase.com, …)

D2Taint (3) •  D2Taint uses fixed length tag (32 bits)

–  Tag includes segments corresponding to classes –  Each segment stores representations of information sources in

its class –  Representation: info source’s class table index

•  Note: source table grows over time –  Information source representation does not uniquely ID source

D2Taint (4) •  D2Taint implemented on Android 2.2, Nexus One

smartphones •  Evaluate D2Taint: 84 popular free apps from

Google Play –  71/84 leak some data to third parties

•  E.g., Android system version, screen resolution •  Often, third parties are cloud computing services •  TaintDroid cannot detect external data leakage

–  1 bit in tag for “network” –  Cannot track multiple external sources at once

–  12/84 leak highly sensitive data, e.g., IMEI/EID (detected by both D2Taint, TaintDroid)

•  D2Taint has overhead similar to TaintDroid’s

Location Privacy Protection •  Strong regulation – Corporate –  Individual

•  Dynamic MAC and Bluetooth addresses? – Collision – How often to change?

•  Proxy-based communications – Dummy device as proxy – Group communications

Summary

•  Mobile devices are increasingly popular •  There are many threats and attacks against

mobile devices, e.g., loss/theft, sensitive information leakage, and location privacy compromise

•  Mobile access control, information leakage protection, and location privacy protection, etc.

References (1) 1.  Cisco, “Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2011–

2016”, 14 Feb. 2012, http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ ns705/ns827/white_paper_c11-520862.html

2.  Samsung, “Exynos 5 Dual,” 2012, http://www.samsung.com/global/business/semiconductor/ product/application/detail?productId=7668&iaId=2341

3.  Nielsen Co., “Two Thirds of All New Mobile Buyers Now Opting for Smartphones,” 12 Jul. 2012, http://blog.nielsen.com/nielsenwire/online_mobile/two-thirds-of-new-mobile-buyers- now-opting-for-smartphones/

4.  K. De Vere, “iOS leapfrogs Android with 410 million devices sold and 650,000 apps,” 24 Jul. 2012, http://www.insidemobileapps.com/2012/07/24/ios-device-sales-leapfrog-android-with- 410-million-devices-sold/

5.  K. Haslem, “Macworld Expo: Optimised OS X sits on ‘versatile’ Flash,” 12 Jan. 2007, Macworld, http://www.macworld.co.uk/ipod-itunes/news/index.cfm?newsid=16927

6.  Wikipedia, “iOS,” updated 2012, http://en.wikipedia.org/wiki/iOS 7.  Apple Inc., “iPhone Developer University Program,”

http://developer.apple.com/iphone/program/university.html 8.  Apple Inc, “iOS Security,” http://images.apple.com/ipad/business/docs/

iOS_Security_May12.pdf 9.  Android Open Source Project, “Android Security Overview,” http://source.android.com/tech/

security/index.html Presentation organization inspired by T. Eston, “Android vs. iOS Security Showdown,” 2012, http://www.slideshare.net/agent0x0/the-android-vs-apple-ios-security-showdown

References (2) 10.  A. Rubin, 15 Feb. 2012, https://plus.google.com/u/0/112599748506977857728/

posts/Btey7rJBaLF 11.  H. Lockheimer, “Android and Security,” 2 Feb. 2012, http://googlemobile.blogspot.com/

2012/02/android-and-security.html 12.  Android Open Source Project, http://developer.android.com/about/dashboards/index.html 13.  M. DeGusta, “Android Orphans: Visualizing a Sad History of Support,” 26 Oct. 2011,

http://theunderstatement.com/post/11982112928/android-orphans-visualizing-a-sad-history-of-support

14.  http://opensignalmaps.com/reports/fragmentation.php 15.  http://www.micro-trax.com/statistics ` 16.  Lookout, Inc., “Mobile Lost and Found,” 2012, https://www.mylookout.com/resources/

reports/mobile-lost-and-found/ 17.  K. Haley, “Introducing the Smartphone Honey Stick Project,” 9 Mar. 2012,

http://www.symantec.com/connect/blogs/introducing-symantec-smartphone-honey-stick-project

18.  Juniper Networks, Inc., “Global Research Shows Mobile Malware Accelerating,” 15 Feb. 2012, http://newsroom.juniper.net/press-releases/global-research-shows- mobile-malware-accelerating-nyse-jnpr-0851976

References (3) 19.  F-Secure, “Mobile Threat Report Q2 2012,” 7 Aug. 2012, http://www.slideshare.net/fsecure/

mobile-threat-report-q2-2012 20.  http://nakedsecurity.sophos.com/2012/04/12/a ndroid-malware-angry-birds-space-game/ 21.  Via Forensics LLC, “Forensic Security Analysis of Google Wallet,” 12 Dec. 2011,

https://viaforensics.com/mobile-security/forensics-security-analysis-google-wallet.html 22.  Proxmark, http://www.proxmark.org/ 23.  libnfc, http://www.libnfc.org 24.  D. Goodin, “Android, Nokia smartphone security toppled by Near Field Communication hack,”

25 Jul. 2012, http://arstechnica.com/security/2012/07/android-nokia-smartphone-hack/ 25.  B. Andersen, “Australian admits creating first iPhone virus,” 10 Nov. 2009,

http://www.abc.net.au/news/2009-11-09/australian-admits-creating-first-iphone-virus/1135474 26.  R. Radia, “Why you should always encrypt your smartphone,” 16 Jan. 2011,

http://arstechnica.com/gadgets/2011/01/why-you-should-always-encrypt-your-smartphone/ 27.  Heritage Foundation, “Solutions for America: Overcriminalization,” 17 Aug. 2010,

http://www.heritage.org/research/reports/2010/08/overcriminalization 28.  Wikipedia, http://en.wikipedia.org/wiki/Mobile_device_forensics 29.  C. Quentin, http://www.slideshare.net/cooperq/your-cell-phone-is-covered-in-spiders

References (4) 30.  A. J. Aviv, K. Gibson, E. Mossop, M. Blaze, and A. M. Smith, “Smudge Attacks on

Smartphone Touch Screens,” Proc. USENIX WOOT, 2010. 31.  X. Ni, Z. Yang, X. Bai, A. C. Champion, and Dong Xuan, “DiffUser: Differentiated User

Access Control on Smartphones,” Proc. IEEE Int’l. Workshop on Wireless and Sensor Networks Security (WSNS), 2009.

32.  W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth, “TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones,” Proc. USENIX OSDI, 2010, http://appanalysis.org

33.  W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth, “TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones,” http://static.usenix.org/event/osdi10/tech/slides/enck.pdf

34.  B. Gu, X. Li, G. Li, A. C. Champion, Z. Chen, F. Qin, and D. Xuan, “D2Taint: Differentiated and Dynamic Information Flow Tracking on Smartphones for Numerous Data Sources,” Technical Report, 2012.