Fnut, 2016/03/01″
The original address: www.fireeye.com/blog/threat…
0 x00 preface
Apple makes a lot of efforts to build and maintain a healthy and clean app environment. One of the things that has contributed to the current situation is the Apple APP STORE, which is protected by an elaborate approval process that checks all applications submitted. Although the program is designed to protect IOS users and ensure that the application complies with Apple’s security and integrity requirements, developers who have experienced the process may find it too complicated and time-consuming. Releasing a new release or releasing a patch for an existing APP also follows this process, which can be very frustrating for a developer trying to fix a critical bug or security vulnerability that affects existing APP users.
The developer community is already looking for alternatives, and some progress has been made. This suite of solutions now provides a more efficient IOS APP development experience, allowing APP developers to update their code as they see fit and immediately deploy patches to users’ devices. While these technologies offer a freer development experience, they do not conform to the same security norms that Apple is trying to maintain. Even worse, these ideas could be the Achilles heel of Apple’s strong APP STORE wall.
In this article, FireEye mobile security researchers will analyze the security risks of IOS apps using these alternatives and try to prevent the IOS APP ecosystem from making unexpected security compromises.
In the beginning of this article, we will focus on an open source solution: JSPatch.
0x01 JSPatch
JsPatch is an open source project — it’s based on Apple’s JavaScriptCore framework — designed to provide an alternative to Apple’s laborious and unpredictable approval process at a time when releasing timely patches for important bugs is critical. In the author’s own words (highlighted in bold) :
JSPatch uses objective-C’s runtime environment to connect Objective-C to JavaScript. You only need to include a small engine to call any Objective-C class or method in JS. This gives the APP the power of a scripting language: dynamically adding modules or replacing Objective-C code to fix bugs.
JSpatch’s author, In a personal blog post, provides an example of how JSpatch can be used to update a flawed APP:
The figure below shows a UITableViewController implementation, class called JPTableViewController, through tableView: didSelectRowAtIndexPath: to provide the data. In line 5, it retrieves data from the back-end source’s array of strings with a directory mapped to the selected row number. In many cases, this feature is fine; But when the row directory exceeds the range of the source data array, which is quite possible, the program will throw an exception and cause the APP to crash. And APP crashes are definitely not something users want to happen.
Within the technology provided by Apple, the way to fix this situation is to fix the bug with updated code and rebuild the APP, and submit the newly created APP to the APP Store for application. Although the approval process for an updated APP often takes less time than the initial review submitted, the process can still be time-consuming, unpredictable, and can result in some losses if APP fixes are not released in a timely and controlled manner.
However, if the original application is embedded with the JSPatch engine, its behavior can be changed based on the JavaScript code loaded at runtime. The JS files here (hxxp://cnbang.net/bugfix.JS in the above example) is under the control of remote APP developers. It is sent to the APP via network communication.
The following figure shows the basic way JSPatch is created in an IOS application. This code will allow you to download a JavaScript patch and execute it when the APP starts.
JSPatch is very lightweight indeed. In this case, make sure that it can perform to do extra work just in application: didFiishLaunchingWithOptions: selector added seven lines of code. From hxxp://cnbang.net/bugfix.JS below, download the defective code used to patch the JS code.
0x02 Malicious Functions Displayed
JSPatch is a great perk for IOS developers. On the plus side, it can be used to deploy patches and code updates quickly and efficiently. But in a non-utopian world like ours, there will always be people who will use this technology for unexpected purposes. In particular, if an attacker was able to tamper with the JavaScript files that ended up being loaded by the APP, an APP from Apple’s APP STORE could be used to carry out a massive attack.
Target application:
We randomly picked a legitimate APP that uses JSPatch and can be downloaded from the APP STORE. As shown in the figure, the logic for building the JSPatch platform and the source code for the patch are packaged in the [AppDelegate excuteJSPatch:] process.
There is a series of flows from the application entry point (in this case, the AppDelegate class) to where the JavaScript file contains updates or patches that are written to the file system. This process involves communicating with a remote server to get the patch code. On our test device, we finally found that the JavaScript patch code was hashed and stored in the location shown below. The hashed content is also shown below, encrypted in base64 format.
While the developers of the targeted app have taken steps to ensure that this private data is not stolen illegally, such as using Base64 encoding based on symmetric encryption, an attacker could override these security measures by running several instructions on Cycript. The encrypted patch code is shown below:
This is what is loaded and run by JPEngine, which is provided by the JSPatch framework and embedded in the target application. To change the behavior of the running APP, we need to modify some JavaScript content. Below we show several possible ways to combat malicious behavior by Apple censors. Although the following example is from a jailbroken device, we will also verify that these actions can be performed on a non-jailbroken device.
Example 1: Load any public framework into the application process
A. public framework sample: / System/Library/Frameworks/Accounts. The framework
[ACAccountStore init] [ACAccountStore allAccountTypes] [ACAccountStore allAccountTypes]
When the target application discussed above is run, it goes home and puts frameworks into the process memory as shown in the following image:
Note that the listing above — generated from apple’s allowed IOS app binaries — does not include the Accounts. Framework. Therefore, any “dangerous” or “risky” operations that rely on these apis provided by the framework are undesirable. However, the JavaScript code shown below makes this assumption meaningless.
If the JavaScript code is sent to the target application as a Hot patch, it dynamically loads a public framework (Accounts. Framework) into the running process. Once the framework is loaded, the script has access to all of the framework’s apis. The following figure shows the output of executing the Private API (ACAccountStore allAccountTypes), which outputs 36 account types on the test device. The addition does not require the APP to be rebuilt, nor does it require additional review in the APP Store.
The above proof highlights the serious security risks that can exist for IOS APP users and APP developers. JSPatch technology could allow individuals to effectively bypass the APP Store’s review process and perform arbitrary and powerful actions on the device without the user’s consent. The dynamic nature of the code also makes it difficult to catch a malicious attacker in a malicious act. We are not going to provide any meaningful EXP in this blog post, just pointing out the possibility to prevent attackers from exploiting this vulnerability.
Example 2: Load any private framework into the application process
A. Framework Example
/System/Library/PrivateFrameworks/BluetoothManager.framework
B. Private API used by the sample framework:
[BluetoothManager connectedDevices], [BluetoothDevice name]
Like those on an example, a malicious JSPatch JavaScript can make an application to load any private framework, such as BluetoothManager. The framework, The private API is further called to change the state of the device. The IOS Private Framework is designed to be used only by apps provided by Apple. Although there is no official documentation on the use of the private Framework, it is well known that most of them can provide proprietary access to the underlying system functionality, which may also allow an application to bypass security controls set up by the operating system. The APP STORE has strict policies that prohibit third-party apps from using any private Framework. However, it is important to note that the operating system does not distinguish between private Framework use by Apple apps and private Framework use by third-party apps. Barring third parties from using it is simply apple’s APP STORE policy.
When we use JSPatch, these constraints become unambiguous because JavaScript files are not censored by Apple’s APP Store. The code below is by loading BluetoothManager. Framework and USES the API to read and change the host equipment state of bluetooth. The latter figure then shows the output of the matching console.
Example 3: Change system properties via the private API
A. Sample dependent Framework:
/System/Library/Frameworks/CoreTelephony.framework
B. Private APIS used by the sample Framework:
[CTTelephonyNetworkInfo updateRadioAccessTechnology:]
Consider the case of a target application created using the Public Framework (CoreTelephony. Framework). According to Apple’s filing, the framework allows you to obtain information about a user’s home mobile phone service provider. It exposes several public API for developers to get these, but [CTTelephonyNetworkInfo updateRadioAccessTechnology:] is not one of them. However, as shown in the figure below, we can successfully use this private API to update the mobile phone service status of the target device without Apple’s consent.
Example 4: Get album private data through the public API
A. Framework for sample loading:
/System/Library/Frameworks/Photos.framework
b. public apis:
[PHAsset fetchAssetsWithMediaType:options:]
The main concern for mobile phone users is privacy infringement. Any activity performed on a device that involves access to and use of a user’s private data (including contacts, messages, photos, audio, notepads, call logs, etc.) should be certified to be within the scope of the services provided by the application. However, as shown in the figure below, we can use the private API to access a user’s Photo album by capturing the Photo’s metadata from the built-in Photo.framework. With a little more code, an attacker could export the photo data without the user’s knowledge.
Example 5: Get the clipboard data in real time
A. framework sample: / System/Library/Frameworks/UIKit. The framework
B. API: [UIPasteboard strings], [UIPasteboard items], [UIPasteboard String]
The IOS clipboard is one of the mechanisms that allows data transfer between applications. Some security researchers have raised security concerns because clipboards can be used to pass private data, such as accounts and certificates. The following figure shows a simple JavaScript demo function that, when run on the JSPatch Framework, retrieves all the string content from the clipboard and displays it on the console.
We’ve already shown five examples using JSPatch as an attack route, and there’s the possibility of many more.
0x03 Future attack method
Most of IOS’s native functionality is dependent on C functions (such as dlopen(),UIGetImageScreen()). Since C functions cannot be called by reflection, JSPatch does not support direct mapping from Objective C to JavaScript. In order to use C functions in JavaScript, an application must support JSExtension, which packages C functions into interfaces and further exports them to JavaScript.
Relying on additional Objective C code to use C function functionality leaves malicious attackers in the dark (such as background screen capture, intercepting text messages without being detected, stealing photo privacy data, or background recording). But these constraints can be easily bypassed. In fact, the authors of JSPatch could provide more usable and convenient interfaces for application developers in the future, ensuring that there are enough commands. In this case, none of the above will be felt by Apple.
0x04 Security Impact
IOS devices are known to be more secure than phones running other operating systems; However, we must recognize that the factors that maintain the status quo are multifaceted. The core of Apple’s security controls is to provide and maintain a secure ecosystem for IOS users and developers, a “walled garden” — the APP STORE. Apps distributed through the APP STORE will be harder to exploit during a meaningful attack. To date, two main avenues of attack make up all previously disclosed attacks on IOS:
- Jailbroken IOS devices allow unsigned or incorrectly signed apps to be installed because signature checking functions are disabled. In some cases, the sandbox constraints are removed, which allows the application to run outside the sandbox.
- On non-jailbroken devices, applications can side load with enterprise certificates. FireEye has published a series of reports detailing attacks using this attack surface, and recent reports continue to focus on this known attack path.
And as we emphasize in this report, JSPatch provides an attack route that doesn’t require side loading or a jailbroken device as a necessary element of the attack. It’s not hard to see how JavaScript content in JSPatch could be the app development framework’s Achilles heel. Since there are few security measures to ensure the secure properties of this file, the following attack scenarios are possible:
● Prerequisites: 1) JSPatch platform embedded in the app; 2) App developers have malicious intentions.
○ Impact: Application developers can take advantage of all the private apis provided by the loaded framework to perform actions that they do not want Apple or users to know about. Because the developer has control over the JavaScript code, malicious behavior can be transient, dynamic, secretive, and evasive. Such an attack, if it occurs, poses huge risks to all stakeholders involved.
○ The following figure illustrates a scenario of this type of attack:
● Prerequisites: 1) Third-party AD SDKS are embedded in the JSPatch platform; 2) The host application uses this advertising SDK; 3) The AD SDK has malicious intent on the host application.
1) The AD SDK may leak data from the app sandbox; 2) The AD SDK may change the behavior of the host application; 3) Advertising SDKS can perform various operations on the operating system in the name of host applications.
○ The following figure illustrates a scenario of this type of attack:
FireEye’s discovery of iBackdoor in 2015 is an example of a trusted replacement attack within the IOS development community, and serves as a good example of this overlooked threat.
● Prerequisites: 1) The app is embedded with the JSPatch platform; 2) The app developer is legal; 3) The application does not secure JavaScript content communication from client to server; 4) A malicious attacker performs a man-in-the-middle attack to tamper with JavaScript content.
○ Impact: A man-in-the-middle attack can reveal the contents of an application in the sandbox. Man-in-the-middle attacks can use the private API to use host applications as proxies to perform a variety of malicious actions.
○ The following figure illustrates a scenario of this type of attack:
0x05 Related Information
JSPatch originated in China. It has been a success in China since it was released in 2015. According to JSPatch, many popular Chinese language apps already use this technology. FireEye APP Scan found 1,220 apps using JSPatch in the APP STORE.
We’ve also seen developers outside Of China adopt this framework. On the one hand, this shows that JSPatch is a useful and desirable technology in the IOS development environment. On the other hand, it is also a sign that these users are at high risk of being attacked — especially without taking precautions to ensure the safety of all parties involved. While JSPatch has exposed some security risks, FireEye has not found any of the apps to be malicious.