iOS 4.3.3 Security

A guide to deploying iPads, iPhones, and iPods on your network

This work was introduced at B-Sides St. John's on 10-Jun-2011 as "iPads: Love'em, Hate'em, You're Going to Have to Deal With'em".

The document is about 10 000 words and should take about 40 minutes to read. its formatted for easy reading but also for import into Instapaper or Read It Later.

Table of Contents

Introduction & Approach

Since its announcement in early 2007Carmo-R.2007.01, the iPhone has held the lion's share of the mobile market...both in profit, units deployed, and mindshare.

Apple quickly built on the iPhone's success, using the same operating system to launch the iPod Touch in the fall of 2007Wikipedia.2011.01. Since the initial release, the operating system on these devices---now known as iOS---has continued to mature.

Now in its 4th major revision---with the 5th just announced---iOS now runs on 200 million iPhones, iPods, and as of April, 2010Wikipedia.2011.02 the iPad (25/200 millionSavov-V.2011.01).

With its prevalence in the consumer market it was inevitable that these devices would make their way into the enterprise. Apple recognized this trend and with the 4th version of iOS started to include features that addressed the needs of its enterprise customers.

This document analyzes the security issues surrounding these devices and provides guidance on how to implement and maintain a secure deployment of iPhones, iPods, and/or iPads in your environment.

Document Conventions

Differences between iPhone, iPad, and iPod models are usually apparent (e.g., faster processer, higher resolution display, 3G capability, etc.) and for the purposes of this piece are largely irrelevant. iOS provides similar functionality to all three classes of device. Therefore, unless otherwise noted, I'll use iPhone, iPad, and iPod interchangably or I'll collectively refer to "the devices".

If specific functionality only applies to one device, I will clearly indicate the restrictions.

All information in this document applies to iOS version 4.3.3 which is the latest production version as of 10-Jun-2011.

iOS Overview

High Level Design

iOS is the foundation underpinning the success of these devices. The operating system [OS] provides a set of core functionality upon which applications ("apps" in iOS parlance) can build.

Out of the box, the OS provides enough functionality that a the user can (among other things); - surf the web - send/receive email - make phone calls (iPhone only) - listen to music - view video

Where iOS really starts to shine is when a user customizes the phone with a selection of apps that provide the desired functionality.

Apps are usually designed for quick interactions and are focused on solving a small set of tasks. There are apps for almost any task or just to have some fun.

Each app runs in its own security sandboxApple.2011.03, Apple.2011.17, Apple.2011.19, Apple.2011.03, Apple.2011.17, Apple.2011.19 which isolates its data store and memory---using ASLR, address space layout randomization and DEP, data execution protection---from the rest of the operating system. This isolation ensures that apps don't interfere with other apps on the system from a stability and secure perspective. This also prevents from accessing each other's data.

In addition to the sandbox, iOS supports only a limit set of functionality for background multitasking. Multitasking is limited to;

• background audio
• voice over IP
• background location
• push notifications
• local notifications
• finish a task that the user has started

This set of background services is enough to enhance the functionality of the device while still maintaining the security perimeter for each application.

Every application that runs on iOS must be signed. Either by an enterprise key or the global App Store key. This ensures that only validated code is run on iOS devices.

Signing applications, profiles, and devices is at the heart of the iOS security modelApple.2011.15, Apple.2011.04, Apple.2011.08, Apple.2011.18. In fact, the entire ecosystem (iOS, iTunes, the App Store) is one giant public key infrastructure. This structure gives Apple the ability to revoke an app's key and thus prevent any iOS device from running that appLemos-R.2011.01.

For this document, it is sufficient to know that code must be signed by a recognized authority in order to run on iOS and at any time, that signature can be revoked.

Guiding Principle

Apple is a consumer focused company. They have been extremely successful focusing on design and the overall user experience. Their extensive human interface guidelinesApple.2011.01 show their dedication to the user experience.

Unfortunately this can be at odds with overall security. As iOS matures, more and more concessions are made to security but a positive user experience is always paramount.

Thankfully a clear, concise interface usually leads to better security. Creating an awareness for the user of the impact of their actions not only provides an easier experience but typically increase security by raising awareness. Apple has published guidance for developers to help ensure that the user interface supports a secure environmentApple.2011.21.

By issuing this type of guidance, Apple is demonstrating their awareness that security must be integrated in the design of iOS and its apps.

But make no mistake, when push comes to shoves, the user experience is the only principle that matters when the chips are down.

The Ecosystem

At the start of June, 2011, there are approximately 400 000 apps available for download in the App Store.

These apps run the gamut from gaming to books to business applications. Whatever a users need or wish, there's usually an app available. In fact, that's the marketing tagline, "There's an app for that".

Each app goes through an approval process by Apple in order to ensure that it conforms to platform standards (both technical and for content). Thought the specific review process isn't know, this code review has managed to keep the number of malicious or potential bad actor apps from being publishedLemos-R.2011.01.

Users on the iOS platform are used to being able to download an app at a moments notice.

There is a 30MB (this is an App Store.app limit in combination with the cellular carrier and some carriers have lower limits) limit on download apps over a 3G connection---above 30MB users must use a wifi or USB connection---but most apps fit within this size restriction, so app installation is generally ubiquitous for users.

Due to the ubiquity, this smooth experience quickly fades from novelty to expectation. Therefore when confronted with a task and lacking a tools on their iOS device, most users can expect to download a new tool within seconds in order to solve their problem on the spot.

Needless to say, this expectation presents a security challenge as the ecosystem around iOS pushes strongly towards a dynamic target instead of the traditional "standard image" approach to IT assets.

Attacking iOS

Like any operating system, there is a multitude of angles from which to attack iOS. Because each application is sand-boxedApple.2011.09, is an app is successfully attack the potential impact on the device is minimized...unless the sandbox is breached.

This document will take a look at the successful exploits and known vulnerabilities of iOS as well as some of the current research highlighting the iOS security model's weaknesses.

Safari / WebKit

Safari.app holds a special place in iOS. its the default handler for all http:// URL requests (sidebar: iOS apps primarily communicate with each other by registering with the OS to handle various URL scheme names. The OS then either passes the message to the only registered app or the user gets a "Open In..." menu to select the destination).

In reality Safari.app is really the chrome around the WebKit rendering engine. its important to make this distinction because iOS app makers can embed a WebKit instance into their app very easily using UIWebView (its literally a drag & drop operation).

This means that any vulnerability in Safari.app or in the current iOS version of mobile WebKit can affect almost every application on the device. On the bright side, one update also fixes all of these vulnerabilities.

Though its shares a common codebase, WebKit on iOS does not pose the same risks as a traditional browser. The iOS sandbox, limited multitasking, and lack of a traditional, user accessible file system severely restricts the access a success exploit can gain on the system.

Attacks in the wild against Safari.app have typically resulted in application crashesUS-CERT/NIST.2010.02, US-CERT/NIST.2011.01 and other denials of service. Very few vulnerabilitiesUS-CERT/NIST.2010.01, Live-Hacking.2010.02, US-CERT/NIST.2010.02, US-CERT/NIST.2010.01 and other denials of service. Very few vulnerabilitiesUS-CERT/NIST.2010.01, Live-Hacking.2010.02 have resulted in a privilege escalation putting data on the device at risk.

Jailbreak!

Like any IT asset, iOS devices need to provide a way to recover them is something severely corrupts the OS or otherwise damages their standard operations.

Unfortunately. this functionality can also be leveraged for other means such as attacking iOS.

DFU Mode

For iOS devices, this comes in the form of DFUOSX-Daily.2010.01 or "Device Firmware Update" mode. This mode allows the user to return the device to its factory settings by restoring the operating system.

Of course, this avenue has been exploited early and often---and continuously in an ongoing battle---to circumvent the iOS security architecture by installing custom code on the device.

Once a device is in DFU mode, its operating system can be overwritten or a RAM disk can be used to temporarily access the device's storage without the usual security controls in place.

Unauthorized Apps

Users can "jailbreak" an iOS device in order to install a hacked version of iOS that allows for the installation of unauthorized 3rd party apps. In fact, a parallel app store named Cydia launched that provides a simple UI for installing these applications.

Why would someone jailbreak a phone? Primarily to install apps that Apple will not allow in the App Store. These apps fall into a wide range of categories. Some popular examples are;

• Wi-Fi Sync (synchronize your iTunes library over wi-fi)
• SNES4iPhone (a Super Nintendo emulator)
• MyWi (emulate the Personal Hotspot functionality without carrier approval)

Using a jailbroken phone you can even install Metasploit and the Social Engineering Toolkit which is extremely useful for a security professional but you can readily see why Apple wouldn't want that published in the App Store along side Disney games for kids.

Imaging

Another legitimate use of DFU mode is to take a forensic image of the device. DFU mode allows for a connected workstation to create a block level copy of the device for later analysis.

This can be done without any significant artefacts being created on the device. its important to note that this can be done while the device is locked with a passcode. The file system will remain encrypted but the image can still be acquired.

Broken Sandbox

When a device is using a jailbroken version of iOS, it can run any Objective-C code it desires. This means that all of the iOS API protections can no longer be counted on.

Therefore allowing jailbroken devices in your corporate deployment poses a significant risk as they are not forced to comply with the technical controls you've put in place.

Jailbreaking leaves forensic artefacts on the device that can be detected during analysis but this does not help is maintaining the integrity of your network since you have to have possession of the device in order to perform this analysis.

The current crop of MDM---Mobile Device Management---vendor supports various forms of detecting jailbroken devices over the air. As with jailbreaking itself, this is a constant back and forth game of detection and concealment.

Fraunhofer Study

The Fraunhofer studyHeider-Jens.and.Boll-Matthias.2011.01 by Jens Heider and Matthias Bol was released in February of 2011 and drew a lot of media attention.

The work of Heider and Bol demonstrated that various credentials were easily accessible to an attacker even if the device was locked with a passcode.

In order to execute the attack, the author posit that the attacker has physical access to the device but that the device is locked with a complex passcode and data protection is enabled. This aligns with the typical state of a lost or stolen device in a secure deployment.

Leveraging DFU mode, the attack can run a simple script that extracts the following credentials from the locked device;

• Apple Push
• Apple-token-sync (Mobile Me)
• CalDav
• Google Mail as MS Exchange Account
• iChat.VeniceRegistrationAgent
• LDAP
• Lockdown daemon certificate
• MS Exchange
• Voicemail
• VPN IPsec
• VPN XAuth
• VPN PPP Password
• WiFi (Company WPA with LEAP)
• WiFi WPA

Of particular concern is the accessibility of MS Exchange and VPN credentials and the device's lockdown daemon certificate.

Exposure of MS Exchange and VPN credentials is a risk that should already be addressed in the analysis of those systems so it won't re-iterate here.

The lockdown daemon certificate is an iOS specific risk. This certificate is used to secure the users passcode on the device and in the backups. Attaining the certificate is the first step in breaking the users passcode and has significant implications.

ElcomSoft

ElcomSoft released an update to their Phone Password BreakElcomSoft-Co-Ltd.2011.02 in May that provides support for iOS devices.

This product is sold in three version; home, professional, and law enforcement. Between home and professional, the difference is straighforward. The professional edition is able to retrieve all of the data from the keychain and can use GPU acceleration in order to execute a brute force attack on the backup image.

The edition for law enforcement is a significant upgrade and adds the ability to work directly on the device to break the passcode. With direct access to the device, you can use the escrow key material from the workstation the device synchronizes with to access all encrypted material on the device.

In addition to the escrow route, this tool allows for a brute force attack on the passcode without triggering Apple's brute force protection (where it locks the device for successively longer periods of time before wiping the data store).

This bruteforce attack uses the UID on the deviceSchneier-B.2011.01 to extract the key material so the image of the device can be decrypted and analyzed on a forensic workstation.

This entire process can take a significant amount of time, up to 3 hours to extract the image and longer to brute-force the key material (depending on passcode length).

Due to the length of this process, an attacker must have possession of the device for an extended length of time. This is not an attack that can be done quickly.

This gives the victim time to report the loss of their device, their accounts deactivated, and a remote wipe attempted. In this scenario it is unlikely that a remote wipe would be success as an attacker would most likely remove the 3G SIM card from the device and wifi is not enabled in DFU mode.

Sogeti Research

Two researchers from Sogeti, Jean-Baptiste Bédrune & Jean Sigwald, have published detailed information that can be used to replicate most of the functionality present in the Elcomsoft tool.

The Sogeti research details iOS data protection functionality; encryption methods, key management, and iTunes backups. This research provides deep insight into how Apple has layered security into the operating system.

While the technical implementation details are interesting, the benefit of this research to the vast majority of security professionals---and unfortunately attackers---is the toolset they've releasedBédrune-J-B.and.Sigwal-J.2011.02 under a BSD license.

This toolset provides a lot of the same functionality as the ElcomSoft tool discussed above but lacks the cohesive UI. With a little patience, similar results can be achieved.

Location

In April of 2011, a number of media outlets ran with the story that iOS was collecting and transmitting location information on the user and sending that information back to Apple without user consent.

At the heart of the matter, the geocache of cellular and wifi signals is used to help aid with faster aGPS [assisted GPS] lookups in iOS was stored unencrypted in the iOS backup and on the device.

The primary issue was the ease at which this information could be mapped to provide a rough map of the users location as it changes over time.

In the wrong hands, that information could be dangerous. This is a common threat facing all location-based services and devices that use these services.

With the release of iOS 4.3.3, Apple has made several changesPatel-N.2011.01 to this data in order to mitigation any potential threat; - the geocache is no longer backed up by iTunes - only 7 days of location data is stored - turning off Location Services removes the geocache entirely

Connectivity

The iPhone and iPod--and to a lesser extend the iPad--are designed for quick interactions. Requiring a rigorous authentication scheme every time a mobile user wants to access a corporate resource is only going to create frustration.

However, the easier you make it for the user to gain access to corporate resources, the easier it is for an attacker as well.

The following sections will address various methods of connecting these devices to an enterprise network.

3G or Wifi

Modern iOS devices use either 3G cellular or wifi (b/g/n) to connect to the outside world. The iPhone offers both, the iPad offers the option of adding 3G to the base wifi, and the iPod Touch is only available with wifi capabilities.

While 3G may be slightly safer given the difficult of a casual intercept (when compared to wifi), carrier interception can and does happen. The risks associated with both 3G data (and voice for iPhone) and wifi connections have been well hashed out so they will not be repeated here.

Though it does deserve to be reiterated that any connection over wifi is extremely vulnerable to attack and every precaution should be taken.

Personal Hotspot

This iPhone-only feature allows the iPhone to act as a bridge a wifi or 3G connection to other devices using; - USB - Bluetooth - or Wifi

Both USB and Bluetooth only allow for 1 other device to connect (e.g., laptop <-> iPhone <-> internet) but a wifi bridge can connect up to 5 clients.

This feature has been present in previous versions of iOS, but only recently was it renamed "Personal Hotspot" and wifi bridging added.

The security implications are minimal but it is good to be aware that an iPhone can bridge a wifi connection to other wifi devices.

This isn't immediate apparent to the user though. If the iPhone is connected to a wifi network and the personal hotspot is turned on, the initial wifi connection is terminated. The user is able to manually reconnect if they choose.

A USB or Bluetooth connection just as easy to configure. Thought, Windows users must have iTunes installed in order to use the iPhone as a USB ethernet connection.

The key security safeguard built-in to this feature is that VPN tunnelling is not supported when using the personal hotspot feature regardless of the connection method. If a VPN tunnel is active, it is automatically disconnected when the hotspot is activated.

VPN

Out of the box, iOS supports most standard VPN configurations, including Cisco IPSec, L2TP over IPSec, & PPTPApple.2010.05. If your organization uses an SSL VPN, Juniper, F5, and Cisco have clients available in the App Store.

As with most VPN clients, several combinations of password, two-factor, and certificate-based authentication are possible. Each of this methods has its own balance of usability and security.

However, iOS---being user focused---allows for the local storage of VPN credentials delegating their safety to the overall security of the device.

In addition---as previously discussed---the Fraunhofer Study has proven that these credentials can be successfully removed from the device quite quickly.

With a supported configuration, iOS also supports on-demand VPN tunnelling. Using this technique, when the user interacts with a set of predefined domains a VPN tunnel seamlessly opens encrypting the traffic to these destinations.

Where ever possible, this configuration is recommend as it provides a layer of security without user interaction.

Application & Desktop Virtualization

As the industry pushes virtualization deeper into the technology stack, mobile access has been keeping pace. There are now a host of official clients available for virtualization technologies including; - VMWare View - Citrix Receiver (for XenApp) - 2X Client

These official clients are complimented by a host of SSH and RDP-capable apps that can be used to connect to various virtualized backends.

While the user experience may be question (a pixel accurate point is not the same as a 20+px finger), delivering corporate applications using virtualization typically offers more opportunities for applying security controls.

If you're using an app to connection to virtualized resources in your deployment, you should analyze the artefacts left behind in iOS.

Does the app have zero footprint? Does it leave behind valuable corporate information in a local cache? Can the app transfer documents locally? Are they encrypted locally? Does the app use an encrypted channel for communications?

These any other questions should be answered and the level of risk assessed before proceeding with your deployment.

ActiveSync

Microsoft ActiveSync is the primary over-the-air synchronization protocol for iOS. Microsoft has published the specification which has enabled a number of third party products to support ActiveSync (Google Apps is a prime example).

ActiveSync allows an iOS client to leverage the native apps for mail, calendar, and contacts. In addition, ActiveSync allows for the enforcement of an iOS password policy, remote lock, and remote wipe.

Given that most organizations already run Microsoft Exchange, this greatly eases the integration and basic management of iOS in the enterprise.

Data at Rest

Besides connectivity, you have to address the issue of data resting on the iOS device. The current crop of iOS devices have up to 64GB of local storage. That's more than enough space to store a vast amount of important corporate information.

In addition to raw space, the ability of iOS to handle rich media and complex documents (it natively supports Microsoft Office formats, among others) only increases the likely that sensitive corporate data will finds its way onto an iOS device.

Fortunately, the operating system offers several controls that can be leveraged to secure local data and reduce the risks associated with it.

Data Protection Framework

The Data Protection Framework [DPF] is enabled by default on an iOS devices that ship with version 4 or higher. Version 3 devices, need to manually enable the framework when they upgrade to iOS 4Apple.2010.06.

The primary function of the framework is to faction your passcode into the encryption scheme used to protect local data storage. Previously, only the device key was used making it trivial to remove the encryption.

In addition to this base layer, DPF also offers file level encryption APIs that app makers can take advantage of to provide additional protection to local data.

The downside is that there is no way for the user to tell if a file is encrypted using this API. If it up to the app maker to advertise the fact and that still leaves no way to verify the claim.

However---when used---these APIs provide a 2nd level of encryption with another set of keys (this time the apps) adding an additional roadblock for an attacker to overcome.

Mail.app, Calendar.app, and Contacts.app fully support these APIs which means that any corporate data configured to use these apps (e.g. via Exchange ActiveSync) has an additional layer of security automatically applied.

The implementation is solid, having been by various 3rd parties. In fact, when the device is locked with a passcode, even Mail.app can't access its own data!

Document Interchange

Document Interchange is another feature that is new to iOS version 4. Most often appearing to the user as the "Open in..." menu, this feature provides apps an approved method to transfer data between them and their sandboxes.

The interchange is an opt-in feature that is implement on a per-app basis. Each apps much register with the operating system as capable of handling specific document types.

When the user selects "Open in..." a copy of the data is then made in the destination apps sandbox. This is a key distinction. If the source app uses file level encryption, this layer of protection is removed during the interchange and its up to the destination app to re-encrypt the file with its app key. This requires the destination app to also support file level encryption.

Besides the issue of file encryption, you know have 2 or more copies of the data locally. This increases the risk profile associated with the data. Though the original app may have been secure, what if the destination app has a vulnerability and an attacker is able to exploit it?

Backups

By default each time an iOS device connects to its home workstation (the one it was configured on), it attempts to synchronize.

The first step in the synchronization process is a full backup of the device.

While incredibly handy for the user, these backups do pose a security risk.

The ElcomSoft productElcomSoft-Co-Ltd.2011.02 and the tools published by the Sogeti research teamBédrune-J-B.and.Sigwal-J.2011.02, ElcomSoft-Co-Ltd.2011.02 and the tools published by the Sogeti research teamBédrune-J-B.and.Sigwal-J.2011.02 are capable of working against the backups that iTunes creates.

While these tools can provide access to the entire device data set, various pieces of that data such (e.g., until recently the location geocacheChen-B.and.Isaac-M.2011.01) that are unencrypted are available in the backup.

If you choose, iTunes can be configured to not backup devices automatically. This will impact the recoverability of a device but may also reduce the threat.

A better choice may be to enforce a backup password. This password is used as part of the key to encrypt the device backup so that the password must be used in order to restore the device and an attacker must use a brute-force attack in order to access the data in the backup.

iTunes

For nowApple.2011.22, iTunes is a required part of the iOS ecosystem. iTunes is required to fully setup a device, natively sync to it, back it up, and to upgrade & patch it.

iTunes also acts as an app repository for installed and removed applications and it provides file transfer services. Don't let the name fool you, iTunes provides a lot more services to iOS than simple music.

Maintenance

As a full desktop application iTunes itself must be considering when planning your deployment. In addition to the possibility of security vulnerabilities, iTunes also includes the WebKit browsing for viewing the iTunes Store.

This browsing engine contains the same vulnerabilities as any other WebKit installation and though the likelihood of an exploit is much lower---iTunes can only visit and view limited content---the application still much be updated on a regular basis.

iTunes provides a handy auto-update feature to help address this issue. The challenge is that the Windows version also prompts the user to install other Apple software such as Safari which you might not want on your corporate network.

iTunes also act as a "home sharing" hub which uses BonjourApple.2011.02 to auto-discover home sharing compatible devices on the network. In a home environment, this isn't a problem but in a managed, enterprise network iTunes' network chatter can be quite the annoyance.

Fortunately, iTunes can be configured to reduce its network activities at the cost of the functionality. You will have to evaluate the trade-offs in order to find the right balance for your environment.

OS upgrades for iOS

Until iOS 5Apple.2011.22 is released, any path or update to iOS must still be conducted through iTunes (though developers can use XCode).

This makes it extremely difficult and laborious to keep a large deployment of iOS devices up to date. Each much be manually upgraded to the latest codebase. While major revisions are reasonably spaced, in some circumstances double dot releases (e.g., 4.3.2 and 4.3.3) can follow quickly one after the other as specific issues are identified and need to be addressed.

File Transfer

If there is one hole in the overall user experience for iOS devices, file transfer to specific applications is it. And its a gaping, massive, black hole.

In iTunes under the individual device's "Apps" tab, at the bottom of the page, a set of list boxes is provided that lets a user add and remove files from a specific app's sandbox.

This is a tedious and frustrating process which is why most apps that needs a steady stream of files use some form of cloud service (typically Dropbox and soon to be iCloudApple.2011.22).

These services provide a vastly superior experience which explains Apples announcement of iCloudApple.2011.22.

From a security perspective, cloud services raise a host of questions that need to be addressed in order to understand the risk of deployment.

How is the data protected in transit? At rest? Who can access it? Where is it? These and many more questions need to be answered though this problem is not unique to iOS.

Management

iOS version 4 finally introduced much needed enterprise management features. This feature set falls short of what RIM provides for the BlackBerry or what is possible with Android and some custom programming.

Several constructs exist within iOS to help manage devices. With each version of the operating system, these constructs mature and make it easier to ensure the operations of your iOS deployment.

Profiles

The "iPhone Configuration Utility" is an app that can be used to create Configuration Profiles that are the heart of iOS device management.

These profile can contain one or several sections of settings that configure the device they are applied to.

The majority of these sections simply replicate the functionality found in Settings.app within iOS but there are a few addition sections such as Mobile Device Management [MDM], Simple Certificate Enrolment Protocol [SCEP], Credentials (for PKCS1 & PKCS12 certificate deployment) that are only available via configuration profiles.

Profiles created with the utility can be deployed via a web server, over USB to the device, via MDM, or even through email.

Profiles layer on top of each and can be configured as removable, removable with an administrative password, or never removable.

The concept of profile layering is important. The most restrictive setting for each section is applied regardless of profile. Therefore if you deploy 2 profiles to a device and each specifies passcode strength. The most complex requirement would be enforced.

This ability to create small profiles and deploy them in a group, adds much needed granularity to an otherwise clunky process.

ActiveSync

Microsoft's ActiveSync protocolMicrosoft-Inc.2011.01 can be used to enforce some policies on iOS devices. The password strength, encryption, and timeout features are all supported.

Additionally, ActiveSync can be leveraged for remote lock and remove wipe of a device.

For the average user, ActiveSync provides corporate support for the ability to stay in touch they've come to expect through personal use of iOS devices and corporate use of BlackBerry devices.

Near real time notification of new mail messages, appointments, and contacts are all possible using ActiveSync. This provides iOS with similar functionality as the ubiquitous BlackBerry.

MDM

Mobile Device Management [MDM] is framework in iOS that allows 3rd party companies to build servers capable of managing iOS devices.

This framework allows for over the air deployment and enforcement of configuration profiles. Unfortunately, the MDM framework does not add any functionality that is not already available through the direct application of configuration profiles.

MDM servers add value by centralizing and automating the application and maintenance of configuration profiles.

Good, AirWatch, and MobileIron continue to lead in this space.

These products act as MDM servers and some can manage other mobile clients---such as BlackBerry and Android---as well.

Support for MDM continues to evolve and though no announcements have been made yet, expect this functionality to improve with iOS 5.

App Installation & Updates

Apps can be installed through the App Store (which is actually different in each country Apple operates in) or they can be developed and deployed internal in the enterprise.

In-house Development

An MDM server can help automate the setup of an enterprise deployment architecture but the steps can be accomplished manually as well.

At a high level these steps are; - register for an enterprise development key (part of Apples iOS developer program) - sign the app using the enterprise's key - install a distribution provisioning profile on each iOS device - deploy the signed app to the devices

While cumbersome, these steps maintain the security framework of the operating system ensuring that only signed code is deployed to the endpoint.

When using this model, the standard set of threats associated with development apply. In addition to these threats, you must take care to securely store the enterprise signing key. If this key is stolen, it is crucial that it is reported to Apple immediately so they can revoke the key.

If the key isn't revoked, anyone can sign their apps using your enterprise key potentially impugning your reputation.

Approving App Installation

Controlling the apps deployed on various enterprise endpoints is a standard security control. With iOS this is extremely difficult.

Due to its origins as a consumer product, the standard deployment channel for apps is via the App Store.

Each iOS device can be associated with one App/iTunes Store account. Each App Store account can be associated with up to 5 devices belonging to one person (more on these restrictions in the next section, "Licensing").

In order to install (and purchase) an app, the user must sign into the App Store using an email/password combination. If the user has these credentials, the only option available for enterprise management is to either allow or prevent the installation of apps. There is no other practical level of granularity available.

Some MDM products do offer the ability to manage the set of install apps but they do so by automated the following process; - remove a profile that prevents the installation of apps - deploy an internal app or verify the signature of an app downloaded from the App Store - re-apply the profile that prevents the installation of apps

As you can tell, this is not a smooth process. It is functional when automated using an MDM server but it is error prone and can be frustrating for the user.

Licensing

Again showing its roots as a consumer product, apps downloaded (either purchased or free) from the App Store are licensed for use on up to 5 iOS devices belonging to the same individual.

There are no exceptions made for corporations or other organizations.Apple is working on providing another solution but there are significant roadblocks. All 400 000+ apps in the App Store have been developed and deployed under the current licensing structure and---even if Apple can develop an organization-friendly option---changing the licensing scheme for existing apps may prove challenge.

In the mean time, ownership of the apps and payment can prove challenging for organizations.

If each iOS device is associated to a personal iTunes Store account, some organizations allow their employees to expenses required app purchases or provide gift cards (virtual ones are available in the iTunes Store) to facilitate purchasing.

This still leaves the question of media ownership on the table. As easy as it is to buy a new app from the App Store, its just as easy to buy a movie, video, or book.

Who own's the license to these media files? Who's responsible for backing them up? What is your organization's stance on personal information & media on a corporate asset? These questions are not strictly information security questions but should be raised to the proper business leaders within the organization.

Remote Lock, Remote Wipe, & Remote Locate

If a device is configured with an ActiveSync account, remote wipe and remote lock functionality is support if the server can send the correct notification (e.g., Exchange Server supports this, Google Apps for Domains does not).

While no guaranteed to be successful, the ability to remotely wipe the local storage on an iOS device is a solid control to have in place.

By educating users to contact their support team immediate when a device is suspected lost or stolen, security teams at least have a shot at wiping the data on the phone.

When the device received a remote wipe command, the first step it takes is to destroy the primary key material used to encrypt the local data storage. It then proceed to delete and then overwrite the local data (which is still encrypted and inaccessible).

The approach makes it likely that any device receiving a remote wipe command is effectively returned to factory new condition. It is extremely unlikely---though theoretically possible---that the key material and the entire encrypted will be recovered from the physical media, reconstructed, and then cracked.

Recommendations

Approach

Based on the stated risks and possible mitigations, I recommend the following for an iOS deployment;

• read the full set of documents that Apple provides for deploying iOS
• full ActiveSync remote synchronization for email, calendar, and contacts
• on demand VPN tunnelling for corporate intranet resources
• leverage an MDM for easier configuration profile and device management (including remote wipe and location)
• a strong configuration profile as detailed below
• restricted iTunes installation as detailed below
• create a clear policy on the responsibilities for app and media purchases via the iTunes store
• conduct a detailed user awareness campaign emphasizing the security aspects of the deployment
• restricting the sensitivity of the data stored locally on the device
• clear recommendations and review services for apps installed on the devices
• regular reviews of the effectiveness of the technology and related policies

Connectivity

Regardless of 3G or wifi, any connection back to the enterprise should occur over a VPN when possible. Ideally, rollout on-demand VPN with any corporate and partner domains setup as requiring VPN access.

I believe that on-demand VPN is a better security control because it takes the user out of the equation. The VPN tunnel is automatically created whenever a designated resource is requested. This eliminates the requirement to train the user to manually connect the VPN tunnel. Any steps that can be taken to lower security further down the technology stack in an automated fashion should be implemented.

Data At Rest

As proven in the Fraunhofer Study, with the ElcomSoft product, and Sogeti toolsets, data on an iOS device is not longer safe if an attacker has physical access for an extended period of time.

Using apps that fully leverage the data protection framework for file level encryption will help make the task of stealing your data take longer but this only delays the inevitable.

In a deployment, ensure that remote wipe functionality is available and educate the user community on the importance of quickly reporting a lost or stolen device. It only takes a few minutes to restore a device from a current backup. A small price to pay to potentially preserve corporate data.

Apart from remote wipe, the only other reasonable safeguard is to limit the amount of sensitive data stored on these devices. This is a not a recommendation based on a shortcoming in iOS but for all mobile devices.

Most information security safeguards can be defeated with physical access to the device. For a data center, this may not be too much of an issue but for a mobile device---especially one as high a theft target as the iPad--its a major issue.

iTunes

Little known fact; you can customize the iTunes installation package using command line switches. Since most corporate environments run on Windows, I'll cover those settings here. Equivalents exist for Mac OS X.

There are two primary concerns with iTunes on most corporate networks; automatic updating outside of the organizations change management process and the Bonjour networking protocol.

If your organization has a strong change management framework, you probably disable software auto-updating. Doing this in iTunes has the added advantage of preventing Apple from prompting your users to download Safari and other Apple products and their updates as well. Once you disable this functionality, be sure to include iTunes in your standard software support lifecycle. Remember, iTunes does provide browser-based functionality and therefore has the usual browser security risks.

• NO_ASUW=1 -> this will disable automatic updates

Bonjour is a fantastic auto-discovery protocol and its what makes your home network services just work with iOS (AirPlay is a great example). In a corporate network, auto-discovery services can be problematic if you're not expecting them. In addition to the extra traffic, Bonjour has very specific requirements in order to work across subnets. Most corporate installations will simply disable Bonjour.

• NO_BONJOUR=1 -> this disables the Bonjour networking protocol

Another challenge with iTunes will depend on your network streaming policy. If you restrict video and audio streaming, you can disable this functionality in iTunes. In Windows, this is accomplished via a registry key. This registry key can also be used to force encrypted backups of iOS devices.

In the registry (as per http://support.apple.com/kb/HT2102) set kParentalFlags_Locked and then:

• kParentalFlags_DisableRadio
• kParentalFlags_DisableSharing
• kParentalFlags_DisableCheckForUpdates
• kParentalFlags_DisableOpenStream
• kParentalFlags_DisableAppleTV
• kParentalFlags_DisablePlugins
• kParentalFlags_RequireEncryptedBackups

Management

As a starting point, I recommend the following configuration profile. Please feel free to use this or use it as a template for your own profile;

• General
  • Security: With Authorization or Never _ Passcode
• Passcode
  • Require passcode on the device = enabled
  • Require alphanumeric value = enabled
  • Minimum passcode length = 8
  • Minimum number of complex characters = 2
  • Maximum passcode age = 60 days
  • Auto-Lock = 5 minutes
  • Passcode history = 5
  • Grace period of device lock = 1 minute
  • Maximum number of failed attempts = 7
• Restrictions
  • Allow screen capture = disabled
  • Force encrypted backups = enabled
  • Allow use of Safari
  • Enable autofill = disabled
  • Force fraud warning = enabled
  • Enable JavaScript = enabled
  • Block pop-ups = enabled
  • Accept cookies = From visited sites
• Wi-Fi -> set as required
• VPN -> set as required
• Email -> as required
  • enable Use SSL whenever possible for incoming and outgoing
• Exchange ActiveSync
  • Use SSL = enabled
  • Include Authentication Credential Passphrase = disabled
• LDAP
  • Use SSL = enabled
• CalDAV
  • Use SSL = enabled
• CardDAV
  • Use SSL = enabled
• Subscribed Calendars
  • Use SSL = enabled
• Web Clips -> set as required
• Credentials -> set as required for NAC and VPN access
• SCEP -> set as required
• Mobile Device Management -> set as required
• Advanced -> set as required

Conclusion

iOS focuses on the user and their overall computing experience. While users love this approach, it can be problematic for information security professionals trying to secure the deployment of these devices.

With a little preparation it is possible to significantly reduce the risk these devices pose to your organization but only with a managed approach.

The worst possible method of rolling out iOS is one-by-one device deployments. A centralized approach with security as a core principle of the strategy is a must.

Apple provides the basic toolset for securing iOS for free. While it may not be as slick as a full MDM product, it will reduce the risks these devices pose to your organization.

iOS and security can co-exist using the current production version and with the announced features in iOS 5, things will only get better.

References

1. 148Apps.biz (2011). App Store Metrics [Website]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/1

2. Apple Inc. (2010). iOS 4: Understanding data protection [Webpage]. Apple Support, 1, December. Retrieved June 7, 2011, from http://markn.ca/2011/ios4/ref/2

3. Apple Inc. (2010). iPad in Business, Security Overview [PDF]. Apple.com, April. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/3

4. Apple Inc. (2010). iPhone in Business, Virtual Private Networks [PDF]. Apple.com, June. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/4

5. Apple Inc. (2010). iPhone in Business, Wi-Fi [PDF]. Apple.com, June. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/5

6. Apple Inc. (2010). iPhone OS, Enterprise Deployment Guide [PDF]. Apple.com, Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/6

7. Apple Inc. (2010). iTunes Store - Terms And Conditions [Webpage]. Apple.com, 21, June. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/7

8. Apple Inc. (2011). About the security content of iOS 4.3 [Webpage]. Apple Support, 09, March. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/8

9. Apple Inc. (2011). About the security content of iOS 4.3.2 Software Update [Webpage]. Apple Support, 14, April. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/9

10. Apple Inc. (2011). Apple - iOS 5 - See new features included in iOS 5 [Webpage]. Apple.com, 6, June. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/10

11. Apple Inc. (2011). Application Interfaces That Enhance Security [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/11

12. Apple Inc. (2011). Bonjour, Reference Source Code [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/12

13. Apple Inc. (2011). Certificate, Key, and Trust Services Reference [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/13

14. Apple Inc. (2011). How to set up Find My iPad [Webpage]. Apple.com, Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/14

15. Apple Inc. (2011). Introduction to Secure Coding Guidelines [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/15

16. Apple Inc. (2011). Introduction to Security Overview [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/16

17. Apple Inc. (2011). iOS Application Programming Guide [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/17

18. Apple Inc. (2011). iOS Development Guide [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/18

19. Apple Inc. (2011). iOS Human Intergace Guidelines [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/19

20. Apple Inc. (2011). iPhone 4 Features [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/20

21. Apple Inc. (2011). iPhone and iPod touch: About backups [Webpage]. Apple Support, 26, may. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/21

22. Apple Inc. (2011). Keychain Services Programming Guide [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/22

23. Apple Inc. (2011). Keychain Services Reference [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/23

24. Apple Inc. (2011). Mac OS X and iOS Security Services [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/24

25. Apple Inc. (2011). NSData Class Reference [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/25

26. Apple Inc. (2011). Security Architecture [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/26

27. Apple Inc. (2011). The Application Runtime Environment [Webpage]. iOS Developer Library, 24, February. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/27

28. Apple Inc. (2011). The Security Landscape [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/28

29. Apple Inc. (2011). UIDocumentInteractionControllerDelegate Protocol Reference [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/29

30. Apple Inc. (2011). Windows OS Managed Client: How to manage iTunes control features [Webpage]. Apple Support, 8, April. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/30

31. Bédrune, Jean-Baptiste (2011). HitB2011AMS: iPhone Data Protection in-Depth [Webpage]. Cupfighter.net, 20, May. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/31

32. Bédrune, Jean-Baptiste, and Sigwal, Jean (2011). iPhone Data Protection in Depth [PDF]. Sogeti, 20, May. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/32

33. Bédrune, Jean-Baptiste, and Sigwal, Jean (2011). iphone-dataprotection [Webpage]. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/33

34. Birnale, Avinash (2010). Apple's iOS 4 (iPhone) and enterprise support [Webpage]. AB's Blog, 26, June. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/34

35. Carmo, Rui (2007). The iPhone Timeline [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/35

36. Chen-B.and.Isaac-M.2011.01Chen, Brian X., and Isaac, Mike (2011). Why You Should Care About the iPhone Location-Tracking Issue [Webpage]. Wired, 22, April. Retrieved June 7, 2011, from http://markn.ca/2011/ios4/ref/36

37. ElcomSoft Co. Ltd. (2011). Elcomsoft Phone Password Breaker [Webpage]. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/37

38. ElcomSoft Co. Ltd. (2011). Enhanced Forensic Access To iPhone/iPad/iPod Devices Running iOS 4 [Webpage]. ElcomSoft Proactive Software, Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/38

39. Heider, Jens, and Boll, Matthias (2011). Lost iPhone? Lost Passwords! [Webpage]. Fraunhofer SIT, 9, February. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/39

40. Kramer, Staci (2011). Apple iTunes And The Cloud: The Fine Print [Webpage]. paidContent.org, 6, June. Retrieved June 7, 2011, from http://markn.ca/2011/ios4/ref/40

41. Lemos, Robert (2011). Apple iOS: Why its the most secure OS, period [Webpage]. Infoworld, 6, June. Retrieved June 7, 2011, from http://markn.ca/2011/ios4/ref/41

42. Live Hacking (2010). Apple iPhone, iPad, iPod Code Execution and Sandbox Bypass [Webpage]. Live Hacking, 5, August. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/42

43. Live Hacking (2010). Safari in iPhone is Vulnerable to Web Attacks by Hiding Address Bar [Webpage]. Live Hacking, 30, November. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/43

44. Live Hacking (2011). Apple iOS Networking Packet Filter Rules Local Privilege Escalation Vulnerability [Webpage]. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/44

45. Microsoft Inc. (2011). [MS-ASPROV]: ActiveSync Provisioning Protocol Specification [Webpage]. MSDN, Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/45

46. Miller, Charlie, Honoroff, Jake, and Mason, Joshua (2007). Exploiting the iPhone [Webpage]. Independent Security Evaluators, 23, July. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/46

47. Morrissey, Sean (2010). iOS Forensic Analysis: for iPhone, iPad, and iPod touch (1st ed.). Apress.

48. Murph, Darren (2011). WWDC 2011 liveblog: Steve Jobs talks iOS 5, OS X Lion, iCloud and more! [Webpage]. Engadget.com, 6, June. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/47

49. OSX Daily (2010). iPhone DFU mode explained, and how to enter DFU mode on your iPhone [Webpage]. OSX Daily, 24, June. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/48

50. Patel, Nilay (2011). Apple releases iOS 4.3.3 for iPhone, fixes location-tracking bugs [Webpage]. This is my next, 4, May. Retrieved June 7, 2011, from http://markn.ca/2011/ios4/ref/49

51. Savov, Vlad (2011). Apple's iOS 5: all the details [Webpage]. Engadget.com, 6, June. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/50

52. Schneier, Bruce (2011). Apple's iOS 4 Hardware Encryption Cracked [Webpage]. Schneier on Security, 27, May. Retrieved June 7, 2011, from http://markn.ca/2011/ios4/ref/51

53. Schulman, Jacob (2011). Apple iOS 5 hands-on preview [Webpage]. Endgadget.com, 6, June. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/52

54. TheiPhoneWiki.com (2011). Timeline [Webpage]. Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/53

55. US-CERT/NIST (2010). Vulnerability Summary for CVE-2010-0157 [Webpage]. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/54

56. US-CERT/NIST (2010). Vulnerability Summary for CVE-2010-3830 [Webpage]. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/55

57. US-CERT/NIST (2011). Vulnerability Summary for CVE-2011-0158 [Webpage]. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/56

58. Vance, Anthony (2010). Limitations of Data Protections in iOS4 [Webpage]. AnthonyVance.com, 24, June. Retrieved June 5, 2011, from http://markn.ca/2011/ios4/ref/57

59. Wikipedia (2011). iPad [Webpage]. Wikipedia, The Free Encyclopedia, Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/58

60. Wikipedia (2011). iPod Touch [Webpage]. Wikipedia, The Free Encyclopedia, Retrieved June 6, 2011, from http://markn.ca/2011/ios4/ref/59