8.1 Mobile Platform Threats & Security Models

Why Mobile Security Is on the CEH Exam

The Mobile Platform, IoT, and OT Hacking domain is roughly 10% of the CEH v13 blueprint and one of the most testable on this domain. Mobile devices hold credentials, OAuth tokens, corporate email, and synced files, yet they live outside the traditional network perimeter and roam across untrusted Wi-Fi and cellular networks. The exam expects you to reason about which weakness class applies to a described scenario and what defensive control mitigates it — not to perform live exploitation. Treat every item below as authorized, defensive knowledge: you are learning the attack surface in order to harden it.

The mobile attack surface spans four areas you should be able to name: the device (storage, OS integrity, lock screen), the application (code, permissions, local data), the network (transport security, Wi-Fi), and the server/back-end (APIs the app calls). A weakness in any one of these can compromise the others — for example, a plaintext token on the device (app/device) can be replayed against the back-end (server).

OWASP Mobile Top 10 (2024) — Conceptual

The Open Worldwide Application Security Project (OWASP) publishes a Mobile Top 10. The 2024 release is the first major revision since 2016 and deliberately reorders the list around credentials and the software supply chain, reflecting how real-world breaches actually begin.

Note the shift: the 2016 list led with Improper Platform Usage; the 2024 list elevates credentials (M1) and supply chain (M2). M3 in 2024 also merges the old separate Insecure Authentication and Insecure Authorization items. A common exam trap is confusing M5 Insecure Communication (data in transit, a TLS problem) with M9 Insecure Data Storage (data at rest, a storage problem) — read the scenario for where the data lives.

Android vs iOS Security Models

The two dominant platforms make different trust trade-offs. Knowing the difference lets you predict which attack vector a scenario implies and which defense fits.

Key exam idea: Android's open model historically faces a larger malware surface mainly because of sideloading and ecosystem fragmentation (slow, inconsistent patching), not because the Linux kernel is weaker or lacks isolation. iOS reduces malware exposure through a curated store and mandatory signing, but a jailbroken iOS device discards those protections and is no safer than an unmanaged Android.

App Sandboxing

App sandboxing confines each application's code and data so that, by default, one app cannot read another app's private storage or interfere with its processes. On Android, each app typically runs under its own UID with a private data directory; on iOS, the OS enforces a per-app container. Sandboxing is a containment control: it limits blast radius if one app is malicious or compromised. It does not stop a user from granting an app excessive permissions, and it is weakened or broken entirely once the device is rooted/jailbroken.

Permission Models and Code Signing

Modern Android (6.0+) and iOS use runtime permissions: the user is prompted to allow access to a sensitive resource (location, camera, contacts, microphone) at the moment it is first needed, and can revoke it later in settings. The recurring CEH weakness is over-permissioning — an app requests far more access than its declared function requires (a flashlight asking for SMS and contacts). The defensive principle is least privilege; app-vetting tools and Mobile Threat Defense agents flag permission scope that does not match declared functionality.

Code signing binds an app to a verifiable author and guarantees the binary has not been tampered with since signing. iOS requires Apple-issued signing to launch any app; Android accepts developer self-signed certificates, which is more flexible but means signing alone proves continuity of authorship, not trustworthiness. Both models collapse on a rooted/jailbroken device, which is why root/jailbreak detection is a baseline control for any app that handles sensitive data.