TLDR:  I was able to enroll a jail broken device on a “major” MDM provider.  Any vendor that says they can prevent jailbroken devices from enrolling in a MDM solution is not being 100% honest.  Any resourceful person can get around jailbreak detections.  Because of the client side nature of this problem it’s very difficult to control the end user, as always it’s a cat and mouse game.

MDM or mobile device management is a way for organizations to control, push configurations, set policies, monitor, etc on phones and tablets.  Mobile operating systems today offer some MDM capabilities but the reason why MDM solutions are popping out of the woodwork is that there are features lacking especially in iPhone / iOS and Android.  Google has recently come out with Android for Work (AFW) which looks to close the gap and add a lot of MDM capabilities which will greatly help organizations adopt the Android platform, especially in a BYOD environment.  With that intro out of the way let’s get to how one can break MDM.

This will focus on iOS.  Enrolling a jailbroken device can very from quite simple to reversing the MDM app on how it checks for jailbreak detection.  I got enrolled a jailbroken device via the simple method.  Joe Demesy and the guys at BishopFox did all the hard work and created an app, named iSpy, to make all of this easier.  Follow the instructions on how to get everything setup and once done you will be able to perform actions such as code injection, runtime modification, debugging, disable SSL certificate pinning, and bypassing jailbreak detection.  Once installed go to Settings > iSpy and there you can enable “Bypass Common JailBreak Checks”, click on the screen shot below for the full size image.

To get around this “major” commercial MDM vendor jailbreak detection all I had to do was enable the feature inside of iSpy.  You will also have to enable “Inject iSpy into Apps” for the MDM mobile app.  Next open up the MDM app and you should briefly see in the top left of the app that iSpy is successfully injected into the app.  Below is an example of iSpy injected into OneNote.

After I did these two steps I was able to successfully enroll my jailbroken device inside the commercial MDM solution.  The purpose of MDM’s blocking jailbroken devices is that they have full root access to the device which allows an attacker or malicious user to modify the intentional features of a MDM solution.  So allowing a jailbroken device is somewhat of a big deal as you don’t have the same protections as you would with a non-jailbroken device.

Especially in iOS this cat and mouse game of jailbreak detection will continue.  Anytime you have a MDM iOS app the only thing it can do is what’s allowed by the iOS framework which is somewhat limiting.  Also a jailbroken device can inject itself into the mobile MDM app and modify it to trick the MDM app that it isn’t jailbroken.  So there you go, thanks to Joe Demesy and others it’s that simple to get around a MDM solution.

For reference below are some links on techniques MDM vendors use to detect a jailbroken device which in turn attackers will try and get around.

https://www.trustwave.com/Resources/SpiderLabs-Blog/Jailbreak-Detection-Methods/

https://reverse.put.as/2013/06/30/gone-in-59-seconds-tips-and-tricks-to-bypass-appminders-jailbreak-detection/

http://resources.infosecinstitute.com/ios-application-security-part-23-jailbreak-detection-evasion/

http://www.bishopfox.com/news/2014/09/misti-itac-2014-mobile-application-security-testing-code-review/

1. Plug iPhone or iPad into Mac
2. User iExplorer or iFunbox to explore file system of apps
3. Export relevant directories to local box (Usually Library and *.app)
4. Search for files of interest

Search inside the files for items of interest

iExplorer can open plist in quick view

You can open databases with Sqlite browser

One can read cookie with BinaryCookieReader.py

One of the areas you need to focus on when performing security / penetration testing on iOS applications is what information is written to disk or stored locally. There are a number of things that can be written to disk (text files, config files, plist files, databases, etc). There are a handful of directories that an application typically uses to store local data within an iOS device which you’ll need to keep in mind when combing through the local file system. I’ll cover these directories and walk through an iOS application security assessment.

The application we’ll walk through is iGoat, an intentional vulnerable application written for the iPhone / iOS devices. The iGoat application can be ran inside the iOS Simulator which is free to use assuming you have an Apple OSX device. I’m not going to walk through setting up the iGoat application within the simulator, please check online resources for getting iGoat up and running. Once up and running go to “Data Protection (Rest)” > “Local Data Storage” and start the exercise. You’ll notice the exercise describes that it’s using an underlying SQLite database to store information, keep in mind you won’t normally know this information. Initially when performing a security test on an iOS application you won’t know if data is being stored locally, it could be it’s storing all information server side. If it does store data locally it can be in a number of locations and in different formats such as a SQLite database. Once you start the iGoat data storage exercise you should come to the following screen.

At this point just put in some fake username and password, I’ll choose username “super” and password “secret”. After you click “Login” nothing will happen, this isn’t meant to be a full blown application. So the application took input from the user but what happened to that information? The iOS simulator is no substitution for an iOS device but the behavior of the application remains the same, meaning if you’re testing an application in the simulator on your Macbook then if the application stores local data then that data will be stored in some location on your Macbook. The application data is typically stored in the following location on your OS X device.

Where UID is a unique identifier for the application installed and of course you’ll substitute my name with your username in the “Users” directory. My UID in this case is “8813AE1B-3FC7-4503-99D0-666E974A74D7”. If you open up Finder in OS X and try to navigate to the Library directory you won’t see it that’s because it’s hidden, you can enable the viewing of hidden files and folders but I’ll be navigating via the Terminal which is in the Utilities folder under applications. Once in the UID directory perform a “ls -lh” command to see the files and directories the application is utilizing.

Here we see four directories (Documents, Library, iGoat.app, and tmp), we know they’re directories because each line begins with a “d”, if it wasn’t a directory you would just see a “-” dash. These are the four main directories you’ll have for each application and you’ll replace iGoat.app with whatever application you’re testing (e.g. AppName.app). When it comes to looking for items of interest when security testing one should focus on these four directories, listed below is a chart showing the type of information that can be found in those directories.

The contents and location are not set in stone but these locations are the best place to start. So now you know the location of where files may be stored locally on an iOS device but what’s the best way to discover the files we’re interested in? Let’s use what we know in this case, the application tells us that it stores login information into a SQL lite database. Normally you’re not going to know that the application uses a SQL lite database to store information unless you’re in close communication with the developers of the application. For now we know the app uses a SQL lite database so let’s search through these directories looking for that file. We could do this manually but I think dropping to a command prompt is always best. Use the “find” command to locate any SQL lite databases, the command is below.

From the output of the find command we’ve located two SQL lite databases for this application, credentials.sqlite and articles.sqlite. Credentials.sqlite is the obvious place to start. There are multiple ways to view that sqlite file but the two I prefer are the sqlite database browser and the command line utility sqlite3. I’ll be sticking with the sqlite3 command to give you a different perspective as the sqlite database browser is GUI based and easier to use. One thing to note with GUI tool is that it can’t browse hidden directories so you’ll have to copy and paste sqlite database from the “hidden” Documents directory into a directory that the GUI tool can navigate tool. Next open the sqlite database with the command below.

You’ll be presented with a sqlite prompt. Next issue the “.tables” command into the sqlite prompt.

Here we see a “creds” table, to view the contents of that table use the “.dump” command.

Here we see in the first INSERT statement the values of username and password that we typed into the application. So the vulnerability is that credentials to the application are stored in plain text so if someone were to remotely or locally gain access to the iphone then they could glean these credentials. It’s always best if possible to store credentials server side and if you must store credentials locally then encrypt that information. This goes for any sensitive information stored locally (text files, config files, plist files, etc). I could extend this example to those types of files but the same concept applies. So if you’re curios about one of your iOS apps check out those locations and if develop iOS applications make sure you store local sensitive information in an encrypted format.

Feel free to comment with questions or concerns.