3. Show of hands...
Who has...
■
■
■
■
4
An Android device?
Loaded a custom ROM?
Rooted his device?
Developed for that device?
27 januari 2014
Android Security in depth
7. Linux security measures
Sandboxing in kernel
Permissions enforced through linux groups
Each app separate UID
8. Dalvik VM
Not a security boundary
■ No security manager
■ Permissions are
enforced in OS, not VM
■ Bytecode verification
optimized for speed, not
security
■ Every app can execute
native code!
9. Zygote processes
Zygote process preloads typical classes and
dynamic link libraries
Copy-on-write
■ Only when new process writes page, new
page is allocated.
■ All pages not be written are shared
among all zygote children.
Exec system call is not used in zygote.
■ wipes the page mapping table of process.
■ It means exec discards zygote cache.
Runs as UID=0 (root). After forking child
process, its UID is changed by setuid
system call.
10. Binder IPC
■ IPC via kernel interface
■ Used under water for all IPC in Android
• Service to application
• Service to system
• But also Intent-based communication...
■ Is security-aware and passes calling UID & GID
11
27 januari 2014
Powerpoint ICT Automatisering
11. Additional measures in Android 4.2
Application verification
■ Additional scan for
malicious sw
Always-on VPN
Improvements to
installd/init handling, etc
12. Bouncer
Checks every app submitted to store
(before publication)
Runs app for 5 minutes in emulator,
exercising UI
If flagged: manual analysis
Combination of dynamic/static
analysis
Submit flagged apps too many times
→ blocked account
13. Additional measures in Android 4.3
Android sandbox reinforced with SELinux.
No setuid/setgid programs.
ADB Authentication.
Restrict Setuid from Android Apps.
Capability bounding.
AndroidKeyStore Provider.
14. Additional measures in Android 4.3 cont'd
KeyChain isBoundKeyAlgorithm.
NO_NEW_PRIVS. (This requires Linux kernel version 3.5
or greater)
FORTIFY_SOURCE enhancements.
Relocation protections.
Improved EntropyMixer.
Security Fixes.
15. Additional measures in Android 4.4
Android sandbox reinforced with SELinux in enforcing
mode.
Per-user VPN
ECDSA Provider support in AndroidKeyStore.
Device Monitoring Warnings
FORTIFY_SOURCE level 2
Certificate Pinning
Verified boot
Security Fixes
16. Verified boot
Used to verify underlying
boot image is not
corrupted
Optional feature
17. SE Linux/Android
Mandatory Access Control (MAC) for Linux
Enforces a system-wide security policy
Over all processes, objects, and operations
Based on security labels
Can confine flawed and malicious applications
Even ones that run as “root” / uid 0.
Can prevent privilege escalation
18. Difference between DAC and MAC
DAC: owner of object (f.i. files) determines access level
MAC: system determines access level
system_app
radio
trusted_app
kernel
nfc
20. Intent system
Communication between OS and
applications via Intents
OS resolves requested action
(e.g. 'edit contact') with all
registered Intent receivers
Highly versatile and modular
Allows changing out default
functionality for alternatives
22. Permissions cont'd
Permissions checked when:
■ Starting activities
■ Starting/binding to services
■ Sending to BroadcastReceivers
■ Accessings ContentProviders (separate for read and
write
■ … and at any given moment using
Context.checkCallingPermission()
23. App signing
All Android applications must be signed by the author (developer)
Signing: process of digitally signing a given application using a private key to:
■ Identify author
■ Detect changes
■ Establish trust between applications
On Android, certificate (X.509) can be self-signed, no need for a certificate
authority
Android applications can be built in debug and release-mode:
In debug mode the app is automatically signed with debug key and cannot be
distributed (e.g. via Google Play)
In release-mode app is signed with private key of developer.
25. Encryption
Full-disk encryption using dm-crypt
■ Actually: /data partition
Done using 128 bit AES/SHA256
Master key encrypted with another key based off device
PIN/passwd
■ Problem: since PIN is usually 4 digits long, cracking
master key is matter of little time...
26. Device Policies
Determine user-level
security
Locate lost devices
Enable remote wipe
Can disable functionality
(such as camera)
27. VPN
Support for VPN connections based on
■ IPSec
■ PPTP
■ Own VPN implementation (3rd party, 4.0+)
Requires use of device lock mechanism
As of Android 4.2, always-on VPN is possible too
28. Manufacturer solutions
Samsung KNOX
■ Based on SE Android with additional policies
■ Separate USER and Work partitions
■ Verified boot
■ Per-app VPN
■ More comprehensive mobile device management
NX-Bit: stack and heap marked to prevent code execution from NX-marked memory pages
Mmap_min_addr prevents MMAPing the lowest pages of virtual memory. A null pointer dereference from the kernel could access that memory and execute code that you prepared beforehand.
Leaking point addresses prevented by disallowing unpriviledged app from accessing /proc/kmsg54
No setuid
Device monitoring: addition of certificates that may allow monitoring of encryped traffic
Fortify Source v2: more stricter checking of copies. May cause correct code to fail
ECDSA: Elliptic curves support
No SHA256 hash of entire block device.
Works at the block layer
Hash tree prepared by vendor, signatures of hash-table stored in non-volatile memory on device.
Start by mounting temporary data fs in RAM and ask for device PIN. Test decrypt using key, if succesful rotate mountpoint.
When you have device access to device, everything goes
Work partitions contains apps wrapped by samsung in additional security layer