Apple quietly drops iOS jailbreak detection API

Version 4.2 disables a query to discover compromised OS

Apple apparently has thrown in the towel, quietly dropping in iOS 4.2 an API that was intended to discover if the OS had been compromised and jailbroken.

Apple has disabled, without explanation, a jailbreak detection API in iOS less than six months after introducing it. Device management vendors say the reasons for the decision are a mystery, but insist they can use alternatives to discover if an iPhone, iPod touch or iPad has been modified so they can load and modify applications outside of Apple's iTunes-based App Store.

Jailbroken devices pose a serious security threat to the enterprise. Even if the end user doesn't intend to load malware, he will be completely unaware of malware present in unauthorized apps.

Managing smartphones calls for new realism and flexibility

Apple declined to comment.

The new API was part of a bundle of mobile device management (MDM) APIs released in June with iOS 4.0. These APIs were available to third-party MDM applications, such as AirWatch or Sybase's Afaria. With the new APIs, these servers could access directly a range of features and information in iOS or on the device. But in the recently-released 4.2 version, the API intended for detecting jailbreaks has been either removed or disabled.

This detection API let the MDM applications in effect ask the operating system if it had been compromised. Jailbreak exploits typically change a number of operating system files, and exploit one or another low-level OS features to let users directly load their own or third-party applications. In October 2010, two separate jailbreaks made use of different vulnerabilities uncovered in the iOS boot ROM, for example. Apple warns that jailbreaking voids the device's warranty and could damage the phone.

Previously, some MDM vendors had created their own series of OS checks to detect jailbreaks, analogous to those performed by an anti-virus application on a PC, to discover if a jailbreak had occurred.

But the new detection API gave these applications direct access to information in the OS. In theory, the iOS device then "confesses" that it has been jailbroken, thereby triggering automatic responses such as alerting the helpdesk or shutting down access to corporate Exchange Server e-mail.

"We used it when it was available, but as an adjunct," says Joe Owen, vice president of engineering at Sybase, which offers the Afaria device management software. "I'm not sure what motivated their removing that....I've not had anyone [at enterprise customer sites] talk to me about this API being present or being removed."

In practice, Apple's idea of using an API-based query turned out to be much more complicated than it sounds. "It's an interesting concept - asking the OS to tell you if it has been compromised," Owen says. "Because a smart attacker might first change that very part of the OS. Jailbreaks often get better and better at disguising the fact that anything has been compromised."

When that happens, the API in effect either lies about or is simply unaware of the jailbreak.

"[I]t may be feasible to detect jailbreaks of a specific version or type, but they will still be trapped in the cat and mouse game they play with jailbreakers," says Jeremy Allen, principal consultant with Intrepidus Group, a security consulting firm. "Whatever they add [in the OS] to detect the jailbreak, if it is to be queried from the iOS kernel, it must be accessible and have the ability to be changed. Meaning, if it is going to be a useful detection method it can also be circumvented. It is a fairly intractable problem to solve 100%."

For a group of computer-savvy end users, jailbreaking is an unalloyed benefit, not to mention a civil right, letting them load any applications they wish. But for enterprise IT, jailbroken iOS devices create a serious security threat.

"When jailbreaking and or rooting a [mobile] device, the goal is to circumvent or disable the pieces of the OS and platform that keep applications in a sandbox and running with limited privileges," Allen wrote in a recent blogpost on trusting mobile platforms. "These devices could be difficult, or even impossible, to enforce security policy on as the user can trivially circumvent the policy enforcement without the management servers being aware of it."

MDM vendors such as Good Technology, MobileIron and Sybase all claim to be able to detect jailbroken iOS devices without the disabled Apple API. Typically, their on-device apps, in conjunction with the server, run a series of checks or try to do things that are forbidden by Apple, such as accessing certain underlying OS primitives. If the app can take these actions, it reports back that the device is jailbroken, and then can block or restrict access to the corporate network.

These techniques are not foolproof, cautions Intrepidus' Jeremy Allen.

"These methods cannot be relied upon with a high degree of confidence, but they would certainly catch many who jailbreak, just not all of them," he says. "I see it as a useful tool, but not an all-encompassing solution."

Allen strongly encourages enterprises to take a multi-layered approach and be realistic about the risks. "I always stress, heavily, [the importance of] educating users about the risks of jailbreaking," he says. "I feel that organizations must outline, in formal policy, that jailbreaking is not permitted. Many users are simply unaware of the risks associated with operating a jailbroken device."

Given the ongoing ingenuity of hackers, enterprises have to be plan accordingly, Allen warns. "For the users that still engage in jailbreaking, with full knowledge of the risks and detection mechanisms, there is little recourse to finding them," he says.

John Cox covers wireless networking and mobile computing for "Network World."

Twitter: http://twitter.com/johnwcoxnww

Blog RSS feed: http://www.networkworld.com/community/blog/2989/feed

Insider Shootout: Best security tools for small business
Editors' Picks
Join the discussion
Be the first to comment on this article. Our Commenting Policies