Android security in depth - extended
7 likes•1,488 views
The document outlines Android security at multiple levels: system, application, and enterprise, detailing measures such as sandboxing, permissions, and encryption methods. It highlights advancements in versions 4.2 to 4.4, including application verification, Selinux reinforcement, and verified boot capabilities. It also covers the importance of app signing and device policies for enterprise security, emphasizing the need for comprehensive security measures in Android devices.
Android security in depth - extended
- 1. Logistics Healthcare Automotive Industrial Automation Android Security in depth Sander Alberink Machine & Systems Energy
- 2. Agenda Android overview System-level security Application-level security Enterprise-level security
- 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
- 4. Android Security – System level
- 6. System level execution NX-bit Stack-overflow prevention Address Space Layout Randomization dlmalloc/calloc + extensions mmap_min_addr Avoid leaking kernel pointer addresses
- 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
- 19. Android Security – Application level
- 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
- 21. Permissions Permissions determine if an app can perform an action 4 levels: ■ Normal ■ Dangerous ■ Signature ■ System
- 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.
- 24. Android Security – Enterprise level
- 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
- 29. Questions?
Editor's Notes
- #8: 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
- #15: No setuid
- #17: 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
- #18: 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.
- #27: 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
- #30: Work partitions contains apps wrapped by samsung in additional security layer