Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Android Security #1 Prabhaker Mateti A first lecture on Android Security, assuming familiarity with Android Internals. “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? Mateti Android Security #1 2 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. Mateti Android Security #1 3 Screen Lock, … • Enable Screen Lock – Slide – Connect the Dots (Pattern) – PIN – Password – Face Unlock – Finger print • All exploited already Mateti • 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 4 Labeling People • Hacker – – • • 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 Noobie Whitehat – • 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. • • 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. – 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. http://www.catb.org/~esr/jargon/html/index .html Mateti Android Security #1 5 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 Mateti Android Security #1 6 Breadth of MobiComp Security Issues • Mobile Computing includes • Additional areas of concern – standard TCP/IP networking – Wi-Fi, Access Points, WEP, WPA, … – bluetooth, cellular, … networking – So all network security relevant Mateti Android Security #1 – theft/loss of mobile device and its content – limited computational power – limited storage capacity 7 Security Philosophy • Prevent vulnerabilities and security breaches • Minimize their impact • Detect vulnerabilities and security breaches when they happen • React swiftly afterwards Mateti Android Security #1 8 Prevent • Prevent before they happen • Design and build better source code • Examined by security experts • Prevent installation of bad apps. • Runtime Vigil Mateti • 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 9 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/dynamicanalysis-tools-for-androidfail.html • Before install Android checks. • 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. – Settings > Security > Verify apps. Mateti Android Security #1 10 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 • 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. • Code audits • Secure Code Dev Edu Mateti Android Security #1 11 Keep Software Up-to-date • Every OS should be responsible for: • Android Over-The-Air update system (OTA) – Automatically updating itself – Providing a central update system for thirdparty applications – User interaction is optional – No additional computer or cable is required – Very high update rate • Autoupdaters Mateti Android Security #1 12 Minimize the Impact of Security Holes • Traditional OS security – Host based – User separation • Same origin policy – webmail cannot access banking app Mateti • Mobile OS are for single users • Sandboxed • Each app runs as a process owned by its own UID. Android Security #1 13 Detection of Security Holes • Fuzzing • Honeypot – Testing via invalid, unexpected, or random data as the inputs – http://en.wikipedia.org/ wiki/Fuzz_testing • Enable everyone to detect – A sting operation. A trap set to detect, deflect, or counteract unauthorized use of systems. – http://en.wikipedia.org/ wiki/Honeypot_(computi ng) – Users – Developers – Security Researchers Mateti Android Security #1 14 React to Security Incidents • Suppose we discovered a security incident. What to do now? • Shut the device down? • For enterprise situations – How long does it take? – Meanwhile … • Collect info. But, how and what? • Answers are non-trivial. Mateti Android Security #1 – http://technet.microsoft .com/en-us/library/ cc700825.aspx – http://csrc.nist.gov/ groups/ SMA/fasp/ documents/ incident_response/ Incident-ResponseGuide.pdf 15 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 Mateti Android Security #1 16 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 Mateti Android Security #1 17 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”) Mateti Android Security #1 18 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. Mateti Android Security #1 19 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 – – – – Mateti Format strings SQL injection Remote file injecttion Cross-site scripting Android Security #1 20 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)? Mateti Android Security #1 21 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 • OpenBSD calloc to prevent integer overflows during memory allocation • Linux mmap_min_addr() to mitigate null pointer dereference privilege escalation Mateti Android Security #1 22 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 nonobvious button presses. • Android detects a “problem” and goes into the safe mode. Mateti Android Security #1 23 OS protected APIs • Cost-Sensitive APIs – Telephony – SMS/MMS – Network/Data connections – In-App Billing – NFC Access • Sensitive Data Input Devices – Location data (GPS) – Camera functions – Microphone • Bluetooth functions • Personal Information Mateti Android Security #1 24 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. Mateti • Services: interfaces directly accessible using binder. • Intents: A message object that represents an "intention" to do something. • ContentProviders: A data storehouse Android Security #1 25 Application Signing • CA = certificate authority • Why self signing? • All .apk files must be signed with a certificate – Market ties identity to developer account – CAs have had major problems with fidelity in the past – No applications are trusted. No "magic key" Mateti Android Security #1 – identifies the author of the application. – does not need to be signed by a CA 26 Application Signing #2 • What does signing determine? • Allows the system to grant or deny access – Shared UID for shared keys – Self-updates • If the public key matches, the new APK may request to share UID of the other APK. Mateti Android Security #1 – signature-level permissions – request to be given the same Linux identity as another app 27 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 Mateti Android Security #1 28 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 Mateti Android Security #1 29 Permissions #2 • PERMISSION_GRANTED or PERMISSION_DENIED Context.checkCallingPer mission() Arbitrarily fine-grained permissions Mateti • Context.checkPermissio n(String, pid, uid) Android Security #1 30 Android Sandbox • The sandbox is based on separation of • Each application – processes – file permissions – Authenticated IPC • Sandboxes native code and sys applications Mateti Android Security #1 – is a different “user”; its own UID – runs in its own Linux process – its own Dalvik VM 31 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 Mateti Android Security #1 32 File System Encryption • Full file system encryption • AES128 • Password • random salt • CPU and mem intense • http://source.android.c om/devices/tech/encry ption/ Mateti • 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 33 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. Mateti Android Security #1 34 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. Mateti Android Security #1 35 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 Mateti • 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 36 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. Mateti Android Security #1 37 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 Mateti Android Security #1 38 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 Mateti Android Security #1 39 A Study of Android Market Apps Mateti Android Security #1 40 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 used – as device finger prints. – to track individual users. – for ad and analytics servers. • Phone identifiers are frequently leaked through plaintext requests. Mateti Android Security #1 41 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. Mateti Android Security #1 42 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. Mateti Android Security #1 43 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 Mateti Android Security #1 44 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 Swarat Chaudhuri, “A Study of Android Application Security”, 20th USENIX Security, Aug 2011. Recommended Reading. Mateti Android Security #1 45