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)

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

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 Mobile Access Control Information Leaking Protection Case Studies

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 Much Android malware, much less for iOS 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

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

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

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

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)

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

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]

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

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]

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

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 Ease of Use Easy Medium Hard Implementation Works for phones Yes No Possible – Deeper problem: mobile devices are designed with single-user assumption…

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.

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.

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

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

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]

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

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]

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

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, …)

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

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

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

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

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

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

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

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

iPhone Configuration Utility

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]

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

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

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.

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

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

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

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 2012. Some devices are not always updated to the latest version. These devices tend to have security vulnerabilities targeted by attackers. Source: [12]

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…

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

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!

Thank You Questions/comments?

References (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 Samsung, “Exynos 5 Dual,” 2012, http://www.samsung.com/global/business/semiconductor/ product/application/detail?productId=7668&iaId=2341 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/ 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/ 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 Wikipedia, “iOS,” updated 2012, http://en.wikipedia.org/wiki/iOS Apple Inc., “iPhone Developer University Program,” http://developer.apple.com/iphone/program/university.html Apple Inc, “iOS Security,” http://images.apple.com/ipad/business/docs/ iOS_Security_May12.pdf 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) A. Rubin, 15 Feb. 2012, https://plus.google.com/u/0/112599748506977857728/ posts/Btey7rJBaLF H. Lockheimer, “Android and Security,” 2 Feb. 2012, http://googlemobile.blogspot.com/ 2012/02/android-and-security.html Android Open Source Project, http://developer.android.com/about/dashboards/index.html 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 http://opensignalmaps.com/reports/fragmentation.php http://www.micro-trax.com/statistics ` Lookout, Inc., “Mobile Lost and Found,” 2012, https://www.mylookout.com/resources/ reports/mobile-lost-and-found/ K. Haley, “Introducing the Smartphone Honey Stick Project,” 9 Mar. 2012, http://www.symantec.com/connect/blogs/introducing-symantec-smartphone-honey-stick-project 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) F-Secure, “Mobile Threat Report Q2 2012,” 7 Aug. 2012, http://www.slideshare.net/fsecure/ mobile-threat-report-q2-2012 http://nakedsecurity.sophos.com/2012/04/12/a ndroid-malware-angry-birds-space-game/ Via Forensics LLC, “Forensic Security Analysis of Google Wallet,” 12 Dec. 2011, https://viaforensics.com/mobile-security/forensics-security-analysis-google-wallet.html Proxmark, http://www.proxmark.org/ libnfc, http://www.libnfc.org 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/ 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 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/ Heritage Foundation, “Solutions for America: Overcriminalization,” 17 Aug. 2010, http://www.heritage.org/research/reports/2010/08/overcriminalization Wikipedia, http://en.wikipedia.org/wiki/Mobile_device_forensics C. Quentin, http://www.slideshare.net/cooperq/your-cell-phone-is-covered-in-spiders

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, http://appanalysis.org 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 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.