1. Android Security #1 Prabhaker Mateti A first lecture on Android Security, assuming familiarity with Android Internals.

2. “Pwned” Pwn is a leetspeak slang term derived from the verb own, as meaning to appropriate or to conquer to gain ownership. -- http://en.wikipedia.org/wiki/Pwn http://en.wikipedia.org/wiki/Pwn “Your Android device is now pwned by me” A real possibility in 2014. Not because it was stolen. Through malware. Anything you can do with your device, an attacker can remotely. And more? Mateti2Android Security #1

3. No 100% Secure Devices Exist This slide is a quick assessment of how/where things stand in 2014 No 100% Secure Devices Exist. PCs, iPhones, … Do not know how to develop without security holes: – App/ … Software Development – OS Design – Network Protocol Design The ability to exploit these holes … Naïve users installing unverified software. Mateti3Android Security #1

4. Screen Lock, … Enable Screen Lock – Slide – Connect the Dots (Pattern) – PIN – Password – Face Unlock – Finger print All exploited already Security Settings – Apps from Unknown – Device Admins – Verify Apps – Trusted CA – SMS limit per minute Install a Stolen Device Location App Kill switch: To happen Mateti4Android Security #1

5. Labeling People Hacker – A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. – One who programs enthusiastically (even obsessively) or who enjoys programming rather than just theorizing about programming. Noobie Whitehat – Whitehats are the "good" guys: they are mostly into forensics and prevention of attacks. To that end, they ultimately release all knowledge they gain to the rest of the community, while initially controlling such release so that vendors and law-and-order authorities have time to fix things. http://www.catb.org/~esr/jargon/html/index.html http://www.catb.org/~esr/jargon/html/index.html Attackers Script kiddies – A script kiddie is an unskilled individual who uses scripts or programs developed by others to attack computer systems. Script kiddies lack the ability to write sophisticated hacking programs or exploits on their own. Blackhat – Blackhats are the "bad" guys in that they use their knowledge to break, without authorization, into systems, and pass their knowledge to other insiders. They spend enormous hours researching security weaknesses. They do have a work ethic that can be admired but is at odds with our values. Blackhats are almost always known only via their pseudonyms. MatetiAndroid Security #15

6. Security/Privacy of Android Devices All the security/privacy issues of – Mobile Computing – Linux OS Specific to the Android Application framework – AndroidManifest.xml – Activity, Service, Provider, … We focus on Android Android Security #16Mateti

7. Breadth of MobiComp Security Issues Mobile Computing includes – standard TCP/IP networking – Wi-Fi, Access Points, WEP, WPA, … – bluetooth, cellular, … networking – So all network security relevant Additional areas of concern – theft/loss of mobile device and its content – limited computational power – limited storage capacity MatetiAndroid Security #17

8. Security Philosophy Prevent vulnerabilities and security breaches Minimize their impact Detect vulnerabilities and security breaches when they happen React swiftly afterwards Mateti8Android Security #1

9. Prevent Prevent before they happen Design and build better source code Examined by security experts Prevent installation of bad apps. Runtime Vigil Test for known security issues Buffer Overflow Attacks – ProPolice stack overflow protection – Heap protection in dlmalloc Remote (via Network) attacks Media codecs Mateti9Android Security #1

10. Apps From Unknown Sources Google Play and other trusted markets do check the apk. – dynamic analysis tools for android fail – http://thehackernews.com /2014/05/dynamic- analysis-tools-for-android- fail.html http://thehackernews.com /2014/05/dynamic- analysis-tools-for-android- fail.html Before install Android checks. – Settings > Security > Verify apps. Apps from identifiable sources – Code signing – Trust – Go after To install apps from other sources, go to Settings > Security, then touch the box next to Unknown sources. Mateti10Android Security #1

11. Better Design + Build Android Code Complexity 5+ million lines of code on top of Linux kernel Uses 100+ libraries open source ⇒ can't rely on obscurity Code audits Secure Code Dev Edu Correct by design? Known to be free of bugs via thorough testing? Can compilers and other build tools be Trojans? – Yes. K&R Turing Lecture. Mateti11Android Security #1

12. Keep Software Up-to-date Every OS should be responsible for: – Automatically updating itself – Providing a central update system for third- party applications Autoupdaters Android Over-The-Air update system (OTA) – User interaction is optional – No additional computer or cable is required – Very high update rate Mateti12Android Security #1

13. Minimize the Impact of Security Holes Traditional OS security – Host based – User separation Same origin policy – webmail cannot access banking app Mobile OS are for single users Sandboxed Each app runs as a process owned by its own UID. Mateti13Android Security #1

14. Detection of Security Holes Fuzzing – Testing via invalid, unexpected, or random data as the inputs – http://en.wikipedia.org/ wiki/Fuzz_testing http://en.wikipedia.org/ wiki/Fuzz_testing Enable everyone to detect – Users – Developers – Security Researchers Honeypot – A sting operation. A trap set to detect, deflect, or counteract unauthorized use of systems. – http://en.wikipedia.org/ wiki/Honeypot_(computi ng) http://en.wikipedia.org/ wiki/Honeypot_(computi ng) Mateti14Android Security #1

15. React to Security Incidents Suppose we discovered a security incident. What to do now? Shut the device down? – How long does it take? – Meanwhile … Collect info. But, how and what? Answers are non-trivial. For enterprise situations – http://technet.microsoft.com/en-us/library/ cc700825.aspx http://technet.microsoft.com/en-us/library/ cc700825.aspx – http://csrc.nist.gov/ groups/ SMA/fasp/ documents/ incident_response/ Incident-Response- Guide.pdf http://csrc.nist.gov/ groups/ SMA/fasp/ documents/ incident_response/ Incident-Response- Guide.pdf Mateti15Android Security #1

16. Android Platform Security Architecture Security at the OS through the Linux kernel Mandatory application sandbox Secure IPC (inter-process communication) Application signing Application-defined and user-granted permissions Mateti16Android Security #1

17. Linux Security Linux is used in millions of security-sensitive environments. – constantly being researched, attacked, and fixed by thousands of developers – Linux has become trusted by many A user-ID-based permissions model Process isolation Extensible mechanism for secure IPC The ability to remove unnecessary and potentially insecure parts of the kernel Mateti17Android Security #1

18. Android Security Basics Apps have NO permissions, by default Permissions list: Manifest.permissionManifest.permission Apps declare the permissions required in source code – AndroidManifest.xml – e.g., Android system prompts the user for consent at the time the application is installed No mechanism for granting permissions at run-time (unless “rooted”) Mateti18Android Security #1

19. Code Injection The virtual memory model of processes in execution consists of – Code pages and segments. Assumed not writeable. Readable and Executable. “Text” Stack of variables local to method/proc/func Heap of objects dynamically allocated. Should a CPU fetch code from Stack or Heap? Implementation of PLs often require this. MatetiAndroid Security #119

20. Code Injection #2 Code injection was often called “Buffer Overflow” because of the technique used to inject. Abstract idea: Masquerade code as data. Transfer control to this “data”. Other concrete versions – Format strings – SQL injection – Remote file injecttion – Cross-site scripting MatetiAndroid Security #120

21. Qs on the State of the Art Without reading the source code, can we detect that an app contains (malicious) code injection? With reading? Recall the size of software. Can we prevent the execution of such? Can we detect that it happened (after the fact)? MatetiAndroid Security #121

22. Android Security Features Hardware-based No eXecute (NX) to prevent code execution on the stack and heap ProPolice canaries to prevent stack buffer overruns ProPolice safe-iop safe integer op lib for C safe-iop Extensions to dlmalloc to prevent double free() vulnerabilities and to prevent heap exploits OpenBSD calloc to prevent integer overflows during memory allocation Linux mmap_min_addr() to mitigate null pointer dereference privilege escalation Mateti22Android Security #1

23. Safe Mode When the device is in Safe Mode – only core Android applications are available. – free of third-party software. A user can boot into safe mode. Some non- obvious button presses. Android detects a “problem” and goes into the safe mode. Mateti23Android Security #1

24. OS protected APIs Cost-Sensitive APIs – Telephony – SMS/MMS – Network/Data connections – In-App Billing – NFC Access Personal Information Sensitive Data Input Devices – Location data (GPS) – Camera functions – Microphone Bluetooth functions Mateti24Android Security #1

25. Interprocess Communication Standard IPC – file system, local sockets, or signals. – Linux permissions still apply. Binder: RPC mechanism for in-process and cross-process calls. Via a custom Linux driver. Services: interfaces directly accessible using binder. Intents: A message object that represents an "intention" to do something. ContentProviders: A data storehouse Mateti25Android Security #1

26. Application Signing CA = certificate authority Why self signing? – Market ties identity to developer account – CAs have had major problems with fidelity in the past – No applications are trusted. No "magic key" All.apk files must be signed with a certificate – identifies the author of the application. – does not need to be signed by a CA Mateti26Android Security #1

27. Application Signing #2 What does signing determine? – Shared UID for shared keys – Self-updates If the public key matches, the new APK may request to share UID of the other APK. Allows the system to grant or deny access – signature-level permissions signature-level permissions – request to be given the same Linux identity as another app request to be given the same Linux identity Mateti27Android Security #1

28. User IDs and File Access Each apk is assigned a distinct Linux UID – no /etc/passwd as in Linux – different device => may have a different UID – files created by apk are owned by this “user” Shared UID feature – Two applications can share UIDs – More interactivity Mateti28Android Security #1

29. Android Permissions Whitelist model – Allow minimal access by default – User accepted access Facilitate asking users fewer questions Make questions more understandable 200+ permissions – More ⇒ granularity – Less ⇒ understandability Mateti29Android Security #1

30. Permissions #2 PERMISSION_GRANTED or PERMISSION_DENIED Context.checkCallingPer mission() Arbitrarily fine-grained permissions PERMISSION_GRANTEDPERMISSION_DENIED Context.checkCallingPer mission() Context.checkPermissio n(String, pid, uid) Context.checkPermissio n(String, pid, uid) Mateti30Android Security #1

31. Android Sandbox The sandbox is based on separation of – processes – file permissions – Authenticated IPC Sandboxes native code and sys applications Each application – is a different “user”; its own UID – runs in its own Linux process – its own Dalvik VM Mateti31Android Security #1

32. Application Sandbox Place access controls close to the resource, not in the VM – Smaller perimeter ⇒ easier to protect Default Linux applications have too much power Lock down user access for a "default" application Fully locked down applications limit innovation Relying on users making correct security decisions is tricky Mateti32Android Security #1

33. File System Encryption Full file system encryption AES128 Password random salt CPU and mem intense http://source.android.c om/devices/tech/encry ption/ http://source.android.c om/devices/tech/encry ption/ Encryption on Android uses the dm-crypt layer in the Linux kernel. Works at the block device layer. – Emmc and similar Android volume daemon (vold) Android 3.0 and later Mateti33Android Security #1

34. Rooting of Android Devices root – uid == 0 as in Linux – has full access to all applications and all application data system – the kernel and sys applications Boot Loaders – embedded system boot techniques – “Locked”: Check a signature of the OS files being booted, or installed. Mateti34Android Security #1

35. SIM Card Access Low level access to the SIM card is not available to third-party apps. The OS handles all communications with the SIM card including access to personal information (contacts, …) on the SIM card memory. Apps also cannot access AT commands, as these are managed exclusively by the Radio Interface Layer (RIL). The RIL provides no high level APIs for these commands. Mateti35Android Security #1

36. GSM/CDMA Vulnerabilities GSM = Global System for Moblie Communication GSM: Largest Mobile network in the world GSM: 3.8 billion phones on network USA – GSM: AT&T, T-Mobile – CDMA: Others – CDMA = Code division multiple access describes a communication channel access Crack GSM encryption – Can crack encryption in under 30 seconds – Allows for undetectable eves dropping – https://wiki.thc.org/gsm/ simtoolkit https://wiki.thc.org/gsm/ simtoolkit Similar exploits available for CDMA Mateti36Android Security #1

37. SMS Vulnerabilities SMS = Short Messaging System GSM uses two signal bands: control, data. SMS operates entirely on the control band. High volume text messaging can disable the control band, which also disables voice calls. Can render entire city 911 services unresponsive. Mateti37Android Security #1

38. MMS Vulnerabilities MMS = Multimedia Messaging Service – Insecure data protocol for GSM – Extends SMS, allows for WAP connectivity Exploit of MMS can drain battery 22x faster – Multiple UDP requests are sent concurrently, draining the battery as it responds to request Does not expose data Does make phone useless Mateti38Android Security #1

39. Bluetooth Vulnerabilities Bluetooth – Short range wireless communication protocol – Requires no authentication, just “pairing” An attack could take over Bluetooth device. Attacker would have access to all data on the Bluetooth enabled device http://en.wikipedia.org/wiki/Bluesnarfing Mateti39Android Security #1

40. A Study of Android Market Apps Mateti40Android Security #1

41. Information Misuse by Apps Phone identifiers – phone number, – IMEI (device identifier), I – MSI (subscriber identifier), and – ICC-ID (SIM card serial number). Phone identifiers are frequently leaked through plaintext requests. Phone identifiers are used – as device finger prints. – to track individual users. – for ad and analytics servers. Mateti41Android Security #1

42. Android Privacy Private information is written to Android’s general logging interface. Apps broadcast private information in IPC accessible to all applications. A few apps are vulnerable to forging attacks to dynamic broadcast receivers. Some apps define intent addresses based on IPC input. Mateti42Android Security #1

43. Null Pointers Null dereferences cause an application to crash, and can thus be used to as a DoS (denial of service). Apps should perform null checks on IPC input. Mateti43Android Security #1

44. More Privilege Separation Media codecs are very complex ⇒ very insecure Won't find all the issues in media libraries Banish OpenCore media library to a lesser privileged process – mediaserver Immediately paid off – Charlie Miller reported a vulnerability in our MP3 parsing – CERT-2009-002 Mateti44Android Security #1

45. References Android Security Overview, source.android. com/tech/security/ Required Visit.source.android. com/tech/security/ Nils, “Building Android Sandcastles in Android’s Sandbox,” Oct 2010, BlackHat. Recommended Reading. William Enck, Damien Octeau, Patrick McDaniel, and Swarat Chaudhuri, “A Study of Android Application Security”, 20th USENIX Security, Aug 2011. Recommended Reading. Mateti45Android Security #1