1. Mobile Device Security
Adam C. Champion and Dong Xuan
CSE 4471: Information Security
Based on material from Tom Eston (SecureState), Apple, Android Open Source Project, and William Enck (NCSU)

2. Organization Quick Overview of Mobile Devices
Mobile Threats and Attacks
Mobile Access Control
Information Leaking Protection
Case Studies

3. 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

4. Organization Quick Overview of Mobile Devices
Mobile Threats and Attacks
Mobile Access Control
Information Leaking Protection
Case Studies

5. Mobile Threats and Attacks
Mobile devices make attractive targets:
People store much personal info on them: , 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
Much Android malware, much less for iOS
NFC-based billing system vulnerabilities

6. 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

7. 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

8. iOS Malware Malware, “fake apps” have hit iOS too
iKee, first iPhone virus, “rickrolled” jailbroken iDevices [25]
Example “fake/similar” apps:
Temple Run: Temple Climb, Temple Rush, Cave Run
Angry Birds: Angry Zombie Birds, Shoot Angry Birds
Not to mention “walkthroughs,” “reference” apps, etc.
Google Play banned such apps…
iOS, Android hit with “Find and Call” app
SMS spammed contacts from central server
Removed from App Store, Google Play

9. Android: DroidDream Malware
Infected 58 apps on Android Market, March 2011
260,000 downloads in 4 days
How it worked:
Rooted phone via Android Debug Bridge (adb) vulnerability
Sent premium-rate SMS messages at night ($$$)
Google removed apps 4 days after release, banned 3 developers from Market
More malware found since

10. Android: Fake Angry Birds Space
Bot, Trojan
Masquerades as game
Roots Android 2.3 devices using “Gingerbreak” exploit
Device joins botnet
Source: [20]

11. Android: Case Study: SMS Worm
Students in previous information security classes wrote SMS worms, loggers on Android
Worm spreads to all contacts via social engineering, sideloading, etc.
Logger stored/forwarded all received SMS messages
Only needed SEND_SMS, RECEIVE_SMS, READ_SMS permissions
Can send 100 SMS messages/hour
One group put SMS logger on Google Play (removed it)

12. Android: Google Wallet Vulnerabilities (1)
Google Wallet enables smartphone payments
Uses NFC technology
Many new mobile devices have NFC
Some credit card info stored securely in secure element
Separate chip, SD card, SIM card
Unfortunately, other data are not stored as securely

13. Android: Google Wallet Vulnerabilities (2)
Some information can be recovered from databases on phone: [21]
Name on credit card
Expiration date
Recent transactions
etc.
Google Analytics tracking can reveal customer behavior from non-SSL HTTP GET requests
NFC alone does not guarantee security
Radio eavesdropping, data modification possible [22]
Relay attacks, spoofing possible with libnfc [23]

14. Android: Sophisticated NFC Hack
Charlie Miller’s Black Hat 2012 presentation: Nokia, Android phones can be hijacked via NFC [24]
NFC/Android Beam on by default on Android 2.3+, Android 4.0+
Place phone 3–4 cm away from NFC tag, other NFC-enabled phone
Attacker-controlled phone sends data to tag/device, can crash NFC daemon, Android OS
For Android 4.0–4.0.1, can remotely open device browser to attacker-controlled webpage

15. 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]

16. Organization Quick Overview of Mobile Devices
Mobile Threats and Attacks
Mobile Access Control
Information Leaking Protection
Case Studies

17. 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)

18. 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

19. 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

20. 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!

21. 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)

22. 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

23. Authentication: Comparison
Passwords
Smart Cards
Biometrics
Pattern Lock
Security
Weak
Strong
Ease of Use
Easy
Medium
Hard
Implementation
Works for phones
Yes No
Possible
– Deeper problem: mobile devices are designed with single-user
assumption…

24. Smartphone Privileges
Our Work: 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
Bluetooth
Apps
App Install
Limit
Sensitive Apps
Source: [31], Table 1.

25. Our Work: DiffUser (2) Implement our system on Android using Java
Override Android’s “Home” Activity for multi-user authentication, profile configuration
Source: [31], Figure 2. From left to right: “normal” user screen;
user login and authentication; user profile configuration.

26. Organization Quick Overview of Mobile Devices
Mobile Threats and Attacks
Mobile Access Control
Information Leaking Protection
Case Studies

27. 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?

28. 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
“trusted”
“untrusted”
Information leakage on mobile devices

29. 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
Source: [33]

30. TaintDroid (2) Uses a 32-bit tag structure
Set bit indicates an information flow (or sensor in use)
Bit #
Tracks
31–16
Unused 15
History sent out 14
Google account sent out 13
Device serial # sent out 12
ICCID (SIM card ID) sent out 11
IMSI (subscriber ID) sent out 10
IMEI (device ID) sent out 9
SMS sent out 8
Accelerometer in use 7
Camera in use 6
“Last” location sent out 5
Data sent out over network 4
GPS location sent out 3
Phone # sent out 2
Microphone in use 1
Contacts sent out
Location sent out

31. TaintDroid (3) Tested 30 popular Android apps (Internet permission)
37/105 flagged network connections were legitimate
15/30 apps leaked data to ad/market research firms, (admob.com, flurry.com, etc.); not obvious to user
Source: [33]

32. Our Work: 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

33. Our Work: 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, …)

34. Our Work: 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

35. D2Taint system architecture
Our Work: D2Taint (4)
Tag dynamics
Users access information sources via time-varying patterns
Class size, representation size can be adjusted as different kinds of sources are accessed
Can switch tag schemes using pre-configured, on the fly options
Variable operations require merging tags with different schemes
D2Taint system architecture

36. Our Work: D2Taint (5)
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

37. Organization Quick Overview of Mobile Devices
Mobile Threats and Attacks
Mobile Access Control
Information Leaking Protection
Case Studies
iOS
Android

38. iOS System Architecture (1)
Boot sequence:
Bootloader, kernel, extensions, baseband firmware all have cryptographic signatures
Root of trust: burnt into boot ROM at the factory
Each component’s signature is verified
If any signature doesn’t match, the “connect to iTunes” screen is shown
Icons from Double-J Design, IconBlock

39. iOS System Architecture (2)
Software updates
Cannot install older version of iOS on an iDevice; e.g., if device runs iOS 5.1.1, cannot install iOS 4
Device cryptographically “measures” components, sends to Apple install server with nonce, device ID
Nonce: value used only once
Prevents attacker from “replaying” the value
Server checks measurements; if allowed, server adds device ID to measurements, signs everything

40. iOS Apps and App Store All iOS apps signed by Apple (not developer)
Third-party apps signed only after:
Developer ID verification (individual, company)
Review: bugs, work correctly (program analysis)
Each app sandboxed in its own directory
Cannot communicate with other apps
Apps need signed “entitlements” to access user data
Further app protection:
Address Space Layout Randomization (ASLR) for all apps
ARM eXecute Never (XN) bit set for all memory pages

41. iOS Data Protection Measures
Each iDevice has hardware-accelerated crypto operations (AES-256)
Effaceable Storage: securely removes crypto keys from flash memory
“Erase all content and settings” wipes user data using Effaceable Storage (locally or remotely)
Interact with mobile device management (MDM), Exchange ActiveSync servers
Developers can use APIs for secure file, database storage
Passcodes
Admins can require numeric, alphanumeric, etc.
Wipe device after 10 failed login attempts

42. iPhone Configuration Utility

43. Miscellaneous iOS Security
Built-in support for SSLv3, TLS, VPNs
Extensive administrative controls:
Password policies
Disable device features, e.g., camera
Disable Siri
Remote wipe
Apps can access contacts without permission (fixed in iOS 6)
Source: [8]

44. iOS Jailbreaking Circumvents Apple’s iOS security mechanisms
Violates iDevice’s terms of use
Allows installation of apps from alternative app stores, e.g., Cydia
Removes app sandbox
Usually replaces kernel with one accepting non-Apple signatures
Tools: redsn0w, Absinthe, etc.
Legal in U.S. under DMCA 2010 exemption

45. Organization Quick Overview of Mobile Devices
Mobile Threats and Attacks
Mobile Access Control
Information Leaking Protection
Case Studies
iOS
Android

46. Android Security (1) Android built on Linux kernel, which provides
User permissions model
Process isolation
Each app is assigned unique user/group IDs, run as a separate process ⇒ app sandbox
System partition mounted read-only
Android 3.0+ enables filesystem encryption using Linux dmcrypt (AES-128)
Device admins can require passwords with specific criteria, remote wipe devices, etc.

47. Android Security (2) Android device administration (3.0+): Remote wipe
Require strong password
Full device encryption
Disable camera

48. Android Security (3) Other protection mechanisms:
Android 1.5+: stack buffer, integer overflow protection; double free, chunk consolidation attack prevention
Android 2.3+: format string protection, NX, null pointer dereference mitigation
Android 4.0+: ASLR implemented
Android 4.1+: ASLR strengthened, plug kernel leaks
Capability-based permissions mechanism:
Many APIs are not invoked without permission, e.g., camera, GPS, wireless, etc.
Every app must declare the permissions it needs
Users need to allow these permissions when installing app

49. Android Security (4)
All Android apps need to be signed: by the developer, not Google
Google Play app store less regulated
Apps available rapidly after publishing
Bouncer service scans for malware in store [11]
Google Play permissions interface

50. Android Device Diversity (1)
Android runs on various devices
Different devices run different OS versions
Device manufacturers often add their own custom UIs, software
Mobile operators add their own software
Not all devices are updated to latest Android version!
Security challenges…
Android devices accessing Google Play,
August Some devices are not always
updated to the latest version. These devices
tend to have security vulnerabilities targeted
by attackers.
Source: [12]

51. Android Device Diversity (2)
Notice many Android devices are “orphaned” without major updates [13]
Android developers need to secure their apps for many different devices…

52. Android Device Diversity (3)
The OpenSignalMaps Android app sees almost 4,000 types of device clients. Source: [14]

53. Rooting Android Devices
Android device owners can often get root access to their devices
Process can be as simple as unlocking bootloader
Sometimes, exploit bugs to get root
Result: install OS of choice, bypass device/operator restrictions
Legal under 2010 DMCA exemption
Security problems:
Voids device warranty (usually)
Circumvents app sandbox: root can modify any app’s files
Malware can root and own your device!

54. Thank You
Questions/comments?

55. References (1)
Cisco, “Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2011–2016”, 14 Feb. 2012, ns705/ns827/white_paper_c html
Samsung, “Exynos 5 Dual,” 2012, product/application/detail?productId=7668&iaId=2341
Nielsen Co., “Two Thirds of All New Mobile Buyers Now Opting for Smartphones,” 12 Jul. 2012, now-opting-for-smartphones/
K. De Vere, “iOS leapfrogs Android with 410 million devices sold and 650,000 apps,” 24 Jul. 2012, million-devices-sold/
K. Haslem, “Macworld Expo: Optimised OS X sits on ‘versatile’ Flash,” 12 Jan. 2007, Macworld,
Wikipedia, “iOS,” updated 2012,
Apple Inc., “iPhone Developer University Program,”
Apple Inc, “iOS Security,” iOS_Security_May12.pdf
Android Open Source Project, “Android Security Overview,” security/index.html
Presentation organization inspired by T. Eston, “Android vs. iOS Security Showdown,” 2012,

56. References (2)
A. Rubin, 15 Feb. 2012, posts/Btey7rJBaLF
H. Lockheimer, “Android and Security,” 2 Feb. 2012, /02/android-and-security.html
Android Open Source Project,
M. DeGusta, “Android Orphans: Visualizing a Sad History of Support,” 26 Oct. 2011, `
Lookout, Inc., “Mobile Lost and Found,” 2012, reports/mobile-lost-and-found/
K. Haley, “Introducing the Smartphone Honey Stick Project,” 9 Mar. 2012,
Juniper Networks, Inc., “Global Research Shows Mobile Malware Accelerating,” 15 Feb. 2012, mobile-malware-accelerating-nyse-jnpr

57. References (3)
F-Secure, “Mobile Threat Report Q2 2012,” 7 Aug. 2012, mobile-threat-report-q2-2012
ndroid-malware-angry-birds-space-game/
Via Forensics LLC, “Forensic Security Analysis of Google Wallet,” 12 Dec. 2011,
Proxmark,
libnfc,
D. Goodin, “Android, Nokia smartphone security toppled by Near Field Communication hack,” 25 Jul. 2012,
B. Andersen, “Australian admits creating first iPhone virus,” 10 Nov. 2009,
R. Radia, “Why you should always encrypt your smartphone,” 16 Jan. 2011,
Heritage Foundation, “Solutions for America: Overcriminalization,” 17 Aug. 2010,
Wikipedia,
C. Quentin,

58. References (4)
A. J. Aviv, K. Gibson, E. Mossop, M. Blaze, and A. M. Smith, “Smudge Attacks on Smartphone Touch Screens,” Proc. USENIX WOOT, 2010.
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.
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,
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,”
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.