Android Security #1

Prabhaker MatetiA first lecture on Android Security, assuming

familiarity with Android Internals.

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

Mateti

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.

Mateti

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

Mateti

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.

Mateti

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

Mateti

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

Mateti

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

Mateti

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

Mateti

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.c

om/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.

Mateti

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.

Mateti

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

Mateti

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.

Mateti

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)

Mateti

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

Mateti

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

Mateti

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 Mateti

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”)

Mateti

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.

Mateti

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

Mateti

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)?

Mateti

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• OpenBSD calloc to prevent integer overflows during

memory allocation • Linux mmap_min_addr() to mitigate null pointer

dereference privilege escalation

Mateti

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.

Mateti

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

Mateti

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

Mateti

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

Mateti

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 permissio

ns– request to be given the s

ame Linux identity as another app

Mateti

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

Mateti

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⇒

Mateti

Android Security #1 30

Permissions #2

• PERMISSION_GRANTED or PERMISSION_DENIED Context.checkCallingPermission() Arbitrarily fine-grained permissions

• Context.checkPermission(String, pid, uid)

Mateti

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

Mateti

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 trickyMateti

Android 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/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

Mateti

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.Mateti

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.

Mateti

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

Mateti

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.

Mateti

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

Mateti

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

Mateti

Android Security #1 40

A Study of Android Market Apps

Mateti

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.

Mateti

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.

Mateti

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.

Mateti

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

Mateti

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 Swarat Chaudhuri, “A Study of Android Application Security”, 20th USENIX Security, Aug 2011. Recommended Reading.

Mateti