Jailbreak Detection in iOS

Organizations are subject to all kinds of auditable compliance standards and having a clear set of measurable benchmarks is an important basis on which to build an information security program. But we need to recognize that just complying with the “letter of the law” or with a pedantic mindset is missing the forest for the trees. Threat actors evolve rapidly so while the compliance “rules” under which we operate are a very useful framework and help us assume a security-first mindset, they should also be taken as a set of guiding principals but the specific requirements they enumerate are far from the end of the story.

It’s kind of like the common criticism of “No child left behind” where schools start teaching for the test instead of creating real learning. Similarly, we as InfoSec professionals can spend all our time figuring out how we’re going to pass the audit and not enough time looking at what’s actually going on in our environment. Information Security needs to protect users against real world threats, even if they had not yet been conceived when a compliance standard was written.

Here’s an example requirement from HiTrust…

The organization prohibits the circumvention of built-in security controls on mobile devices (e.g., jailbreaking or rooting)

So when we look for a mobile device management system, we’ll insist the vendors address this for us. We have read the requirement and taken it to be saying, “We need to have a system in place to detect jailbroken devices.” That’s not at all unreasonable, but it doesn’t actually work, so it’s not going to be so easy to pass the buck. And if we re-read the requirement, we’ll see that’s not what it actually says.

The MDM vendors who try to detect jailbreak basically have some app that gets installed on the devices. When it runs, it tries to do something that a non-compromised mobile device OS should not allow… like write some data outside the app’s sandbox. But threat actors obviously know this and can adapt far, far faster than any MDM vendor, and that is just the way it is.

Take a look at this popular project… https://resources.infosecinstitute.com/topic/ios-application-security-part-44-bypassing-jailbreak-detection-using-xcon/. They are identifying every conceivable indicator of compromise and creating hooks so detections don’t work. https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md is an interesting discussion of some common indicators of compromise and how detection can be prevented. The never-ending cat and mouse/leapfrog game going on here is not just between Apple and jailbreak developers, but also between Jailbreakers and those who seek to detect them.

But there is a defense! The newer the OS, the less likely it will be that a public Jailbreak is available. Take unc0ver, for example. As of this writing it covers up to iOS 14.8, so if your devices are on a version of 15, they’re not going to be Jailbroken that way.

To me, the correct approach regarding this requirement is:

  1. We should expressly prohibit Jailbreaking (unless a security exception is obtained) in our information service end-user policy and include coverage of the topic in our ongoing user education. That alone satisfies the requirement as written. But it’s not the end of the story.
  2. Document the SLA and achievement metrics for applying OS and application updates. Above all else, we must continuously improve our performance here through a combination of systems that make patch easy and accompany that with user education. We must recognize that this is the best and only real defense against jailbreak and other rootkit attacks. State to the compliance auditor that beyond policy statements, this is recognized as the critical means of “prohibiting” jailbreaking.
  3. Device models with aging security protection or known security issues are removed from the fleet and replaced with something newer. For example, Apple blocked one exploit with hardware changes in subsequent models, but the mechanism remained viable on iPhoneX.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: