Dynamic analysis of iOS applications without Jailbreak
In this article, we want to share our experience solving some problems related to the security analysis of iOS applications. The review will be subject to the condition that we do not have an iOS device with JailBreak on board.
Static analysis vs. dynamic analysis
We begin our dive with the types of analysis and their small comparison. Static analysis allows you to identify a large number of problems: from the left account data to various kinds of “bookmarks” and vulnerabilities. Speaking about iOS applications, we note that IDA Pro, Hopper Disassembler, MobSF or Radare2 will be useful in this business. The advantage of this approach is the ability to autoscan files, code, including, unused with a relatively full coverage.
Dynamic analysis helps to find out how an application behaves directly during operation / execution, for example, to examine the state of a program at one or another point of execution (memory contents, registers, value of variables), study the operation logic, etc. ')
Using these two approaches allows you to carry out the work on analyzing the application in the most qualitative way, cover the entire attack-surface and find the maximum possible number of errors and vulnerabilities.
Criteria
Static analysis
Dynamic analysis
Code vs. Data
Problems
No problems
Code coverage
Large (but not all)
One way
Value data
No information
All information
Self-modifying code
Problems
No problems
Runtime vulnerabilities
Not
Yes
Unused code
Analyzed
Not analyzed
Dynamic analysis
Dynamic analysis of mobile applications is impossible without a device or, in the worst case, an emulator. Real devices are almost always preferable (unless there is a great need for any parallelization of the task). But the availability of a real device is more expensive for the researcher himself ... A simple possibility of installing your own applications on the device and tools for analyzing applications is also needed.
Android situation
While exploring Android applications, you can often even get away with the old and cheap version of the device or an emulator in the development environment. On Android, there is a simple opportunity to increase the user's privileges, in other words, “get root access”, to install your own tools and applications on it. On the old devices of Chinese brothers in the settings there was even one time switch for obtaining superuser privileges in one click / tap. On a personal device used every day, root can, in inept hands, noticeably weaken system security and cause malware infection, so we do not advise doing this. But as part of laboratory research, this is a necessary thing that allows us to speed up and improve the course of research.
IOS situation
When conducting a security audit of iOS applications, there are some additional points:
The cost of the device is not the lowest. But a separate device is definitely needed - do not use the same personal device
Device version - old phones are not suitable. Often you need the latest features, including Force Touch / Touch ID / ..
The type of device - phone, tablet, clock - all this plays an important role in the analysis (we have seen cases when a vulnerability in the same application was present only in the version for a certain type of device)
Relevance of the iOS version - The iOS API is constantly evolving, and for qualitative analysis, the analysis itself should take place on the latest iOS version
Having JailBreak on the device - to install your applications and tools with all the above
Jailbreak
Earlier, when the first iPhone was just released, it was hacked a few days after the release. A rather low level of security was maintained up to the fourth version of the operating system: the researchers created extensions (tweak), built their iOS builds and added applications. Over time, Apple changed its attitude towards security and significantly enhanced system security, also adding some of the most requested features created for Jailbreak devices in its updates. For example, the Control Center was initially tweak, and later became an embedded component of iOS. Each new release of the system increased the time for finding and exploiting vulnerabilities, changing the API and accessibility of the function (moving some to Private, and some to the Public zone). These and many other changes made life difficult for developers of tweaks (add-ons for the system) and applications, forcing them to update their offspring under new APIs and functions, as well as security researchers. The increased protection of devices was also influenced by close attention to the “bad guys” platform, special services, and all those who would like to access your data on the device. So, today the price of a remote JailBreak for iOS reaches $ 1.5 million.
Time passed, and many who stood at the origins of the JailBreak creation, were hired by information security companies, Apple itself , or began selling vulnerabilities to certain individuals, without publishing and creating public JailBreak. All this (an increase in the platform security level and an outflow of vulnerabilities to the market) led to the fact that public JailBreaks began to appear less and less.
At the moment, the latest actual version of iOS, suitable for using Jailbreak, is iOS 10.2 . All other versions of iOS10.2.1–11 are not yet confirmed, and numerous tweets do not contain anything other than video or photos / screenshots. It turns out that in order to conduct a security audit on a device, it is necessary to perform many factors, and the stumbling block is the presence of a current JailBreak.
Small retreat At the Tencent Security Summit 2017 conference, researcher Chris Wade presented a project on full virtualization of the iPhone 6. It is not public and it is not yet known how and when it will appear to a wide audience. But definitely, this is a very big step forward for many areas related to iOS. onetwothree
Security Analysis for iOS Applications
Now gradually gradually move on to the main topic of the article. So, there are, by and large, three types of application / system analysis:
WhiteBox - as part of this type of work, the customer provides all the information about the application: source code, documentation, etc. And here we are free to do ourselves with the application, whatever - to modify, build, run, analyze, etc. on any available device even without JailBreak.
GrayBox - in such a situation, the customer does not provide the source code of his application for one reason or another, but he can make a special assembly of his application for analysis. For example, with all the debugging messages and features turned off by SSL pinning and with our own libraries inside, which simplify the analysis of the application (more about them later). This build runs without problems on the device without JailBreak.
BlackBox is a model that fully reflects the situation with a real attacker who does not have any additional information about the application and the ability to influence its assembly. Here we just go to the application distribution store, download one of them and then try to do something with it. It is also possible that the customer’s desire to work in such a model of the offender, and participation in the developer’s BugBounty program. This is where the problem arises with the dynamic exploration of applications, since, in theory, one cannot do without JailBreak ...
Dynamic study of the security of iOS applications without Jailbreak
Conducting this kind of research requires some training of the researcher and setting the environment, so the steps in the form of a manual necessary for the implementation of the plan will be described below. It is important to note that some steps can be skipped, for example, if you use an Xcode project (signing, delivery to a device, etc.).
Step 0. Preparation
In order to begin research, it is necessary to observe some simple conditions regarding the environment:
macOS with Xcode
Apple Developer Account
iOS device without JailBreak
The decrypted .ipa file of the application being investigated
The framework you need to add to the application
Step 1. Extract the .ipa file
In order to get the IPA file needed for analysis, there are several ways:
From iTunes (iTunes <12.7.X +)
Buying an application in the AppStore from iTunes.app allows you to get the associated .ipa file to the AppleID of the buyer, this limits the possibility of modification, but allows you to conduct a static analysis of the binary file. The limitation of the version of iTunes.app is related to the latest application updates: Apple has deleted the AppStore section .
iFunBox, even TestFlight (iOS≤8.3)
An application for managing the file system of iOS devices. Full functionality is available only on devices with iOS version not higher than iOS 8.3.
Download the old version of the .ipa file from iTunes (iTunes <12.7.X +)
This is possible through the use of any application that allows you to redirect traffic through yourself (Charles Proxy, Burp, ..). After that, you need to run iTunes and download the selected application. Then, intercepting the request, change the build number for downloading in the package XML file and continue execution. More details about this can be found here and see here .
Online, for example, with ipastore.me or w3bsit3-dns.com (already immediately decoded here)
Sites and forums with applications available for download without binding to AppleID and allowing the necessary manipulations to join frameworks - the best solution, but you need to be careful with banking applications :)
Step 2-3.Data Extraction and .ipa Decryption
There will be a slight deviation from the rules, when JailBreak may be required, - for the step of getting the decrypted .ipa file. This concerns, first of all, those applications that are not available through the AppStore (for example, “special assemblies” or TestFlight). Getting the decrypted file is necessary to build the modified binary without being tied to the owner's AppleID. To do this, you can use the applications for JailBreak devices (for example, ask to unload a friend :)
One of the most convenient ways to add a framework to the .ipa file is to use the Xcode project. There are many projects on GitHub, but I wanted to highlight a couple, in our opinion, of the most successful, efficient and intuitive.
In the first case, there is a demo in which you only need to replace the .ipa file of interest and build the application, in the second case, drag the .ipa file and the Framework that you need to attach. The convenience of the first project lies in the fact that in addition to the introduction of the library, the researcher can add his own code, which will work after launch.
What can be put inside the .ipa file?
Answer: What your heart desires! But from the point of view of security analysis of the application, we can recommend using the following ready-made frameworks:
One of the few frameworks that is actively developing today and allowing you to implement the JS code inside the process, track the launch of the application and patch it even before the process is finished downloading. Its advantages are easy extensibility for tasks, the possibility of scripting actions and a convenient client. By adding only Frida gadget to the project, even without performing anything, it is already possible to find out which calls occur within the program and later apply this in static analysis (r2 + frida).
Similar in functionality to the Frida framework, it allows embedding into processes and manipulating environment variables and memory through an interactive console. It supports not only Javascript, but also Objective-C.
The legendary framework from Saurik itself, which allows to modify the application without the source code, manipulate the API and in every possible way twist and twist the application without having the source code. But at the moment it has not been updated for a long time, and it should be used solely at your own peril and risk. In addition, the development of iOS makes changes to the API, so in some versions of iOS it may not be useful at all.
The most non-standard of this set of frameworks. It is more suitable for UI / UX-sphere and studying the device interfaces for the presence of hidden fields, associated objects, and so on. Plus is the support for TV and Watch.
Step 5. Sign application
The application can not be installed on a smartphone without a corresponding developer signature (do not forget that we have a device without JailBreak). If we do not use Xcode, which itself, automatically, picks up certificates, then we can do it manually using one of the tools:
They both do an excellent job with their tasks and at the output we get the application correctly re-signed by our certificate.
Step 6. Delivery to the device
Using Xcode projects and a device after selecting a target, the application will automatically be delivered and launched on the smartphone. If the output is only .ipa file, then install it will help the following utilities:
In short, the diagram with a description of each step and utilities that help to make each step looks like this: And finally, a couple of demos of how it all looks in a bundle:
Description : Building a project from Demo 1, launching Objection with Frida and viewing the contents of the application folder, calling Alerts, reading the contents of Keychain.
This work was a little earlier presented at VolgaCTF'17, and slides from the report can be viewed here .
appdb.store - allows you to sign applications online and for free, if you attach your developer account. Also from there you can download decrypted binaries.