Mobile Security Assessment

Most multi-factor authentication systems rely on the user's phone as the channel for receiving a code, either via SMS or via an authenticator app. This makes phone compromise particularly destructive, especially if the phone also offers email access, the typical channel for password reset requests. A simple option for preventing a stolen phone from turning directly into an account breach is to use a separate hardware device for multi-factor authentication, such as a YubiKey. In addition to protecting against phone theft, this also protects against cyberattacks targeting phones, as a hardware authenticator is vastly harder to compromise remotely than a phone is.

If SMS is used as the two-factor authentication mechanism for your staff's accounts, an attacker may even be able to break your MFA through your phone without ever having direct access to it. This is done via SIM swapping, which is a very common way for attackers to target executives or other individuals. This involves two steps. First, an attacker uses open-source intelligence to gain information about the target (the feasibility of which our Open-Source Intelligence Assessment can assess). Secondly, once that information is obtained, the attacker contacts the target's mobile provider and impersonates the target, with the goal of persuading the mobile provider to switch which SIM card is associated with the target's mobile number - for example, by falsely reporting the target's phone as stolen. Once this has happened, all SMS messages and phone calls, including MFA codes, are sent to a phone owned by the attacker. Here, again, the simplest solution is to move the MFA off the phone entirely and to a physical device like a YubiKey. Shellhex does not conduct SIM swaps as part of our security testing - they're extremely illegal - but we can advise companies on how to harden their access control to be more secure from the danger of SIM swapping.

Our first step is to assess device management and configuration - your mobile device management policies and their enforcement, including encryption, passcode requirements, the separation of corporate and personal data, remote wipe, and the controls on what applications and configurations a device may carry. Here, it is important to distinguish mobile device management from mobile application management; a bring-your-own-device fleet typically uses the latter, not the former, as few employees are willing to give their employers complete control over the management of their personal devices. For an organisation with dedicated managed phones for its staff, we follow a mobile device management approach and can assess the fleet-wide systems configuration of phones. For a BYOD fleet, we can test, and advise on, mobile application management for encapsulation of corporate data. On Android, this means full containerisation through Android Enterprise Work Profile; on iOS, this is more complex, and involves a variety of different systems (currently Apple User Enrollment, Apple Managed Open In, AppLayerVPN, and the ManagedApp framework).

Given that mobile phones may be the private property, and in any case almost certainly handle the private data, of employees, we only conduct testing in a manner mindful of the consent of specific individuals who use any devices in question. Where possible, we recommend testing dummy devices that are not in active use by an employee but which share any relevant system configuration settings with the actual devices of the fleet.

If an attacker steals a phone while the phone is locked, the first thing they are likely to try is to unlock the phone. A phone lock is not a magic vault. It is a delay mechanism. Strong biometrics are generally resistant to casual spoofing, but weak face unlock systems with poor liveness checks may be fooled by photos or videos, or even by similar-looking people. A six-digit PIN has only about 20 bits of theoretical entropy, which would be trivial to brute-force in an offline attack. Modern phones try to prevent that by making PIN verification happen inside protected hardware with enforced delays and lockout behaviour; however, this protection depends heavily on the device model, patch level, implementation quality, and whether the PIN is actually random. A phone's real security when locked thus depends on the device model, biometric class, passcode strength, notification settings, and whether stolen-device protections are enabled. We can - with authorisation from the staff members in question - assess the security of device unlock for real devices used by your organisation, guide the drafting of standards and policies concerning device unlock settings, and, if your organisation has a fleet of dedicated work phones, guide your direct management of device unlock settings fleet-wide.

If an attacker cannot unlock a phone, this does not mean they cannot access its data - in general, any data physically stored in plaintext on a phone's drive must be assumed to be accessible by an attacker with physical access. Our Workstation Security Assessment and Secure Data Architecture offerings encompass whole disk encryption as a security strategy for laptops and desktops under a physical access threat. Neither iOS nor Android support whole disk encryption. Rather, they instead offer per-file encryption, which while somewhat more complex to configure can provide a high level of device security if properly configured. The core considerations with the security of a per-file encryption configuration are twofold:

• Can we ensure all the necessary data is stored exclusively in encrypted files, and not cached or duplicated in plaintext anywhere?
• Can we ensure that decryption keys for these files are not themselves stored in plaintext on disk?

The first of these is primarily an application configuration issue, but a complex one, as it requires examining all the applications staff use to access your organisation's data, or through which they might obtain authentication tokens used to access your systems. Identifying all the files in which sensitive data is stored is not impossible; it is merely difficult and error-prone, and so we place emphasis on searching device storage for any sensitive information stored in plaintext.

The second of these comes down to device configuration, and, to a certain extent, to constraints imposed by hardware and operating systems, which we can't meaningfully address. On iOS, the keys used to encrypt files are themselves secured with cryptography ultimately backed by a device-unique hardware ID, the user passcode, and the Secure Enclave Processor. On Android, file encryption keys are typically managed by a combination of Android subsystems (such as Keystore, Gatekeeper, and Weaver), typically ultimately backed by hardware enforcement of data separation - via Trusted Execution Environments on the main processor, or via the dedicated StrongBox co-processor. Our options for changing the way your devices manage encryption keys are frequently limited, but we can at least assess their security to give you an informed view of the level of risk you would face if staff devices were compromised.

Physical access is not the only threat model mobile devices face. Phones can be grabbed, but they can also be hacked remotely. The first line of defence against phone compromise comes down to simply having common sense about security on your phone, like double-checking before installing an app that it is by who you think it is and not an impostor, and our Staff Training services can include education about best security practices for mobile devices. However, it is wise to assume that no device is unbreachable. If a phone was remotely compromised through a malicious application or website, could an attacker gain access to everything on the device? This is fundamentally a question about the feasibility of privilege escalation, and as such it is similar in spirit to what our Breach Impact Assessments, Workstation Security Assessments, and Server Security Assessments test for, merely in a different domain. The good news is that privilege escalation on mobile devices is generally actually harder than it is on Windows or Linux machines, but this does not make it impossible.

Android is fundamentally Linux-based, merely with added process sandboxing, built-in permissions and access control restrictions, cryptographic signing of apps, and managed IPC. These security measures make it harder to escalate privilege, but not impossible, especially if there is out-of-date software on the phone. Furthermore, even if Android itself is relatively secure, most Android phones have additional attack surface through third-party (Qualcomm, Samsung, etc.) drivers and OEM software, which are often vulnerability-prone and which can provide a privilege escalation pathway. iOS is even more locked down, with strong sandboxing of apps, mandatory code signing, capability-like security features, AppleMobileFileIntegrity, operating system integrity protections, and more. But iOS systems still remain susceptible to vulnerabilities in the underlying software, including the kernel, if out-of-date.

If you maintain a managed fleet of dedicated devices, our Mobile Security Assessment can include an offensive test of privilege escalation feasibility on a dedicated test device (if you have one), on either Android and iOS. For BYOD organisations, every staff member may have different global configurations, so it may be impractical to test them all - and staff members are unlikely to authorise us to try to hack their personal phone, anyway. However, we can still offer advice on how to harden both Android and iOS phones, which you can pass on to your staff members as policies.

For staff-facing internal mobile applications, we test whether a compromised device could realistically use your application as an attack vector into your organisation's servers and other core systems. We also test if your application stores any authentication credentials locally that an attacker could use to access your systems outside of your application. We broadly align our testing methodology with OWASP MASTG and MASVS. We examine how the application stores data locally, since sensitive data written to the device in recoverable form is one of the most common and serious mobile flaws. We assess transport security and certificate handling, authentication and session handling, the resilience of any jailbreak or root detection the app relies on, and the security of its communication with its backend - frequently the softer target behind a hardened front end. We test on both major platforms as scope requires, since iOS and Android present meaningfully different security models and pitfalls.

What a Mobile Security Assessment provides depends on the precise scope and the nature of your organisation's mobile use; however, in general, what you receive is a report outlining the results of any testing of your mobile systems we performed, as well as targeted guidance on hardening your mobile estate. For organisations that do not manage the mobile devices their staff use for work purposes, we further include guidance on drafting policies surrounding mobile security best practices for staff to implement themselves.