Smartphone are a great target for a cyber attack: they are always online, have wide range of computing resources available and handle sensitive data (email, social networks, online banking, current location).
| Desktop | Android | iOS | |
|---|---|---|---|
| OS | Win/Linux/MAC | Linux based | Darwin based |
| Processor Architecture | x86 | ARM/x86/.. | ARM |
| Programming Language | arbitrary | Java/native code | Objective C |
| Accessibility | open | open | closed |
Security Model
In the realm of mobile operating systems, iOS and Android exhibit distinct security architectures that safeguard user data and ensure application integrity. iOS implements rigorous security measures that encompass both installation and runtime phases. During installation and every subsequent app launch, iOS verifies code signatures, thereby ensuring that only trusted applications, signed by Apple’s certificate authority (CA), are permitted to execute. Furthermore, iOS enforces sandboxing, confining each application within a restricted environment with predefined permissions. For instance, applications are typically restricted from accessing sensitive data such as the Address Book, thereby mitigating potential privacy breaches.
The iOS ecosystem is characterized by its closed nature, predominantly distributed through the App Store, which acts as the central authority for application distribution. This controlled environment significantly reduces the risk of malicious software, except in cases where users opt to jailbreak their devices, circumventing Apple’s security measures.
In contrast, Android’s security model diverges in several key aspects. Upon installation, Android verifies code signatures to establish the authenticity of the application package, ensuring it has not been tampered with during transit or storage. However, unlike iOS, Android does not conduct runtime code signature checks, potentially exposing the system to malicious modifications after installation. Sandboxing in Android is enforced with explicit permissions granted to applications, allowing users to delineate what resources and data an application can access. This approach aims to balance security with user flexibility in application usage.
Android operates within an open ecosystem where applications can be distributed through various channels, not limited to a central certificate authority. While Android lacks a centralized authority akin to Apple’s App Store, integrity checks are performed to verify the authenticity of applications before installation, albeit without the overarching certificate validation present in iOS.
Sandboxing Mechanism
In iOS, the kernel employs Mandatory Access Control (MAC) to constrain both file and memory access for each application. This ensures that apps operate within strictly defined boundaries, preventing unauthorized access to resources. Each app is isolated within its own sandboxed environment, enforced by the operating system’s security framework.
Conversely, Android adopts a distinct approach where each application is allocated a unique user identity. This mechanism leverages Linux’s built-in capabilities to automatically manage privilege separation. By assigning each app its own user credentials, Android achieves effective sandboxing, ensuring that apps are isolated from one another and operate within designated confines of permissions and resources.
Despite the differing implementation details, the fundamental outcome remains consistent across iOS and Android: applications are unable to interact with each other without explicit authorization from the kernel. This contrasts sharply with desktop environments where applications often share the same user context, allowing for more open interaction between software components. The strict sandboxing model in mobile operating systems like iOS and Android significantly enhances security by limiting the potential impact of malicious actions and unauthorized data access between applications.
Access Control Mechanisms
In iOS, access control is managed through “privacy profiles” that dictate which resources and data each application can access. For instance, Safari may be granted permission to access the Address Book under specific conditions. Upon initial use of an application, users are prompted to confirm these permissions, adhering to a default deny policy. This means that unless explicitly allowed by the user, applications are restricted from accessing sensitive data or system resources.
In contrast, Android historically operated on a different paradigm where applications requested permissions explicitly during installation. Users were presented with a list of permissions an app required, and they had to approve all requested permissions as a single block (“all or nothing”). Often, users did not thoroughly review these permissions before granting them, potentially leading to inadvertent approval of unnecessary or intrusive access requests.
However, Android has evolved to adopt a permission model more akin to iOS. In current versions, Android employs a more granular approach where permissions are requested dynamically as needed by the application (runtime permissions). This allows users to grant or deny permissions individually when a specific feature is accessed within the app, similar to how iOS manages permissions. This shift aims to enhance user control and transparency, ensuring that users have clearer insight into and control over how their data and device resources are accessed and utilized by applications.
Both iOS and Android continue to refine their access control mechanisms to strike a balance between user privacy, security, and usability, adapting to evolving threats and user expectations in the mobile ecosystem.
Code Signing
In iOS, stringent measures are in place to ensure that only signed code executes on the device. Application code is signed using the developer’s cryptographic key, and the developer’s certificate, issued by Apple’s Certificate Authority (CA), validates the authenticity of the code. This closed ecosystem approach strictly prohibits external code from being introduced into the system. Additionally, iOS imposes restrictions on dynamic code generation and just-in-time (JIT) compilation, except for JavaScript, to mitigate risks associated with traditional shellcode and more sophisticated exploitation techniques like return-oriented programming. The sandboxing mechanism provides an essential layer of defense, ensuring that even if malicious code breaches initial defenses, it remains contained within its designated boundaries.
In contrast, Android’s security model revolves around cryptographic validation during the installation phase of applications. The installer verifies the cryptographic validity of each new application package against its signature. Unlike iOS, Android does not enforce runtime code signing checks, potentially exposing the system to risks if an application’s integrity is compromised post-installation. Android allows applications to be signed with self-signed certificates, as it lacks a centralized Public Key Infrastructure (PKI) akin to Apple’s CA. Furthermore, Android permits the use of dynamically-generated code through mechanisms like the DexClassLoad API, facilitating functionalities such as silent upgrades.
Breaking the Rules for Extra Apps
In iOS, the process of “jailbreaking” is required to install applications from sources other than the official App Store.
Definition
Jailbreaking involves exploiting vulnerabilities at the kernel or driver level to modify the operating system, enabling the installation of unauthorized apps and alternative app store managers like Cydia.
This procedure is complex and typically inaccessible to average users, requiring technical knowledge and posing significant risks. Once jailbroken, iOS devices circumvent Apple’s security restrictions, making them vulnerable to a broader range of external attacks beyond those typically mitigated by Apple’s security measures.
Conversely, Android provides a simpler method to install apps from outside its official channels. Users can enable the “Allow from unknown sources” setting in the system preferences. This setting permits the installation of applications downloaded from sources other than the Google Play Store or other authorized app stores. Unlike iOS, enabling this setting does not compromise the core security mechanisms of Android itself, as Android’s design inherently supports a more open ecosystem for app distribution.
While both platforms offer avenues to expand app installation capabilities beyond their standard channels, iOS and Android approach this flexibility with distinct security implications. iOS’s reliance on jailbreaking introduces significant security risks by bypassing Apple’s stringent controls, whereas Android’s method preserves core security measures while offering users greater freedom in app selection and installation.
Malicious Code
In iOS installing malicious apps needs a jailbroken target or App Store approval (i.e. overcome manual checks).
In Android “Allow from external sources” must be enabled or Google Play Store approval is needed (i.e. overcome automatic checks) or the app must be installed from an alternative marketplace.
Following the risk formula analyzed in the first chapter:
let’s consider these 4 empirical facts:
- The open model of Android makes it attractive for money-motivated attackers.
- The closed model of iOS makes it unattractive for money-motivated attackers.
- Android has 75% of the market: this makes it attractive for attackers.
- Android has less vulnerabilities than iOS.
As a result about 99% of the malware is written to target Android devices, while the remaining 1% is written to target iOS devices.
In iOS, only 10–15 malware families were found, there are few samples, only 2 of which in the App Store. In Android more than 50 malware families were found: about 200–500K samples (0.28% infected devices) and a dozen cases in the Google Play Store, there are about 100 alternative marketplaces (e.g. apptoide, slideme, and app online) full of malicious apps.
Actions
Sandbox restrictions requires creativity and mobile attackers usually direct monetize via different ways:
- call or text to premium numbers (e.g., 1-900 numbers)
- silently visit web pages (boost ranking) or click on ads (boost revenue)
- steal sensitive information (mobile banking credentials, contacts, email addresses to re-sell)
- root-exploit the device (Android only, so far)
- turn the device into a bot (re-sell) or a zombie (DDoS)
- lock the device and ask for a ransom (ransomware)
To mitigate (Mobile) Malware, Google Play runs automated checks, performs SMS/call blacklisting and quota and exploits Google App Verify (call home when apps are installed). Also, App sandboxing is used to limit the privileges of an app, bit is useless against root-level exploits. To counteract (Mobile) Malware the same ex-post workflow as desktop malware must be followed:
- suspicious app reported by “someone” (e.g., user, antivirus)
- automatically analyzed by Google Play
- manually analyzed by Google support team
- app removed from the (official) store, could remain in unofficial ones
- antivirus signature developed and distributed
Moreover, permission can be analyzed: this allows to detect a lot of mobile malware. The concepts of static and dynamic analysis do not change.
Reflections on Antivirus for Mobiles
Antivirus (AV) software on mobile devices operates within constraints imposed by the platform’s security architecture. AV apps function by scanning for malicious content within their designated sandboxed environment. However, they face inherent limitations in accessing the entire system due to the strict isolation enforced between applications. This isolation ensures that apps cannot interfere with each other, which is crucial for maintaining overall system integrity and user privacy.
The challenge for AV software lies in effectively identifying and mitigating threats without compromising system security. Unlike desktop environments where AV software often operates with elevated privileges, granting root access to an AV app on mobile devices is not advisable. Root privileges grant unrestricted access to the entire system, potentially exposing it to exploitation if compromised by malicious actors.
To address these constraints, AV solutions for mobile platforms typically rely on heuristic analysis, behavior monitoring, and pattern recognition to detect and mitigate threats within the confines of their sandboxed environment. This approach minimizes the risk of inadvertently granting excessive permissions that could be exploited by attackers.