Android Security #1

1. Android Security #1 PrabhakerMateti 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 • “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? Android 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. Android 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 Android 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 • 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. Android Security #1

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 #1

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 Android Security #1

8. Security Philosophy • Prevent vulnerabilities and security breaches • Minimize their impact • Detect vulnerabilities and security breaches when they happen • React swiftly afterwards Android 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 Android 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 • 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. Android 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. Android 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 Android 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. Android 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 • 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_(computing) Android 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://csrc.nist.gov/ groups/ SMA/fasp/ documents/ incident_response/ Incident-Response- Guide.pdf Android 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 Android 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 Android Security #1

18. Android Security Basics • Apps have NO permissions, by default • Permissions list: Manifest.permission • Apps declare the permissions required in source code • AndroidManifest.xml • e.g., <uses-permission android:name = "android.permission.RECEIVE_SMS" /> • Android system prompts the user for consent at the time the application is installed • No mechanism for granting permissions at run-time (unless “rooted”) Android 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. Android Security #1

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 Android Security #1

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)? Android Security #1

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 • safe-iop safe integer op lib for C • Extensions to dlmalloc to prevent double free() vulnerabilities and to prevent heap exploits • OpenBSDcalloc to prevent integer overflows during memory allocation • Linux mmap_min_addr() to mitigate null pointer dereference privilege escalation Android 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. Android 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 Android 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 Android 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 Android 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 • request to be given the same Linux identity as another app Android 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 Android 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 Android Security #1

30. Permissions #2 • PERMISSION_GRANTED or PERMISSION_DENIEDContext.checkCallingPermission() Arbitrarily fine-grained permissions • Context.checkPermission(String, pid, uid) Android 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 Android 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 Android Security #1

33. File System Encryption • Full file system encryption • AES128 • Password • random salt • CPU and mem intense • http://source.android.com/devices/tech/encryption/ • 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 Android 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. Android 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. Android 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 • Similar exploits available for CDMA Android 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. Android 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 Android 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 Android Security #1

40. A Study of Android Market Apps Android 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. Android 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. Android 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. Android 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 Android Security #1

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