Figure 7-1 Device provisioning
Mobile device management, or MDM, refers to frameworks or solutions that control, monitor, and manage mobile devices deployed across enterprises or service providers. MDM frameworks often provide the provisioning entity with the ability to remotely (over-the-air) monitor, control, and manage mobile devices enrolled with the managing entity’s service.
Although the primary function of an MDM framework is to ensure device management and provisioning features, these frameworks are being increasingly used to ensure and monitor the security posture of mobile devices. Unlike desktop/laptop computing environments, the new smartphone ecosystem is more consumer centric, providing enterprise administrators with limited features. Remote administrators and enterprise administrators can no longer mandate or force system upgrades or force the installation or uninstallation of applications on mobile devices with the same level of control as they have in a desktop environment. Hence, MDM’s play a crucial role in enforcing administrative policies and providing periodic status checks on devices to ensure compliance to policies that are deemed necessary by administrators.
Most mobile platforms provide their own set of policies and features that mobile device administrators can control and enforce. These policies and features, which facilitate mobile device management, jointly form a framework called the MDM framework. iOS, Android, and BlackBerry devices provide their own MDM frameworks that allow device administrators and MDM vendors to create solutions that facilitate mobile device management. MobileIron, AirWatch, and BlackBerry Enterprise are three examples of MDM solutions that leverage platform-specific MDM frameworks to provide device management capabilities. In some cases, however, MDM vendors develop proprietary solutions that do not depend directly on the mobile platform, but still ensure policy enforcement and security posture–check capabilities on mobile devices. Although these solutions do not leverage platform-supported frameworks and features, they are still considered MDM solutions for the purpose of this chapter. GOOD for Enterprise is an example of an alternate MDM solution that provides MDM capabilities without leveraging platform framework and support.
All MDM frameworks provide the same set of core functionalities and features supported by the mobile platform. These features are further augmented by additional vendor-specific functionalities and capabilities. However, the effectiveness of these MDM solutions depends on their ability to integrate into device functionalities while enforcing device management capabilities.
Based on device management objectives, MDM frameworks can be broadly classified into three categories:
• Device-centric model The device-centric MDM model relies on leveraging platform capabilities and feature sets provided by the mobile platform to configure, secure, and harden the mobile device. The basic assumption behind the device-centric MDM model is that the underlying framework can detect changes to a device’s security and configuration posture. MobileIron, AirWatch, and Tangoe are examples of device-centric MDM solutions that take advantage of MDM frameworks provided by the platform.
• Data-centric model The data-centric MDM model focuses on securing data/content of interest, without focusing on controlling or securing the whole device. The basic assumption behind this model is that the solution can ensure the security and integrity of data and provide access control capabilities without relying on platform capabilities. Data-centric MDM solutions often rely on custom mobile apps to enforce access control, ensure the integrity and security of sensitive data, and facilitate access to critical infrastructure. GOOD for Enterprise is an example of a data-centric MDM solution.
• Hybrid model This model combines a platform MDM framework along with solution-specific features to provide device management capabilities. An ideal hybrid solution provides data protection as well as device management capabilities to ensure the security and integrity of the device and data at rest.
Although each of these models exhibit unique functionalities, they share many common features that form the basic tenets of mobile device management. In the following section, we explore and analyze how devices are provisioned using the above-mentioned frameworks.
Device provisioning (Figure 7-1) is the process by which MDM solutions deploy and enforce policies and restrictions on mobile devices and provide access to resources controlled by the MDM server.
Figure 7-1 Device provisioning
MDM frameworks often use MDM client apps for managing and enforcing policies on mobile devices. As shown in Figure 7-1, the end-user uses the MDM app to enroll mobile devices with the MDM server. After successful authentication, the MDM server remotely enforces policies and controls on the device.
Policy enforcement on mobile devices is performed by means of provisioning profiles, which are installed on the device by the MDM client. Provisioning profiles are often XML-or text-based files that specify configuration and provisioning information for the mobile device. Depending on the mobile platform and MDM solution, these provisioning profiles may be plain-text, signed, encrypted, or signed and encrypted to ensure the security and integrity of the profile delivered to the device.
Policy enforcement can be viewed as a three-step process that enrolls the device in the MDM service. These steps can be broadly described as follows:
1. When the device receives a provisioning profile, the profile is verified (its signature is checked) and decrypted before parsing the configuration and enforcement information.
2. After parsing the provisioning profile, mobile platforms populate the system files stored on the device file system with the configuration information required to enforce these policies.
3. System files are subsequently parsed by system services to enforce and implement the configuration settings.
For example, on iOS devices, the MDM server generates the provisioning profiles and sends it to the mobile device through Apple’s Mail client (ActiveSync) or the MDM app installed on the device. The mobile device stores these provisioning profiles at the following location on the device file system (location as observed on iOS versions 4.x to iOS 6.x):
Provisioning profiles are stored on the file system as XML files (plists) with .stub file extensions:
Here is a sample snippet from the iOS provisioning profile:
After verifying and storing the provisioning profile in the form of .stub files, the mobile platform installs these provisioning profiles. Profile installation typically refers to the process of parsing the profile and updating the appropriate system files to enforce the policies requested in the .stub file. On iOS devices, the provisioning profiles (.stub files) are parsed to populate the following system files:
EffectiveUserSettings.plist and Truth.plist are the system files that determine an iOS device’s security posture. For example, Truth.plist specifies the configuration details such as PIN/passcode policies, device restrictions, device timeout, and so on. The following is a snippet from Truth.plist:
Once these system files are populated, as per the requirements specified in the provisioning profile, the profile is considered installed and the appropriate status is updated to the MDM server. When the provisioning profile installation is completed successfully, the MDM server grants the device access to resources protected by the MDM solution.
Although this chapter focuses on iOS for descriptive examples, other platforms like Android behave in a similar manner: provisioning profiles are pushed or installed on devices using XML or similar file formats that are locally cached and parsed to enforce MDM policies.
Although device provisioning and policy enforcement look straightforward, this solution has multiple shortcomings, which are explained in the following sections of this chapter.
As explained previously, MDM policies are enforced by populating the appropriate operating system–controlled files with the configuration requirements. Hence, the effectiveness of MDM controls and policy enforcement is directly proportional to the security and integrity of the operating system and the associated system files.
Modifying MDM Policy FilesOn a jailbroken or rooted device, any user with sudo or root permission can modify these system files. For example, any malicious user can modify the Truth.plist file on iOS devices to relax the passcode requirement restrictions imposed by an MDM administrator. To mitigate this risk, MDM solutions implement proprietary versions of jailbreak detection capabilities that are used to detect signs of activities or features that could lead to MDM compromise. This section includes examples of MDM control bypass.
To enable a simple passcode and to disable the alphanumeric passcode on a device, set the value of allowSimple to true in Truth.plist and the value of requireAlphaNumeric to false:
To enable the capability to Turn Off PIN/Passcode, set forcePIN to false:
To increase the number of failed PIN attempts, set maxFailedAttempts to the desired value:
To set the inactivity and device lock grace period, set maxGracePeriod and maxInactivity to the desired values:
These examples cite some of the MDM controls that a malicious actor can bypass. There are many more controls and restrictions that can be bypassed by means of modifying the above-referenced files, including, but not limited to, password, email, SSL, and software restrictions. An exhaustive list of examples is beyond the scope of this chapter and is left to the interested reader for interpretation and testing.
Detecting MDM BypassMDMs enforce policies by means of provisioning profiles and system files that malicious actors can manipulate to bypass these controls. This limits the effectiveness of MDM solutions, giving rise to the need for a solution that can detect and factor changes to profiles and configurations. To facilitate this need, MDM vendors often use MDM client apps to routinely monitor and evaluate the mobile device’s security posture.
The MDM client apps, in conjunction with the MDM back-end servers, often poll mobile devices to monitor the security posture of enrolled devices. If any device is found to be in violation of MDM policies, the MDM server can invoke security capabilities such as remote wipe, remote lock, or remote locate to ensure the security of the end-user as well as sensitive information on the device. This ability to perform periodic device checks is termed check-in.
Check-in functionality provides MDM administrators with the ability to specify the duration and time for running periodic checks on the mobile device. During check-ins, MDM client-side apps check for the provisioning profile installed on the mobile device. If the provisioning profile is not detected or found to be tampered with, the MDM server triggers responsive actions such as remote wipe or remote lock. This feature specifically addresses scenarios in which provisioning profiles have been deleted from the mobile device or the .stub files have been tampered with or modified. However, this does not address the scenario in which the provisioning profile remains unaltered, but the system file referred to in previous sections has been altered to subvert MDM controls.
Weak MDM Bypass DetectionIn the recent past, some of the leading device-centric MDM solutions were found to be vulnerable to a control bypass attack as they failed to detect changes in system files and only monitored provisioning profiles. Although the iOS platform provides users with the capability to retrieve and monitor effective device settings, most leading MDM solutions were only monitoring the authenticity of the provisioning profile installed on the device.
The following packet snippet shows the check-in message sent by a device to the MDM server. The bold section shows that the device is noncompliant with the profile’s passcode requirements. The MDM, however, fails to detect this.
An attacker can manually tamper with the profile configurations, without being detected by the MDM. This is a significant security threat to data, resources, and intellectual property as it allows an attacker to maintain control over the device by bypassing security requirements and, at the same time, avoid detection.
Although the mobile device sends detailed information regarding the policy violation, as shown here, the MDM server fails to validate the effective configuration applied on the device:
This issue was subsequently fixed by MDM vendors in later releases, after ethical disclosure, by ensuring that the back-end server checks the effective settings on the device and not just the provisioning profile.
MDM apps and solutions are evolving to address these security shortcomings; however, there are even more advanced attacks against MDM solutions that attempt to circumvent the policy enforcement and check-in functionalities. Some of the more sophisticated attacks against MDM solutions involve application modification and app logic-bypass attacks that exploit the trust relation between the mobile client (app) and the MDM back-end server.
The sequence of steps in the client-server interaction between a mobile device and the MDM server is depicted in Figure 7-2. The check-in process is orchestrated by the MDM server. It polls the device periodically and provides the MDM client with specific instructions or commands to execute on the local device. These instructions are typically commands that retrieve the device configuration and security posture information that can then be reviewed by the back-end to ensure compliance. Hence, this interaction model assumes that the information sent across by the device to the server is accurate and cannot be tampered with. Any attacker with the ability to invalidate this assumption will uncover security loopholes that can be used to bypass MDM controls. The more sophisticated attacks against MDM frameworks work by patching and circumventing application and device functionalities that poll or retrieve application configuration and security posture information. By patching these functions and processes, the attacker can control the result of commands executed on the mobile device. As the basic assumption behind MDM frameworks is the client-server trust relation, the ability of the attacker to manipulate the data sent to the server by the client allows the attacker to circumvent MDM policies without being detected by the back-end server. We’ll discuss some of these attack patterns in more detail next.
Figure 7-2 MDM client-server interaction model
Application Patching and Modification AttacksApplication patching and app logic-bypass attacks are platform specific in nature. For example, this type of attack can be performed by modifying the Java or Dalvik byte codes in an Android application. Figure 7-3 depicts the Dalvik byte codes from a disassembled Android application.
Figure 7-3 Android Dalvik byte code
Because the Android platform supports application signing using self-signed certificates, an attacker can easily modify the binary of an Android application to patch existing functionalities or even inject new functionalities into the code. The mobile platform as well as the application back-end often cannot detect any modification or tampering at the client side. These kind of attacks can be performed on rooted Android devices without user knowledge and with user-interaction on a nonrooted device. An attacker can execute the Android PackageManager command on the device as the Linux user shell to install or uninstall Android application packages silently on an Android device. A PackageManager snippet from the Android platform is shown here:
On iOS devices, these attacks can be performed more dynamically by injecting into running processes by means of MobileSubstrate. MobileSubstrate, one of the most popular frameworks, allows applications to perform runtime patching of system functions in iOS. Captain Hook and Logo are two widely used frameworks that can leverage MobileSubstrate for injecting into iOS applications.
These types of dynamic injection attacks on iOS can only be performed on a jailbroken device.
Mobile device hacking and MDM control-bypass attacks often rely on these frameworks to inject and suppress key functionality and capabilities of the MDM application as well as the solution as a whole. For example, XCon (theiphonewiki.com/wiki/XCon) is an application that, when installed, leverages MobileSubstrate to patch jailbreak detection functionality present in an MDM app. The following snippet identifies the list of all functions that were patched by XCon in the pre-2.0 version of GOOD for Enterprise:
By patching these functions in the GOOD app on iOS, XCon provides the user or attacker with the ability to bypass the device’s security controls without being detected by the back-end. Essentially, this allows the attacker to send bogus posture updates to the back-end on behalf of the MDM app running on the device.
Information on MobileSubstrate, Logo, and XCon can be found at iphonedevwiki.net.
Code patching relies on decompiling and debugging apps, so we’ll shift in the next section to a discussion of how that works on Android and iOS platforms and the steps an application developer can take to protect against these attacks.
The ease of performing an application patching attack is determined by the underlying mobile application development platform itself. For example, Android applications are easy to reverse because they are usually developed in a decompilable high-level programming language such as Java.
Android Reverse EngineeringAs you saw in Chapter 4, Android application binaries can be decompiled and debugged by looking at the Dalvik byte code representation of the application. Dalvik byte code is the representation of the application that is interpreted and executed by the Android system. The byte code is obtained by running the Java byte-code version of the application through the Smali assembler (see code.google.com/p/smali/).
Java and Dalvik byte code can be easily decompiled or disassembled. The decompiled or disassembled byte code is human readable and can easily be manipulated. Converting an Android application into Java code is quite trivial. An attacker can then obtain a high-quality version of the actual source code that was written by the application or solution developer. As you saw in Chapter 4, a combination of tools, such as apktool, dex2jar, and JAD, can be used to reverse engineer an Android application and obtain the source code (for more info on these tools, see code.google.com/p/android-apktool/, code.google.com/p/dex2jar/, and varaneckas.com/jad/, respectively). The details of app decompilation are covered more fully in Chapter 4.
Android Code ObfuscationTo mitigate debugging attacks, Java-based Android applications can use code obfuscation to make reverse engineering harder for the attacker. ProGuard (proguard.sourceforge. net/) is a popular and free code-obfuscation tool used to obfuscate Android and other Java/J2ME-based applications. Code obfuscation is not the same as anti-tampering: it does not protect the application and associated code from external attacks, but it does make it harder for an attacker to reverse engineer or debug an application, which provides some security value against unsophisticated attackers. Though code-obfuscation techniques make reverse engineering harder, these techniques are not foolproof and do not protect applications against sophisticated attacks by persistent attackers. Unlike the web application world in which applications written in high-level programming languages are hosted at server-side, the mobile ecosystem follows a client-server model in which these decompilable apps are deployed on client-accessible devices, which are out of the back-end server’s control.
An important thing to remember when using Android code obfuscation: keep Android Activity, Service, Receiver, and Content Provider classes as light as possible and offload most application logic to utility Java classes; these components are directly invoked by the Android system, so class files implementing these components cannot be obfuscated.
A well-programmed Android application that properly uses code obfuscation can make it challenging to reverse engineer Android applications. Figure 7-4 depicts obfuscated code from the Android MDM client for GOOD for Enterprise. This is an example of a well-obfuscated application.
Figure 7-4 Android code obfuscation in the GOOD for Enterprise MDM client
iOS Reverse EngineeringOn the iOS platform, mobile applications are compiled into more low-level machine codes and binaries. iOS applications are written in Objective-C, which is a hybrid language that uses the primitives of the C programming language along with message passing. The message passing functionality of this language is the key feature that separates it from the traditional C language and, at the same time, provides the avenue for data and logic leakage that leads to more sophisticated activities such as application debugging and decompilation.
Class-dump, class-dump-x, and class-dump-z are Objective-C interface extractors that can aid in reverse engineering iOS applications (see cocoadev.com/wiki/ClassDump and code.google.com/p/networkpx/wiki/class_dump_z, respectively). These extractors scan the application binary of iOS applications to extract interface names that are declared in application interface declarations. This, however, does not return or provide any sort of insight into the implementation of these interfaces; it merely provides the debugger with the ability to correlate and understand application logic and functioning. For example, Figure 7-5 shows a dump of interface declaration information from an MDM app that could be of interest to an attacker.
Figure 7-5 iOS class dump from an MDM app
Although interface extractors do not provide implementation information, these tools provide a wealth of information that enables an attacker to patch critical functions in an application, which he or she can then use to perform control-bypass attacks on MDM solutions.
iOS Anti-DecompilationJust as in the Android ecosystem, logic-bypass attacks can be thwarted to an extent on iOS by raising the bar and using a well-programmed and hardened iOS application. An extensive overview of iOS secure coding guidelines is beyond the scope of this chapter (see Chapter 8). However, hardened iOS applications that are more resilient to reverse engineering attacks can be developed by following these recommendations that are particularly relevant to MDM:
• Move critical application logic to more low-level Simula-style programming languages such as C++ that does not use message passing. A skilled attacker can inject into iOS processes and patch Objective-C application implementations, as the target of a message passed in an Objective-C application is resolved at runtime. An attacker can develop dynamic libraries that are loaded into memory and patch method calls invoked via message passing in Objective-C. Moving critical functionalities into C++ prevents an attacker’s ability to patch Objective-C method calls easily and dynamically. Though C/C++ can also be patched using libraries that load or get invoked before an application execution, it is much harder to achieve and certainly raises the bar and provides extra levels of security that Objective-C cannot provide.
• Ensure more generic naming conventions for publicly exposed interfaces and declarations. By changing the method naming convention and implementing functionality in a transaction processing pattern, an application developer can make application logic-bypass more difficult. By doing so, an attacker not only has to guess the implementation but also has to patch application logic without affecting the app’s core functioning.
• Ensure that the application binaries are generated by enabling symbol table stripping under the Deployment option in XCode to ensure code obfuscation before publicly releasing an application.
• Emphasize creating dynamic UI components for handling sensitive data and user input to avoid swizzling attacks that target data from global variables and components.
• Ensure that all sensitive application logic is confined to private methods, protocols, or anonymous methods. Avoiding forward declarations of sensitive functions prevents easy method swizzling attacks using Mobile Substrate and class-dump.
• Use anti-tamper techniques and solutions that inject guards and protections in the application. These solutions can be used to detect application tampering or reverse engineering attempts. There are multiple anti-tampering solutions in the market today. One of the notable solutions reviewed by the authors in the recent past was EnsureIT for Apple iOS by Arxan Technologies (www.arxan.com/products/mobile/ensureit-for-apple-ios/), which can be used to protect iOS apps against disassembly, reverse engineering, and debugging.
Arxan also makes anti-reversing solutions for Android, as well as desktop applications written in Java and .NET.
Although these techniques can be used to harden iOS applications, they are still not foolproof and can be circumvented by highly skilled attackers with appropriate reverse engineering skills. These types of dynamic attacks on iOS can only be performed on jailbroken devices, however—hence, the ability to detect jailbreaks is a vital feature for MDM applications to ensure device security and integrity as well as their own solution. Let’s talk about that next.
Jailbreak detection, a feature offered by MDM solutions and mobile security products, enables you to detect device breaches. This feature is often offered as extra functionality by MDM vendors to augment the MDM framework and/or MDM features provided by the mobile platforms. With the exception of Apple iOS, which supported this capability as part of its platform features until iOS 4.2, most mobile platforms do not provide jailbreak detection as an MDM capability.
MDM vendor solutions leverage client-side MDM applications (apps) to perform jailbreak detection on iOS devices. The effectiveness and implementation of jailbreak detection varies widely across solutions and vendors and depends on their understanding of device jailbreak mechanisms. For example, most end-users associate device jailbreak with the ability to install applications outside of Apple’s App Store. Hence, most MDM solutions implement jailbreak detection by simply looking for alternate app stores and external applications on a device. Cydia (cydia.saurik.com) is the most popular Apple App Store alternative installed on jailbroken devices because most jailbreak tools in the market load Cydia onto the iOS device after jailbreaking.
Jailbreak Detection BypassMDM solutions and mobile security products mostly perform jailbreak detection by checking the device for the presence of Cydia or other components (mechanisms include but are not limited to trying file writes using fopen(), checking for su, writing out of the “mobile” user space, and so on). Checking for Cydia is generally implemented by means of file handler APIs that look for specific files and directories on the device’s file systems. However, as mentioned in the previous section, an attacker on a jailbroken device can inject into MDM processes and patch application logic that scans the file system for these specific files and directories. Therefore, solutions relying on this logic are susceptible to jailbreak detection–bypass attacks. Some widely used device-centric MDM solutions are susceptible to this attack. This issue is further exacerbated by the fact that device jailbreak can be performed without installing Cydia or other apps on the device. An attacker can bypass this type of jailbreak detection by performing the following steps:
1. Scan application binaries for giveaway interface names such as “isDeviceJailBroken” and “checkDeviceSecurity.”
2. Dynamically patch these method implementations using MobileSubstrate.
The details of jailbreak detection bypass, binary decryption, and application patching are beyond the scope of this chapter; Chapters 3 and 4 contain further details on these attacks.
In addition, tethered device jailbreaks and jailbreak tools that do not install Cydia on a device can easily bypass this type of jailbreak detection. MDM solutions fixed this flaw by checking for more low-level jailbreak symptoms such as a su binary, apt-get package, and file-write permission on-device. However, these features are still implemented by means of method calls and platform features that can be circumvented by skilled attackers.
Jailbreak Detection Bypass CountermeasuresA skilled developer can increase the complexity of jailbreak detection–bypass attacks by implementing these countermeasures:
• Performing multipoint check at multiple locations in the app code and at multiple instances, based on use case scenarios
• Moving jailbreak detection logic into C++
• Performing compensatory controls and actions on the server rather than on-device logic
• Implement anti-debugging and/or code-obfuscation tools/techniques (see previous discussion of anti-tampering tools like Arxan)
Despite the manifest flaws in the current approaches, we believe that jailbreak detection is a highly desirable feature for an MDM solution; it ensures both its own as well as the platform’s security and integrity. However, jailbreak detection is not foolproof without hardware or trusted computing platform support and, hence, has a long way to go before it can assertively provide the level of assurance needed. Device jailbreak and jailbreak detection is a cat-and mouse game that has to evolve over time. MDM vendors must continuously improvise to ensure that it isn’t feasible for an attacker to bypass their application’s jailbreak detection and application logic–bypass detection capabilities.
So far we have discussed MDM provisioning, enforcement, and bypass scenarios associated with both MDM solutions and frameworks. In this section, we explore some of the most commonly adopted MDM security actions, which are mostly triggered as a response to security or compliance alerts or events.
Remote Wipe and Remote Lock are two of the widely used features in an MDM solution. MDM administrators invoke these actions in response to device loss, device breach, or device noncompliance scenarios to ensure the security and integrity of the device and associated data. However, as mentioned earlier in “Bypassing MDM” and as depicted in Figure 7-2, most MDM solutions architect these actions as server-side commands issued to the client device in response to violations detected by the server. Such implementations are also susceptible to MDM control-bypass attacks, as with other MDM capabilities and features. Any attacker with the ability to intercept the Remote Wipe or Remote Lock command from the server can bypass this administrative control on a mobile device. This can be done in multiple ways, including:
• Putting the device in airplane mode to prevent server commands from reaching the device.
• Patching the MDM app so it won’t execute the server commands and provide false responses. For example, patch method calls like - (void)wipeDeviceFileSystem;, as shown in Figure 7-5.
Most MDM solutions, including MobileIron and GOOD for Enterprise, are susceptible to this type of attack. However, most new releases of MDM solutions incorporate client-side decision-making logic that can be used to wipe or lock devices without having to wait or rely on a back-end server to issue the command.
With the penetration of mobile devices into enterprise environments, mobile device management is a key capability that every corporation must have. MDM solutions and capabilities are still evolving and have a long way to go before we can attain the level of assurance needed from these products.
MDM solutions have come a long way toward providing more advanced and hardened products. However, the MDM solution space is still evolving and maturing with more support from platform and hardware along with more tightened and coupled integration with platform functionalities. The large and rapidly evolving mobile threatscape calls for improved MDM capabilities and frameworks. An ideal MDM solution for the future would be one that encompasses both device and data protection at the same time, that is, a hybrid MDM model.