Why ActiveSync policies alone are not sufficient in a Secure Enterprise Environment
Microsoft Exchange ActiveSync is a collection of protocols that enables mobile devices to synchronize and exchange messaging objects such as email, contacts, or calendar items (often referred to as PIM data) with a server. ActiveSync was originally released in 1996 and has now become the de-facto standard for syncing corporate PIM data from various enterprise email solutions from Microsoft Exchange to Lotus Notes, Office365 and Google Apps to mobile devices. Nokia Symbian, Windows Mobile, Blackberry BB10, Google Android, Windows Phone, Apple iOS, Windows 8 RT and Windows 8 Pro all include an ActiveSync PIM client.
The ActiveSync protocol has moved through a number of iterations with release typically coinciding with new editions of Microsoft Exchange Server. Version 1.0 of ActiveSync simply allowed a mobile device sync mail/contacts/calendar from a server, which was a significant improvement from POP3 which was more common at the time. ActiveSync 2.5 added Direct Push, the ability for the server to inform the client that new mail was available in the users’ mailbox so it should connect and sync this new mail. ActiveSync 2.5 also added the first policies/controls in the form of Remote Wipe (the ability for an administrator to set a flag that the ActiveSync client would read during the next sync and initiate a wipe of the device) and the enforcement of a Device Unlock Password/PIN along with some control over the strength of this password/PIN. Further enhancements and controls were added to ActiveSync with enforcement of Device Encryption becoming an option with ActiveSync 12.1.
ActiveSync Policies, such as enforcing a Device Unlock Password or Device Encryption are typically applied during the Provisioning phase of enrolling an ActiveSync client with an ActiveSync server. At a high level the Provisioning process proceeds as follows  –
1. an ActiveSync client initiates the provisioning process with the ActiveSync server
2. if the initiation succeeds (the user has ActiveSync enabled on their mailbox, they have not hit their maximum mobile devices per mailbox limit etc.) the server may
a. immediately issue a Remote Wipe command OR
b. provide a set of policies to the device
3. the device will now apply the policy settings (force the user to set a Device Unlock Password, force the user to encrypt the device, disable the camera etc.) and when it has done so will reply to the server that it is now in compliance
4. the server will acknowledge this and all going well the device will shortly receive email/contacts/calendars
The focus of this whitepaper is part 3 of this process and the assumption by the ActiveSync Server that the ActiveSync Client has in-fact applied the policy settings before responding that it has done so.
In any security conscious enterprise the two fundamental security requirements for allowing corporate email/contacts/calendars on mobile devices should be –
It is generally not feasible for a business to manually check all devices on a regular basis to ensure they are secured in the above manner, and from a compliance point-of-view it would not be acceptable to rely on the user to do so as they could very easily disable the security either accidentally or deliberately to make the device more convenient to use. Therefore it is necessary to use technologically imposed policies, such as ActiveSync Policies, to enforce this security. As a result it is now commonplace for IT Administrators and their businesses to rely on ActiveSync policies for security and assume that they are indeed enforcing them and that their devices are “secure” as per their policy.
The risk with this approach is that the ActiveSync Client on the mobile device is tasked with both enforcing the polices dictated by the ActiveSync Server and with informing the ActiveSync Server that it is compliant, the Server has no mechanism to check the device itself and confirm the settings. This is quite normal behaviour for a protocol like this but is based on the premise that the ActiveSync client can be trusted to report accurate information, and unfortunately this premise is false.
In the case of rooted Google Android devices or compromised (also known as jailbroken) Apple iOS devices the user has unfettered access to the operating system to make any changes they see fit. ActiveSync currently has no mechanism to detect if a device is rooted or jailbroken. Two possible vectors of attack against the enforcement of ActiveSync policies are immediately obvious in this scenario; modify the operating system to report to an ActiveSync Client that the device has a passcode enforced or is encrypted when neither may be the case, or modify an ActiveSync Client to receive the policy from the ActiveSync Server and immediately report that the device is in compliance regardless of whether it is or not. Either of these options could lead to the business believing all their devices are secure according to their ActiveSync Server reports, while a device could have corporate mail on it while no passcode is set, the device is not encrypted or other policies are not enforced – the worst kind of security breach where data is at risk but monitoring systems are reporting everything is secure and compliant.
Below we detail at a high-level the steps required to implement one of the ways of bypassing ActiveSync security policies, with the end result being a device with corporate email on it that appears to be secure (unlock password set and the device encrypted) from the server but is in-fact not. The device used was a Google Nexus running Cyanogenmod 11 (a rooted flavour of the Andoird 4.4.2 Operating System) as this was the easiest operating system to present a demonstration on, similar bypasses are available for virtually all flavours of Android with a simple Google search and rooting the device.
Step 1 – Setup
An ActiveSync Policy was configured on the test Microsoft Exchange 2010 Server as per Figure 1, this policy enforces a complex eight character device unlock password, that the device must be encrypted and that the camera must be disabled. This policy was assigned to the test user’s mailbox.
Step 2 – Prove policies are enforced with an unmodified ActiveSync Client
The first test is to ensure that the test device in an unmodified state will actually enforce the ActiveSync Policies specified above. Figures 2, 3 and 4 below show that while the native ActiveSync email client is configured (the Provisioning phase) the user is forced to set a Password, then Encrypt the device and the Camera is disabled. Figure 5 shows that email would not sync to the device because we did not proceed with encrypting it (due to the battery being too low in this case).
Step 3 – Setup the ActiveSync client to bypass the policies
Android in particular is a very “open” Operating System, the source code for the entire OS is readily downloadable. Part of the source code downloadable is the ActiveSync Email Client.
Applying the third bypass method above was extremely simple and could be carried out by a regular user in less than 15 minutes. As our test device was already rooted the procedure was –
Step 4 – Prove the method above has bypassed ActiveSync policies
Once the phone rebooted the same test account was added to the device from the Settings->Accounts page. The setup went as normal except for the stage after entering the connection details and user credentials where the user would usually be prompted to apply any ActiveSync policies, such as applying a device unlock password or encrypting the device; this simply never appeared and email began syncing to the device.
Figure 6 below shows email syncing to the device even though Figure 7 show that the device has no unlock password or even PIN set and Figure 8 shows that the device is not encrypted.
Output from the Get-ActiveSyncDevices and Get-ActiveSyncDeviceStatistics Exchange 2010 PowerShell commands show the following (note “Enforce PIN and Encryption” is the name of the ActiveSync policy shown in Figure 1 that should enforce an eight character complex device unlock password and device encryption) –
DeviceAccessState : Allowed
IsRemoteWipeSupported : True
Status : DeviceOk
DevicePolicyApplied : Enforce PIN and Encryption
DevicePolicyApplicationStatus : AppliedInFull
While ActiveSync does offer a useful set of policies, due to how easily they can be bypassed they cannot be relied upon unless security is a very low priority for an organisation. The problem is made more serious by the fact that the ActiveSync Server will report that the device is fully in compliance with a policy when it has no way of auditing this.
While this document focused on device unlock passcodes and encryption regulation, it should be obvious that similar steps could be taken to bypass any of the policies that ActiveSync sets and also to disregard Wipe commands sent to the device. A question could also be raised as to what else is packaged in pre-built Email clients downloadable from public forums as it would be a simple task for the Email client to be modified to copy emails/contacts/calendars to 3rd parties without the users’ knowledge. Though there is no reason to believe the packages mentioned in this document contain anything untoward.
It is also worth noting that although this whitepaper was based on an Android device, similar ActiveSync bypasses are also possible on Apple iOS devices with solutions such as ExchangePolicyCleaner – https://github.com/joedj/ExchangePolicyCleaner. In the case of Apple iOS devices these bypasses require the device to be compromised (jailbroken) however as mentioned earlier in the document ActiveSync has no way of determining that a device has been compromised so again will report that the iOS device is in compliance when in-fact it may not be.
While it must be accepted that there are no guarantees when it comes to security and determined entities trying to work around it, there are two common solution to the issue outlined in this document, namely preventing users from compromising devices in the first place or having a system in-place that can detect the compromise.
Preventing devices from being compromised is not something that can easily be achieved above the hardware and operating system layer of a device, it really needs to be carried out by the device manufacturer. Samsung have recently released their KNOX product which is available on their higher-end Galaxy range of devices. KNOX includes features such as Secure Boot which prevents any Operating System from booting on the device unless it has been signed by one of a small set of X.509 certificates that are physically fused into the hardware of the device, and TIMA which is a service running in the TrustZone (a feature of the ARM CPU that separates secure code from other code to avoid it being interfered with) of the CPU and constantly monitors the OS kernel to ensure it has not been compromised.
Compromise (jailbroken or rooted) detection is now a standard feature of most mainstream Mobile Device Management (MDM) solutions. In most cases once the MDM agent on the device detects that the device has been compromised it will inform a management server which can opt to take actions against the device such as blocking any more mail syncing to it or attempting to wipe it altogether. While this may not stop a determined hacker it is sufficient to prevent most regular users from compromising their device and potentially syncing mail to an insecure device.
 Implementing an Exchange ActiveSync client: provisioning
 An ActiveSync Policy bypass tool for Apple iOS devices
 A tool to recompile an Android mail client with ActiveSync Policy enforcement removed
 A pre-compiled Android email client with ActiveSync Policy enforcement removed