Transcript Android Security Part 1

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