Mobile Device Security Adam C Champion and Dong

Mobile Device Security Adam C. Champion and Dong Xuan CSE 4471: Information Security Based on material from Tom Eston (Secure. State), 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/4 G, 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 i. OS • 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 • i. OS 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

i. OS Malware • Malware, “fake apps” have hit i. OS too – i. Kee, first i. Phone virus, “rickrolled” jailbroken i. Devices [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… – i. OS, Android hit with “Find and Call” app • SMS spammed contacts from central server • Removed from App Store, Google Play

Android: Droid. Dream 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 NFCenabled 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 4 G)

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

Our Work: Diff. User (1) • Current smartphone access Smartphone control focus: 1 user (admin) Privileges • Hard to achieve fine-grained mobile device management: Personal SMS Admin Normal Guest ✔ ✔ ✘ Info Contacts – Control app installation/gaming ✔ ✔ ✘ – Parental controls Wi. Fi ✔ ✔ Limit‼ – Lend phone to friend Resource GPS ✔ ✔ Limit‼ • We design Diff. User, Access Bluetooth ✔ ✔ Limit‼ differentiated user access control model [31] App ✔ Limit ✘ Install – Different users use smartphone Apps in different contexts Sensitive ✔ Limit ✘ Apps – User classification: admin, “normal, ” guest Source: [31], Table 1.

Our Work: Diff. User (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 “trusted” • Challenges – Reasonable runtime, space overhead – Many information sources “untrusted” Information leakage on mobile devices

Taint. Droid • 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]

Taint. Droid (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 0 Location sent out

Taint. Droid (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: D 2 Taint (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: D 2 Taint (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: D 2 Taint (3) • D 2 Taint 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

Our Work: D 2 Taint (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 D 2 Taint system architecture

Our Work: D 2 Taint (5) • D 2 Taint implemented on Android 2. 2, Nexus One smartphones • Evaluate D 2 Taint: 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 • Taint. Droid 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 D 2 Taint, Taint. Droid) • D 2 Taint has overhead similar to Taint. Droid’s

Organization • • • Quick Overview of Mobile Devices Mobile Threats and Attacks Mobile Access Control Information Leaking Protection Case Studies – i. OS – Android

i. OS 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 i. Tunes” screen is shown Icons from Double-J Design, Icon. Block

i. OS System Architecture (2) • Software updates – Cannot install older version of i. OS on an i. Device; e. g. , if device runs i. OS 5. 1. 1, cannot install i. OS 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

i. OS Apps and App Store • All i. OS 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 e. Xecute Never (XN) bit set for all memory pages

i. OS Data Protection Measures • Each i. Device 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 Active. Sync servers – Developers can use APIs for secure file, database storage • Passcodes – Admins can require numeric, alphanumeric, etc. – Wipe device after 10 failed login attempts

i. Phone Configuration Utility

Miscellaneous i. OS Security • Built-in support for SSLv 3, 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 i. OS 6) Source: [8]

i. OS Jailbreaking • Circumvents Apple’s i. OS security mechanisms – Violates i. Device’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: redsn 0 w, 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 – i. OS – 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 Open. Signal. Maps 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) 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/ns 341/ns 525/ns 537/ ns 705/ns 827/white_paper_c 11 -520862. html 2. Samsung, “Exynos 5 Dual, ” 2012, http: //www. samsung. com/global/business/semiconductor/ product/application/detail? product. Id=7668&ia. Id=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-buyersnow-opting-for-smartphones/ 4. K. De Vere, “i. OS 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, “i. OS, ” updated 2012, http: //en. wikipedia. org/wiki/i. OS 7. Apple Inc. , “i. Phone Developer University Program, ” http: //developer. apple. com/iphone/program/university. html 8. Apple Inc, “i. OS Security, ” http: //images. apple. com/ipad/business/docs/ i. OS_Security_May 12. 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. i. OS Security Showdown, ” 2012, http: //www. slideshare. net/agent 0 x 0/the-android-vs-apple-ios-security-showdown

References (2) 10. 11. 12. 13. 14. 15. 16. 17. 18. A. Rubin, 15 Feb. 2012, https: //plus. google. com/u/0/112599748506977857728/ posts/Btey 7 r. JBa. LF 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. De. Gusta, “Android Orphans: Visualizing a Sad History of Support, ” 26 Oct. 2011, http: //theunderstatement. com/post/11982112928/android-orphans-visualizing-a-sad-historyof-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-stickproject Juniper Networks, Inc. , “Global Research Shows Mobile Malware Accelerating, ” 15 Feb. 2012, http: //newsroom. juniper. net/press-releases/global-research-showsmobile-malware-accelerating-nyse-jnpr-0851976

References (3) 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. F-Secure, “Mobile Threat Report Q 2 2012, ” 7 Aug. 2012, http: //www. slideshare. net/fsecure/ mobile-threat-report-q 2 -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 i. Phone 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) 30. 31. 32. 33. 34. 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, “Diff. User: 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. Mc. Daniel, and A. N. Sheth, “Taint. Droid: 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. Mc. Daniel, and A. N. Sheth, “Taint. Droid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones, ” http: //static. usenix. org/event/osdi 10/tech/slides/enck. pdf B. Gu, X. Li, G. Li, A. C. Champion, Z. Chen, F. Qin, and D. Xuan, “D 2 Taint: Differentiated and Dynamic Information Flow Tracking on Smartphones for Numerous Data Sources, ” Technical Report, 2012.