Category Archives: MDM
We know that Android is popular, and recent polls show that Android is “winning” the race in sheer number of smartphones that are out there. Frequent readers will remember previous blog posts on Apple’s MDM solutions where David Schuetz dives into some of the security concerns.
But what about Android? It seems to be following the way of the iPhone in that it becomes super popular as a consumer device, and only then do we start thinking about using it in an enterprise environment. Android has supported mobile device management (MDM) solutions for a long time now (since 2.1). Yet Android, until recently, is often considered ill-prepared for an enterprise environment.
Here’s Your API. Good Luck
Android’s MDM support comes in the way of the DevicePolicyManagement API. This allows developers to control things like password complexity, lockout timing, remote wipe, and remote lock. Standard MDM features right? But what about things like tracking apps that are installed on a device, keeping track of serial numbers, being able to recover lost devices? Yeah, it can do that but just like all of the other Android decisions they’ve made, Google has given you the ability to do it yourself and then they stepped back to watch the carnage. This means that while no official Android MDM solution exists, third parties are picking up the slack and rolling their own.
The MDM Recipes
I categorize third party MDM solutions into three unscientific groups: Cross-platform Android clients that use ActiveSync, native Android solutions, and cloud based solutions. Native clients, such as Google Apps, have created a complete solution tailored to Android devices. They take advantage of the DeviceManagementPolicy APIs and then add in some other features such as asset tracking, GPS location tracking, app auditing, and permission controls. They are not building upon any pre-existing technologies so while this sounds like the best solution, not many MDM providers are going this route because it’s so specific to Android.
Cloud based MDM solutions (lets face it, it’s just Good Technologies), will give a user access to all of the cloud services, and then remove them when the device is no longer compliant with a device policy or an employee leaves the company. You can probably see how it would be easier to just stop granting access to your enterprise services rather than attempting to wipe a device when it leaves a company.
The most popular solution by far is the ActiveSync based solutions. This is an MDM app that relies on ActiveSync for device management policies, and then adds in their own bells and whistles. Airwatch, for instance, is an ActiveSync solution that has added in asset tracking, app auditing, and a lot of other features. In fact, the most popular solution that I’ve seen is just enabling ActiveSync and calling it a day.
As a stand alone solution, ActiveSync will push out device polices that control passwords, idle timeouts, and provide a remote wipe capability. But the bells and whistles that you’ll see with other solutions are nonexistent. The reason it’s so popular is that there’s minimal deployment time and for some environments it very low cost. Those organizations that have already implemented Exchange can enable ActiveSync services for smart phones and using using Android’s built in “Corporate Email Client,” it connects in and is ready to go.
MDM and ActiveSync
Why are we talking about ActiveSync when it comes to Google? The reason is that the Android Exchange client (AKA Corporiate Email Client) uses ActiveSync to pull down email, contacts, and calendar events from corporate networks since 2.1. But one of the features it has also implemented as part of ActiveSync protocol is password controls, remote wipe, and idle timeout.
So that’s great – you have an Exchange environment, you enable ActiveSync, and you now have a mobile device management solution for Android devices. But what about those other feature we talked about; app management, asset tracking, GPS tracking. None of those features are there. Well it turns out that a lot of organizations believe that’s enough. In talking with one of the local fortune 500 companies about how they manage their mobile policy, we found that they’re using a native ActiveSync to implement a Bring Your Own Device (BYOD) mobile policy. They had an Exchange environment, they wanted to allow employees to bring in their own devices to access corporate information, so they enabled ActiveSync and they were done.
Because this is such a popular implementation, it’s also become a target for clients that would like to evade this policy. In the next post I’ll talk about some specific problems that we’ll run into.
MDM Communication With C2DM
Cloud 2 Device Messaging (C2DM) is Google’s lightweight data push service. It’s Android’s answer to the Apple Push Notification Service or the Blackberry Push Service. These types of services are ways of pushing down information to an app as opposed to waiting for an app to pull data. A lot of the MDM providers use this solution to send down their device policies or remote commands. When a remote wipe command is issued from an organization, you don’t want to wait for the app to issue a schedule update, you want that command to be sent as soon as a device has connectivity to something.
A coworker of mine is looking into the security concerns with C2DM but in this scenario, we’re concerned that someone might be able to send a remote wipe to your phone without having administrative access.
Android’s MDM solutions are up in the air which may be why a lot of people say that Android isn’t really ready for the enterprise. With the latest Ice Cream Sandwich version of Android that supports policy controlled encryption, I think you can see Google pushing Android into enterprise environments much more.
This is a nice little info blurb about Android MDM and the underlying technologies but lets be honest, the real fun comes from attacking. The next Android MDM post will discuss some attack vectors and evasion techniques that may make you re-think how much you trust your MDM provider.
Last Saturday (January 28), I presented an updated talk on Apple’s iOS MDM system at ShmooCon 8. I had a great time, and really enjoyed all the questions and nice comments I received afterwards. I thought I’d mention a couple of the changes that iOS 5 provide.
First, the devices support some additional restrictions and controls. These controls should be available in most commercial MDM solutions, and can also be found in the iPhone Configuration Utility (IPCU). Among these new controls are the ability to:
- Disable Siri
- Selectively disable iCloud features: Backup, Document Sync, Photo Stream
- Reject SSL sites with untrusted certificates
- Prevent moving messages out of an email account into another
- Prevent use of an email account from 3rd party applications
Additions to the MDM service as a whole include:
- Ability to ask a device to “Check Out” when removed from MDM
- Installing and removing applications (custom and App Store apps)
- Listing managed applications
- Configuration of some settings (Voice and Data Roaming)
- Applying iTunes redemption codes to installation of apps (for Volume Purchase Plan)
I’ve updated my experimental MDM server to support most of these features. I’ve also added some better documentation for the server code, and scripts to help create the necessary server and CA certificates.
Slides from the presentation, as well as the code and the Black Hat white paper and slides, are all available at Github. Enjoy!
When deploying iOS devices, such as the iPhone or iPad, to a corporate population, the security-minded may ask “how can we keep people from using this device for inappropriate web surfing?” The easy answer is to use the restrictions available via profiles. This can be readily accomplished through a configuration profile that disallows Safari. The profile is easiest to create using the iPhone Configuration Utility (IPCU). It can then be installed on the device via the IPCU directly (usingUSB) or through a Mobile Device Management (MDM) system. Disabling Safari is simple: Just remove the checkbox next to “Allow use of Safari” and push the configuration to the target devices.
Once this configuration has been loaded on the device, Safari will simply disappear altogether, and the user won’t be able to surf to any of their favorite web sites, right? Apple MDM documentation is pretty clear that you can disallow the use of Safari, so our iOS devices should be safe and locked down.
Well, it’s not quite that simple. The IPCU can also create Web Clips, little icons on the device’s home screen that link to external URLs. The only restriction is that the web clip must be set to “full screen” mode (which disables the Safari navigation controls, etc.) Any page can be loaded through a web clip, however, tapping on links within that page doesn’t work. The screen won’t even acknowledge the tap, and the device will not navigate to the link.
Simply place this on just about any publicly-accessible web server. Then create a new web clip, using the URL for the file as the web clip’s source, and push the clip to your device.
Tap the web clip icon, and select the desired site. The second selection in the example doesn’t do much more than show you the front page of this blog, as all the links are still intercepted and neutered by the web clip display. However, the link for Gmail is fully functional. You can log into the system, read, and reply to emails, as if Safari were fully functional.
Just to re-iterate, this is being installed on an iPad with Safari completely disabled. The user should not be able to connect to anything other than the pages directly referenced by the installed web clip.
Is there a workaround? Nothing that I’ve been able to discover so far. It seems that this is an easy way to get around corporate restrictions and access arbitrary web sites on iOS devices. With a little work, one could conceivably create a proxy server that transparently modifies web pages and sends them to the device with all links changed to something that’ll work within the web clip framework. In a way, a simple ajax-based web browser could be created that would let the user have the vast majority of Safari’s functionality, despite the device restrictions.
Fortunately, if the device is managed by an MDM server, then the server should at least be able to see the “rogue” profile that the user installed. However, because the profile was installed by a 3rd party (that is, not by the MDM service), the server may not be able to see the contents of the profile and, thus, the web clip. For more about the risks of personal yet managed devices in the enterprise, check out this post from Jeremy.
Has anyone else run across this? It seems absurdly simple, so I’m surprised it hasn’t been discussed, but I haven’t been able to find any references to this…issue. What do you think, is this a bug? or a feature?
This article is part 2 of our gripping thriller on mobile platform trustworthiness, which focuses on the iOS platform and some of the new features in iOS 4.x. This article assumes you have made the leap of faith and are ready to bring iOS devices onto your network as full participants. Now you need to know what controls are available and how useful those controls are. Apple’s solution to enforcing these controls is known as a “Mobile Device Management” server, or MDM for short. This article will start with device security and gradually focus outward to a discussion on MDM. Today we will also make some comments on the thorny issue of jailbroken iOS devices.
First, the actual devices: since the iPhone 3GS, Apple devices have supported hardware based encryption. This technology got off to a rocky start for Apple as it was almost trivial to circumvent. Apple has continually improved since then. The iPhone 4G, iPad and 3GS and the latest generation iPod Touch devices all support hardware based encryption. It is important to understand that, prior to iOS 4, the hardware based encryption available on iOS devices existed solely to provide a nearly instantaneous remote wipe feature. That is all. The data was not ever, really, protected if an adversary physically acquired the device and put it in a Faraday Cage, also sometimes referred to as a Booster Bag. Some data would not be accessible, but overall a savvy attacker can get some pretty sensitive things off the device before iOS 4.
As of iOS 4, Apple provides a data protection mechanism they, aptly enough, call “data protection” on the aforementioned devices. This leverages the security of the built in hardware based encryption to protect the 256-bit AES full disk encryption keys with the passcode on the device. Now, applications that specifically utilize the data protection API will have their data protected with proper encryption controls. The encryption is implemented to make brute force attacks (in the event that an attacker recovers the device and the encrypted data on the device) infeasible. Applications that do not store the data using the data protection APIs can still have their data stolen if an attacker recovers the physical device and the device is not wiped. Currently, only the Mail application uses the data protection features out of the box in iOS 4, which is a bit disappointing. However, with this caveat in mind, iOS can now provide reliable confidentiality for our data that is resistant to local attacks. This feature is one of the major building blocks required to trust these devices on an enterprise network.
Additional settings for iOS devices can limit the number of manual/physical password entry attempts an attacker will get. In the event the device is stolen and the attacker tries to guess the password, the device will forget the encryption key, which is a small 256-bit chunk of data. When the device is wiped, the encryption key is deleted and the attacker has no recourse. Ideally we will see a BlackBerry like feature that causes the device to wipe itself after being disconnected from the network for some set amount of time, which works even if the SIM card is removed and the device is in a booster bag. From this point, the protection mechanisms and security features needed for enterprise deployment become higher level and focus more on policy and tools to enforce policy. Mobile Device Management (MDM) is the sophisticated caveman club we use to bludgeon unsuspecting iOS devices into submission.
Mobile Device Management
Beyond the device security features that are afforded all users of iOS devices are the new MDM APIs. These features are probably of the most interest to large organizations as they provide the ability to enforce policy. The first step to bringing an iOS device into the fold is “Enrollment”. A profile is installed, which encapsulates a large amount of configuration details and security settings. Apple provides a tool, the iPhone Configuration Utility, to create these configuration profiles. A couple of screenshots, illustrating the features of the tool, are shown below:
Nearly everything of interest for on-device configuration is set up in the configuration utility: Wi-Fi credentials, VPN credentials, MDM settings, pass codes, email configuration, etc. This enables administrators to quickly push a set of configuration details to an iOS device. Another nice feature of MDM is that it can all be done “over the air”, making device configuration streamlined. These features give organizations the tools they need to set up effective security policies and enforce them. The features are not lacking in any significant regard and were designed with large enterprise security concerns in mind.
Mobile Device Management is accomplished via a MDM server. There are quite a few available MDM server suites out there: JAMF’s casper suite, Sybase’s Afaria, Air Watch and many others. These servers are the entities that will actually query the iOS devices and issue commands to them. They will perform the enrollment, configuration deployment and querying. The options are very numerous on the configuration side. Restrictions can now be enforced on application installation, iTunes backup policy (encryption), password policies and other settings that enabled organizations to fully control iOS devices that are enrolled. Most of these settings are configured into profiles using the iPhone Configuration Utility and then deployed via the MDM. Most of these controls are flexible and can be tailored to a specific situation or personal device usage scenario.
So, what about jailbreaking? About that: Apple quietly dropped a sneaky feature they added in iOS 4.x. They added an API to make iPhone devices “confess” if they had been jailbroken. These efforts typically involve applications that attempt to do things they should not be able to do, such as accessing the root file system, accessing forbidden APIs, etc. If an application has the ability to perform these actions there is a good chance (read: almost certain chance) that the device is jailbroken. The short version is that jailbreaking is no different from users running a local privilege escalation exploit on a corporate issued laptop to gain admin access to it. The MDM vendors all have their own strategies for detecting jailbroken devices.
If the device is personally owned by the user it becomes a bit murkier, but ultimately to be a good “network citizen”, users need to understand that jailbreaking should not be done on devices handling sensitive data and that it removes security features. Tools for jailbreaking iOS come from hacking communities dedicated to iOS and are not from an official, Apple recognized, source. Organizations should codify their views on jailbreaking into a formal policy that has some bite. If you are concerned about jailbreaking, the linked article is highly recommended as it gives in depth coverage of the topic.
Finally, we come to the burning question: are iOS devices ready for enterprise deployment? Based on the aggressive feature development and commitment to enterprise features on Apple’s part, the features available finally provide enough policy enforcement and control to make the answer to this question “probably so for most organizations”. Each organization will have to weigh the risks and benefits associated with mass deployment of iOS based on an informed understanding of their risk tolerance. From the information security perspective, the tools available are acceptable. The vendor support for MDM is already high and the momentum is great. Businesses have a variety of tools to choose from and a variety of options after choosing their MDM suite. I would not lose a lot of sleep with properly configured iOS devices on my enterprise network. So Google, you have Android devices rapidly leaving store shelves, what are you doing about MDM?