The practical challenges of keeping mobile devices’ operating system software up to date
You’re vulnerable, you know
In November, it was reported that a vulnerability in the Android operating system had been discovered, which allowed the passcode to be bypassed. This was a pretty explosive finding. In effect, it meant that anyone could, by following a few simple steps, unlock a phone to which they had access. Devices are mislaid every day, and passcodes exist to ensure that, should they fall into the wrong hands, our data will remain secure. And it’s not just lost phones – housemates, colleagues, intimate partners, children, and many others have ready access to our phones when we leave them lying on a table, desk or anywhere else.
These kinds of high-severity vulnerabilities are not confined to Android devices. In October, Apple released an urgent upgrade for iOS to address a severe vulnerability that Apple announced “may have been actively exploited”. This followed a similar urgent update in August. In these cases, the vulnerability was one which required considerable technical skill to exploit but did not require physical access to the device.
The discovery of security holes in mobile operating systems is more common than is generally appreciated.
The graphs below show the number of CVE’s discovered in iOS and Android in recent years.
Graph 1: iOS Vulnerabilities By Year [Source: cvedetails.com]
Graph 2: Android Vulnerabilities By Year [Source: cvedetails.com]
While many of these vulnerabilities are relatively minor, they do nonetheless confirm that mobile operating systems are not the impenetrable fortresses that some assume.
Your mobile’s secure… until it isn’t
The architecture of mobile operating systems has given them considerable advantages over the traditional operating systems on laptops and desktops. They have a range of built-in features which makes them hard to hack. Application sandboxing is the single most important reason why mobile operating systems are more secure than their desktop/laptop equivalents. Apple’s documentation summarises sandboxing very well:
“All third-party apps are “sandboxed”, so they are restricted from accessing files stored by other apps or from making changes to the device. Sandboxing is designed to prevent apps from gathering or modifying information stored by other apps. Each app has a unique home directory for its files, which is randomly assigned when the app is installed. If a third-party app needs to access information other than its own, it does so only by using services explicitly provided by iOS and iPadOS.”
Access to system functions is tightly restricted, and any sensitive capability (for example, tracking location) requires explicit user permission. Application sandboxing is a major departure from traditional operating systems. In macOS or Windows, software downloaded to the device has unrestricted access to a wide range of system functions and to all of the files on the device. But even with sandboxing, there are gaps and holes that can be exploited. For example, attacks against the Safari Webkit rendering engine are popular because it has access to a range of system functions unavailable to standard applications.
The software distribution model for iOS and Android is also a security strength. In iOS, in particular, it is very difficult to inadvertently install an app which has not been through the App Store vetting process.
Android remains more open. The latest statistics from Google’s Android ecosystem security report suggest that in June 2022, Potentially Harmful Apps (a broad category that includes spyware, toll fraud and phishing apps) represented .05% of Android app installs. When Corrata’s Mobile Security is initially rollout out, we typically find between one in every one hundred and one in every two hundred devices have malware installed.
A third area where mobile operating systems have improved on their traditional predecessors is in ensuring the integrity of the operating system itself. In the early days of iOS, it was not uncommon for skilled users to exploit vulnerabilities to ‘jailbreak’ the phone (technically gain superuser privileges) to customize the device in some way (for example, by installing apps without going through the App Store). Rooting is the term for the equivalent process on Android. Some manufacturers allow rooting (in much the same way that a skilled user can replace the Windows operating system that ships with a pc) but others do not (thus requiring a vulnerability). The risk to an organization when a device is jailbroken or rooted is that the inbuilt security protections they expect to operate can no longer be relied upon.
And this illustrates well the reason why patching vulnerabilities is so important. If the operating system is vulnerable, then you can no longer rely on sandboxing, file encryption and other protections to work.
The challenges with vulnerability patching
Apple, as both the phone manufacturer and owner of the operating system, has always had complete control over the delivery of patches to its phone. In the past, the patch process for Android was problematic.
However, this has much improved, particularly with the introduction of monthly security updates, which can be implemented without the need for an overall system upgrade. So now the question is not whether patching is possible but rather how you ensure that mobile devices used by your employees are kept up to date.
The key challenge is that, in many circumstances, you are reliant on end users to perform the upgrade. And even where you have control over the update process (for example, with supervised iOS devices), we may be concerned about user pushback when updates introduce significant changes to user experience. And remember, of course, that many organizations allow unmanaged user-owned devices (BYOD) to access critical data on their mobiles, including email, file sharing, and line of business apps.
A zero-trust approach to Operating System hygiene
Lock down, and protect your systems with conditional access policies
In our experience, the most effective way to ensure operating system hygiene is to use conditional access policies. Conditional access is a key part of the zero-trust security model. With this model, access to corporate systems, be they on-premises, cloud-hosted or hybrid, is conditional on the security status of the user, device, and network from which the access request is coming. We can, for example, use conditional access to restrict access to the most sensitive information to managed devices, with a high-security score only allowing unmanaged devices to access less sensitive data. And even this access can be made conditional on the device running up-to-date software.
A general policy that requires users to be running up-to-date software to access corporate systems has, in our experience, been effective. Updating system software is simple today and only a minor inconvenience to the end user. The dangers of running out-of-date software are increasingly understood by the general public, making it easier for Info Sec teams to communicate a no-tolerance policy to unpatched devices.
And while there may be a minority of older devices which can no longer be patched, replacing these is a price worth paying for the peace of mind that successful patchwork brings.