When you are working in the area of mobile security, you sooner or later receive requests from clients asking you to test specific ‘Mobile Device Management’ (MDM) solutions which they (plan to) use, the corresponding mobile apps, as well as different environment setups and device policy sets.
The expectations are often high, not only for the MDM solutions ability to massively reduce the administrative workload of keeping track, updating and managing the often hundreds or thousands of devices within a company but also regarding the improvements towards the level of security that an MDM solution is regularly advertised to provide.
With this very blog post you are reading and a small series of future blog posts, I would like to provide some insight from my day-to-day practical experience with some of the most often used MDM solutions from a testers perspective.
To get a general idea about the market, it makes sense to get an overview over the available solutions. The following list is not necessarily complete, its order alphabetic and does not indicate any kind of preference or rating with regards to the quality of the solution or otherwise:
- BlackBerry Enterprise Mobility Suite (formerly Good Technology)
- Cisco Meraki
- Citrix Endpoint Management (formerly XenMobile)
- IBM MaaS360
- Ivanti Avalanche (formerly Wavelink Avalanche)
- Jamf Pro (formerly Casper Suite)
- Microsoft Intune
- MobileIron
- Trend Micro Mobile Security
- VMware AirWatch
The problem MDM solutions face on mobile devices, is that when it comes to security, the detection of malware and root/jailbreaks, they are supposed to solve a problem which the restrictions of the underlying OS effectively do not allow them to solve.
The agent apps of the MDM solutions out there run with exact the same privileges and within the same sandbox restrictions any other legitimate app on the device runs with. So in terms of awareness of its environment, the agent is mostly blind to anything outside its own sandbox. With one exception. The OS vendors (e.g. Google, Apple etc.) can and do provide certain APIs which to some extent allow functionality without which the whole MDM concept would not work otherwise.
So how does root/jailbreak detection on mobile devices work then? Obviously, it depends on the operating system.
On Android, aside from being able to root the device, and the fact that a device vendor can customize the OS to some extent, users are also able to flash a completely customized version of Android onto their device.
So in comparison to iOS, where the OS is mostly closed source and only distributed by Apple, Android or more specifically AOSP, the Android Open Source Project is available to everyone and everyone is able to build their own version with arbitrary modifications to the OS.
Ideally, an MDM Agent should also be able to identify the source of the Android OS itself and whether it is a genuine vendor-created and -distributed (as well as trusted) operating system or a rather unofficial custom mod or AOSP variant.
One way to do this is to rely on Googles own SafetyNet APIs which, in case of the SafetyNet Attestation (device integrity) API allows an app developer to confirm that a device on which their app runs on is a known ‘good’ OS/device combination by comparing different device and OS aspects with a database of certified profiles.
Due to the fact that rooting a device also requires modifications to the filesystem, same as jailbreaking on iOS, modifications of the system partition will cause SafetyNet tests to fail. As an alternative, this resulted in the so-called systemless root, which makes use of a modified boot partition and doesn’t touch the system partition at all. Modifying the boot partition means that unlocking the bootloader becomes necessary, which on devices like Samsung with its Knox security concept is problematic, as this will trigger an eFuse (hardware fuse) to burn through, which is irreversible at this point.
For any other devices, tools like Magisk will be able to hide root even from SafetyNet when used carefully, even though actual detection success will depend on the specific signal sources and possibly what other apps and tools are installed by the user or an attacker. One famous example of to what great length some developers are willing to go is probably a popular game on mobile devices: Pokemon Go. The game even blocked players which previously had root on their device, as it even looked for specific filenames on the phones SD-card.
On iOS in contrast, an API like SafetyNet does not exist, which means developers have to rely on other means to detect jailbreaks.
Most common is the detection based on filesystem access. As the jailbreak process involves modifications of the default filesystem in terms of directory structure, existence of files and their set permissions, these changes can be detected, by simply enumerating whether a file/directory exists or not or whether there are differences in permissions compared to the default.
Therefore, depending on the implementation, a simple change of the file or directory name and a jailbreak can remain undetected, at least if based on this method alone.
Most of these checks are implemented via calls from Apples Foundation framework and POSIX-compliant system functions. Most prominently used are fopen(), stat(), access(), statfs() as well as NSFileManager and its (BOOL)fileExistsAtPath:(NSString *)path;
An alternative approach is process forking via fork(), popen() etc. On jailbroken devices, checking the returned process id on fork() gives clear indication that a jailbreak is active, while on a non-jailbroken device, the sandbox daemon will not allow this.
A less often used method, as it is not that reliable, is to check for open SSH ports on the device. As not necessarily the default port has to be used, checking for port 22 might mislead to a false negative. Also, even though most public jailbreaks come with SSH access, an attacker might use other means to communicate with and access the device remotely.
Another method is to use system() with NULL as an argument will return 1 on jailbroken devices as it returns non-zero values if a shell is available, while on non-jailbroken devices, a shell is not available and therefore 0 is returned instead.
dyld functions provide one more way to check the jailbreak status of a device, as it allows the developer to get (among other things) the number and names of loaded .dylibs, iOS format of dynamic libraries. Comparing these to the expected values gives another indication for active jailbreaks.
As you can see from the above examples, the more an attacker customizes their root/jailbreak and the less they depend on publicly known tools and techniques, the harder it will be for a detection mechanism to detect it.
Now the sources for a compromise usually are app downloads/installations from arbitrary sources outside of the official app stores (e.g. Google Play Store, Apple App Store). Even though, also the official app stores occasionally contain malware that managed to slip through the review processes.
Depending on what policy the company enforces, with regards to app downloads/installations, the attack surface can range from very small (only selected and monitored apps are allowed) to very broad (e.g. Bring Your Own Device (BYOD) environments, where the user is in control of what apps get onto the device from whatever sources they choose).
In the latter case, the employee brings their personal device. If this device has previously been rooted/jailbroken, the MDM agent now needs to be able to detect the root/jailbreak on a completely untrusted system. Malware running on the device can try to fake a perfectly genuine device by recognizing the agent and its detection mechanisms and simulating the expected check results. Alternatively, malware can try and hook into the agent itself, circumventing the checks directly. Finally, if the agent only reports back the current system state to some MDM backend, without locking down the device on its own, malware can hook into and intercept and modify the communication between the agent and the backend, making it look policy-compliant to the administrative side.
But even in cases of more restrictive policy sets, which only allow selected whitelisted apps, a malicious user still has a chance to get around the restriction and install malware/root/jailbreaks. As already mentioned before, MDM agents fall under the same restrictions as any other app, which means there is no way for an agent to verify an apps identity, aside from using OS mechanics, which (so far) in turn solely rely (on iOS) on an apps’ so-called ‘bundle identifier’.
Modifying an apps bundle identifier to a whitelisted one is rather easy and after signing the app with a developer certificate, it can be sideloaded with common tools.
On Android, white- (or black-)listing usually relies on the apps package name, which doesn’t pose any higher requirements to an attacker than on iOS.
So does an MDM help you to make your company environment more secure? Yes, but it depends a lot on what kind of attacks or attackers you expect. An MDM might help you to protect from your less security aware employees who would love to install that new fancy tool they just heard about in some newsletter they never signed up for. It will usually also protect from disgruntled employees that might want to leave with a bang. Though if you expect targeted attacks against your management from entities with time and money, you should better have additional measures and concepts in place. The policy you implement is the most important part and should get as much attention as possible. If it is too strict, you do not only fight possible attackers but also your employees. If it is not strict enough and you make a lot of your internal infrastructure available to mobile devices, you open up a great attack surface. The right compromise between security and usability will be key to make MDMs work in your company.
I hope, at this point you enjoyed this initial blog post, that it helped you get a basic idea of what MDMs can (realistically) do and where their limitations (the magic) are. The next post in this series will take a closer look into MobileIron on iOS and Android. Stay tuned!