Security firm Skycure recently blogged about risks associated with a technique for configuring iOS devices. Certainly, it's an abuse of trust, but it is not a vulnerability. The author describes it as the "sleeping giant of iOS security" and he's half right. It's "sleeping" in the sense that the technique has been known for nearly three years. But it's not a "giant" vulnerability in the sense that the concern is overblown (it's a vendor I've never heard of trying to make a stink). But it is an interesting article, and you should read it. AppleInside covered the story and it's popped up in a lot of places over the last few days.
iOS devices are highly manageable. An Apple device can accept a variety of "profiles" that instruct the device to do things. Profiles are XML documents that describe what the device should do. Some of these are benign: for example, the profile can: (a) instruct the device put a link on the home screen to a web page, for example the corporate intranet. Others are security-related: for example, (b) instruct the device to implement a non-simple passcode such as a numeric PIN, and a 10-wrong-tries-and-the-device-erases-itself policy. A few are quite powerful, such as (c) the ability to route all traffic through a VPN server.
There are two ways to instruct Apple iOS devices to implement profiles. First, you can use an MDM solution to do it: MDM pushes a master profile down to the device after it is enrolled with the system. This master profile (the "MDM profile") allows the MDM server to dynamically push down, update, and delete additional individual profiles. That's how SilverSky, for example, updates passcode policies and pushes them out to all of our MDM customers. In other words: through the use of a master MDM profile, MDM makes profile distribution dynamic.
The second way to implement policies by distributing static .mobileconfig documents and installing them on the device. The documents get onto the device in one of two ways: (a) sideloading via USB using the Apple Device Configuration Utility or (b) over-the-air via the web. Mobileconfig documents are "usually" encrypted and signed, although they need not be. Thee documents contain one or more profiles, expressed as XML. However, unlike with MDM, after they are installed they can't be updated automatically. The user must uninstall them, and reinstall a new version. My personal iEnroll project (internal & unreleased), uses the static .mobile technique and provides a completely automated implementation.
The article references risks associated with the second method -- static .mobileconfig documents. The author's not-particularly-original insight is that a web server could serve these .mobileconfig documents up and cause the device to install the VPN server config that would divert all traffic through a server of the attacker's choosing. All sorts of network snooping, hijinks and various nastiness, presumably, ensues. To be successful, the user would have to be lured to a web server of the attacker's choice. The server would have to serve up the correct MIME type (application/x-apple-aspen-config), and a .mobileconfig file in the right format (ideally signed with a trusted public certificate). The user would have to agree to install the profile. Apple makes this dialog fairly scary, so the user would not do this by accident.
The .mobileconfig technique Skycure is up a tree about is an older mechanism and has been largely obsolesced by MDM. The overall risk here, in my view is quite low. I think there's a high likelihood this method will be eliminated in the future; it certainly will be if the technique is abused. Given a choice, customers should always choose to use an MDM solution.
In the meantime, regard this article for what it is: useful for "raising awareness" about some of the voodoo of Apple device management. But a giant it ain't.