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
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
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.