Post last updated 8th June 2020

Jailbreaks these days are rare. “Back in the Day” jailbreaking and installing Cydia (the jailbroken App Store) was a bit more common, but in recent years this has been less of a threat for any company deploying managed iOS devices. My opinion on this is as iOS has become more mature many features I certainly jailbroke for are now part of the OS.

With the new “Unc0ver” v5.0 Jailbreak launched on the 23rd May 2020, it seems that all releases of iOS back to 11. So pretty much every device in the wild, and most device types. For this post I have tested ‘Unc0ver’, it works on my iPhone 6s and iPhone 7 and takes less than 10 minutes. Any person who wants to do this, has a Mac and can follow some basic instructions will be able to do this.

This post is aimed at Mobility/Digital Workspace Teams at organisations who have deployed (or are considering) Workspace ONE UEM (formerly AirWatch). This post will NOT contain any links to the Jailbreak, nor any guidance on how to run it.

As of iOS 13.5.1, this jailbreak is no longer effective. https://www.theverge.com/2020/6/1/21277281/apple-ios-13-5-1-patch-unc0ver-jailbreak-update-software-install

“This jailbreak basically just adds exceptions to the existing rules,” Unc0ver’s lead developer, who goes by Pwn20wnd, told WIRED. “It only enables reading new jailbreak files and parts of the filesystem that contain no user data.”

Wired – https://www.wired.com/story/apple-ios-unc0ver-jailbreak/

Plan of Attack

  1. Detect a jailbroken device with Workspace ONE UEM
  2. Remediate devices using UEM by sending emails and using Compliance Policies
  3. Prevent a user from doing this in the first place

Detection

Firstly, a little bit about how Workspace ONE detects a Jailbreak. I can’t go into a technical deep dive on its logic (I don’t know, and Dev can’t tell me!), but essentially our process to detect if a device is Jailbroken lives the Workspace ONE SDK. This SDK is baked into all our VMware Productivity Apps, including the Intelligent Hub (our Agent and Catalog experience), Boxer (email Client), and Web (managed browser). Great explanation of what this is and where Applications live in the Workspace ONE Ecosystem here.

The key setting to consider first: do we want to automatically Enterprise Wipe / Unenroll the Jailbroken device? Or do we want to leave it enrolled, and use Compliance Policies to take care of it? This is down to you, but you need to consider the settings here: Settings > Apps > Settings and Policies > Security Policies. More on Compliance Policies in the remediate section.

If Compromised Protection is Enabled, as soon as a Jailbroken device launches ANY Workspace ONE SDK enabled app it will be Enterprise Wiped. The device is not wiped/factory reset (personal data remains intact), but anything delivered via MDM (managed apps and data, email profiles etc) will be removed.

I have 3 test iOS devices at my disposal. An iPhone 6s running 13.3.1, and iPhone 7 (in Apple Business Manager) running 13.5 and an iPad Mini (4th Gen) running 12.4.6 (dinosaur here, but it does make an OK eReader!).

The devices prepped for Jailbreaking, all green
  • The 6s enrolled as a BYOD device manually via the Intelligent Hub
  • The iPhone 7, supervised via Apple Business Manager Automated Enrolment
  • The iPad was manually enrolled, but also manually supervised via Apple Configurator 2.

First off, the iPad was too old to run the Jailbreak, so that one stayed safe (books intact!).

Next up, the iPhone 6s BYOD device. Once successfully compromised, the next time I loaded the Intelligent Hub to launch a SaaS application/check my notifications, it was instantly unenrolled. I had a Compliance Policy running (more on that in the remediation part below), so I got notified by email that I’d been naughty.

I then ran the Jailbreak on my iPhone 7 Supervised device. Same outcome here, the device was instantly Enterprise Wiped (unenrolled) the second the Hub was launched. For this test, I had disabled the Compliance Policy, and I was not notified at all about what had just happened, I was just no longer enrolled.

End result: 2 unenrolled devices, 1 email notification, and some stats for the dashboard!

Remediation

This section will go over our Compliance Engine (official docs), and a policy based on “Compromised Status”. This step will help us get users back under management by communicating with them via Email.


It’s always best to set a compliance police for Compromised Status when deploying Workspace ONE UEM for the first time. Your VMware Deployment Consultant/Partner be able to go through this with you, but is pretty straight forward. First of all, we set up a new Compliance Policy and select “Compromised Status” as our target, and “Is Compromised” as the value.

NOTE: If we have the Compromised Protection option mentioned above Enabled, and our first step is Block/Remove profiles apps, this will be fired off as well as a ‘Break MDM’ command, meaning the device is just gone. To prevent this in the first case, disable Compromised Detection. This means the Compliance Policy is the caretaker here, instead of that option.

16 compliance policy types for iOS alone!

Next, we set up our Actions. These can be time-bound, you can have more than one and can escalate from a light touch to a heavy hand over time.


Here, we will send a user an email with our Compliance Violation message template (the default built-in one). You can create your own email templates with your own branding and guidance, and links to your help desk team. This should help users trust the email notice more.

In our example, after 1 day we will send another email to the user, we could select a follow-up template if we wanted to make sure the user is able to get back on the platform with a safe device.


We then set the Assignment, using the Smart Group methodology. Note here we can also set an exclusion, however, this will only exclude you from the email/actions, it will NOT prevent your device from being enterprise wiped after Jailbreaking if Compromised Protection is Enabled. You can check the assignment before going forward, REALLY important if setting this in production.

You can check your Device Summary, set the name and description. I recommend where you see a description box in UEM, USE IT!! In the case of the Compliance Policy this field is used to communicate to the end-user what the policy is doing.

When I did my tests, I got the below stock email. The Support Email address is taken from Settings > Devices & Users > General > Enrolment > Customisation.

Extra Step: Workspace ONE Intelligence

I have not yet done the legwork here yet, but we should be able to detect a users jailbroken device, and using a combination of Intelligence and Hub Services send a notification to the users Hub (across Browser and Native apps), with a link to an FAQ or other resource. We could also do some proactive steps with their other iOS devices (if they have them) to encourage them to un-jailbreak their device (remove some profiles, ban from VPNs etc).

Prevention

You may be thinking, I want to stop users from doing this in the first place! I have thought of a few different ways we can try and do this.

Bring iOS Devices to 13.5.1

Use a compliance policy to encourage users to upgrade to iOS 13.5.1. To help improve your email templates, check out this Blog from Mathijs @ Fondo.

Set up a new compliance policy, and use the “OS Version” action. I would use “Less than or equal to” iOS 13.5. This will mean if you’re on 13.5.1, you won’t be targeted, everyone else will get an email/action.

Don’t forget about “Compliance Profiles”. These are special profiles that can be delivered down as part of a compliance policy.

Content Filter profile (supervised devices only)

Supported on iOS 7+ Supervised devices. If you add the URL of the jailbreak website in a Content Filter profile as below, you can block the users from accessing it in Safari. This kills one avenue to jailbreak the device via using the side-loaded app store method (AltStore).

Also on Supervised devices, we can see any personal apps installed, as well as side-loaded iOS apps. This allows us to again use Intelligence to take some automated actions. Think, IF AltStore Installed, THEN block/remove profiles until app is removed.

Showing the AltStore side-loaded app in the Install list

Application List Compliance Policy

One method to deploy this Jailbreak is via a side-loaded AppStore, called ‘AltStore’. We can see this application in the app list sample from iOS, when the privacy options permit (yes for corp devices, no by default for BYOD).

The Bundle ID for this is:  com.2UY22H6W29.com.rileytestut.AltStore. We set an “Application List” compliance policy to check for this app. This was at least the case in my example. YMMV.


This will initially send an email, which we can ask nicely for the user to remove the app. After a day, we will block their VPN profiles and send another email. A day after that, we remove all config profiles and send another email. A day after that, we will revoke all Azure Tokens (unauthorising them from Office 365) and removing all managed applications. NOTE here we DO NOT enterprise wipe them. This path is less destructive and allows us to return the device back to normal without needing to get the Hepdesk involved.

Example email from UEM. NOTE – the Name and Description of the policy are shown to the user.

(Theoretical) Use Carbon Black to detect the side-loading tools

I’ve not tested this yet, but in theory we could leverage Carbon Black deployed on your Mac’s to detect and prevent the execution of certain applications/files. The Hashes of the files needed are below.

user$ shasum -a 256 unc0ver-v5.0.0.ipa 
 a20c8909dd23b1cd38875ab04e83f64c5179ed888ac05aed8f6775f8a3f3a6ee  unc0ver-v5.0.0.ipa
  
user$ shasum -a 256 altserver.zip 
 7c1db4387a700f389d173a8cf56d385673419b4c2227e1de4251101c5f14f153  altserver.zip

This would allow us to know which users are preparing to jailbreak a device, so we can send them a friendly warning. I don’t know if this will work, something I hope to test and update in the coming weeks.

BYOD Prevention

Unfortunately, there’s not a lot we can do to stop someone Jailbreaking their device if it’s managed as BYOD. Likely, the App List will prevent you from seeing any personal apps, and the Content Filter profile isn’t supported on non-supervised devices.

Conclusion

I hope this article has been helpful in understanding some of the features Workspace ONE UEM can offer when attempting to work with the new Jailbreak for iOS.

I intend for this to be a bit of a living document, and will update it if I/we come up with any more ways to help detect/remediate/prevent this.

Feel free to leave a comment or get in touch, drop us a message on @EUCSE1 on Twitter. We love hearing from our readers and want to work as a community!

References and further reading

Please read up on this!

Spread the love