Android Platform Overview Android Architecture Kernel – Linux with Low Memory Killer, wake locks, Binder IPC HAL – On top of the kernel, the Hardware Abstraction Layer (HAL) defines a standard interface for interacting with built-in hardware components. Android Architecture Runtime Environment – ART (similar to JVM), Dalvik bytecode (optimized Java Bytecode). ART executes the Dalvik bytecode differently, using a hybrid combination of ahead-of-time (AOT), just-in-time (JIT) and profile-guided compilation. Sandboxing – A malicious third-party application, with low privileges, shouldn't be able to escape its own runtime and read the memory of a victim application on the same device Android Security: Defense-in-Depth Approach The security strategy can be roughly categorized into four distinct domains, each focusing on protecting against certain attack models. - System-wide security Software isolation Network security Anti-exploitation System-wide security - Device encryption – Full-Disk Encryption is deprecated, now File-Based Encryption - Trusted Execution Environment (TEE) – Hardware-backed KeyStore, StrongBox (separate hardware chip), GateKeeper (module enables device pattern and password authentication, must be able to securely throttle brute-force attempts on a user credential) - Verified Boot – cryptographic proof that the code which is running is the one that is intended by the OEM and not one that has been maliciously or accidentally altered. Software Isolation - Android Users and Groups - SELinux – uses a Mandatory Access Control (MAC) system to further lock down which processes should have access to which resources - Permissions – Install-time permissions, Runtime permissions Network security - TLS by Default since Android 9 - DNS over TLS since Android 9 Anti-exploitation Address Space Layout Randomization (ASLR) – standard protection against buffer-overflow attacks, which makes sure that both the application and the OS are loaded to random memory addresses making it difficult to get the correct address for a specific memory region or library Data Execution Prevention (DEP) prevents code execution on the stack and heap, which is also used to combat buffer-overflow exploits. SECCOMP Filter – blocks certain syscalls which are not needed by apps. 17 / 271 syscalls was blocked for ARM64 and 70 / 364 for ARM. Android Application Structure Communication with OS Android apps interact with system services via the Android Framework, an abstraction layer that offers high-level Java APIs. The majority of these services are invoked via normal Java method calls and are translated to IPC calls to system services that are running in the background. The framework also offers common security functions, such as cryptography. The App Sandbox Installation of a new app creates a new directory named after the app package, which results in the following path: /data/data/[package-name]. This directory holds the app's data. Linux directory permissions are set such that the directory can be read from and written to only with the app's unique UID. The App Sandbox Linux User Management Android leverages Linux user management to isolate apps. This approach is different from user management usage in traditional Linux environments, where multiple apps are often run by the same user. Android creates a unique UID for each Android app and runs the app in a separate process. Consequently, each app can access its own resources only. This protection is enforced by the Linux kernel. Inter-Process Communication Intents Intent messaging is an asynchronous communication framework built on top of Binder. This framework allows both point-to-point and publish-subscribe messaging. An Intent is a messaging object that can be used to request an action from another app component. Although intents facilitate inter-component communication in several ways, there are three fundamental use cases: - Starting an activity Starting a service Delivering a broadcast Android Application Publishing - JAR Signing (v1 Scheme) – This scheme does not protect some parts of the APK, such as ZIP metadata (Vulnerable for our RASP check). APK Signature Scheme (v2 Scheme) – faster and offers more comprehensive protection against modification. APK Signature Scheme (v3 Scheme) – adds information about the supported SDK versions and a proof-of-rotation struct to the APK signing block (ability to change signing key as part of an APK update). APK Signature Scheme v4 – based on the Merkle hash tree calculated over all bytes of the APK
