Advantages and risks of iOS remote hot patch

Advantages and risks of iOS remote hot patch
0x00 Preface

Apple has made a lot of efforts to build and maintain a healthy and clean application environment. The Apple app store, which plays a major role in the current situation, is protected by a very thorough approval process for all submitted applications. Although this program is designed to protect IOS users and ensure that the application meets Apple's security and integrity requirements, developers who have experienced this process may feel that it is too complicated and takes a lot of time. This process is also required to release a new release version or a patch for an existing APP, this is a problem for developers who want to patch critical bugs or security vulnerabilities that affect existing APP users.

The developer community is already looking for alternative solutions and has made some progress. This series of solutions now provide a more efficient ios app development experience, allowing APP developers to update their code as long as they think it is appropriate, and immediately deploy the patch to your device. Although these technologies provide a more free development experience, they do not comply with the same security specifications apple is trying to maintain. Even worse, these ideas may become the Achilles' heel of Apple app store's powerful "City Wall.

In this article, FireEye mobile security researchers will analyze the security risks of IOS apps using these alternative solutions, and attempt 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 based on Apple's JavaScriptCore framework. It aims to provide an alternative solution for Apple's laborious and unpredictable approval processes, it is very important to release patches for important bugs in a timely manner. In the author's own words (Bold):

JSPatch uses the Objective-C runtime environment to contact Objective-C and JavaScript. You only need to include a small engine to callAnyObjective-C class and method. This gives the APP the ability to use the script language:DynamicAdd a module or replace Objective-C code to fix the bug.

The author of JSpatch provides an example in his personal blog to illustrate how JSPatch is used to update a defective APP:

Demonstrate the implementation of a UITableViewController. The class name is JPTableViewController, which provides data through tableView: didSelectRowAtIndexPath. In row 5th, It retrieves data from the string array of the back-end source, which carries a directory mapped to the number of the selected row. In many cases, this function is normal. However, when the row directory exceeds the range of the source data array, this is also likely to happen, this program will throw an exception and eventually cause the APP to crash. The APP crash is definitely not expected for users.

Within the technical scope provided by Apple, the solution is to use the updated code to fix the bug and reconstruct the application, and submit the newly created APP to the App Store for application. Although the approval process usually takes less time for updated applications than the reviews submitted at the beginning, this process still takes a lot of time and is unpredictable and may cause some losses, if the APP cannot be released in a timely and controllable mode.

However, if the original application is embedded with the JSPatch engine, its behavior can be changed according to the JavaScript code loaded at runtime. The JS file (hxxp: // cnbang.net/bugfix.JS in the above example) is remotely controlled by APP developers. It is sent to the APP through network communication.

Demonstrate the basic methods created by JSPatch in an IOS app. The code will allow you to download a JavaScript patch and execute it when the APP is started.

JSPatch is indeed very lightweight. In this example, make sure that it can perform additional work by adding 7 lines of code to application: didfiishlaunchingwitexceptions: selector. The following code is downloaded from hxxp: // cnbang.net/bugfix.jsto provide the JS Code with the defective code.

0x02 malicious function display

JSPatch is a good benefit for IOS developers. On the one hand, it can be used to quickly and effectively deploy patches and code updates. But in a non-utopia world like ours, there will always be people who use this technology for unexpected purposes. In particular, if an attacker can tamper with the JavaScript files eventually loaded by the APP, a large-scale attack can be carried out by an Apple app store application.

Target application:

We randomly select a valid APP that uses JSPatch and can be downloaded from the app store ., The logic for establishing the JSPatch platform and the patch source code are packaged in the [AppDelegate excuteJSPatch:] process.

There are a series of procedures, from the application entry point (in this example, the AppDelegate class) to the place where JavaScript files contain updates or patch code is written to the file system. This process includes communication with remote servers to obtain the patch code. On our testing device, we finally found that the JavaScript patch code was hashed and stored in the location shown in. The hash content is also shown in. It is encrypted in base64 format.

(Location of the downloaded JavaScript file stored on the target machine)

(Encrypted patch content)

Although developers of this target application have taken some measures to ensure that the private data is not stolen illegally, for example, Base64 encoding is used on the basis of symmetric encryption, attackers can invalidate these security measures by running several commands on cyloud. Shows the encrypted patch code:

This is the content loaded and run by JPEngine. JPEngine is provided by the JSPatch framework and embedded into the target application. To change the running APP behavior, we need to modify some JavaScript content. Below we will show several possibilities of malicious behavior against Apple review. Although the following example is from a jailbroken device, we will also confirm that these behaviors can also be completed on a non-jailbroken device.

Example 1: Load arbitraryPublicFramework to the application process

A.Public framework example:/System/Library/Frameworks/Accounts. framework

B.Private APIs used by the public framework: [ACAccountStore init], [ACAccountStoreallAccountTypes]

The target application discussed above, when it is run, goes home and enters the process memory as shown in frameworks:

Note that the above list, generated from the binary file of IOS apps allowed by Apple, does not contain Accounts. framework. Therefore, any operation that relies on the APIS provided by this framework to perform "dangerous" or "risky" operations is not expected to happen. However, the JavaScript code shown 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) to the running process. Once the framework is loaded, the script has the permission to access all APIs of the framework. Displays the output of executing the private API (ACAccountStore allAccountTypes). It outputs 36 account types on the test device. The added behavior does not require the application to be rebuilt or requires additional review in the APP store.

The proof above emphasizes the serious security risks that may exist for ios app users and APP developers. JSPatch technology may allow individuals to effectively bypass the APP store review process and execute any force actions on the device without the user's consent. The dynamic nature of Code also makes it very difficult to seize malicious attackers in a malicious behavior. We will not provide any meaningful EXP in this blog post, but just point out this possibility to prevent attackers from exploiting this vulnerability.

Example 2: Load any private framework to the application process.

A.Framework example:

/System/Library/PrivateFrameworks/descrithmanager. framework

B.The private API used by the framework in the example:

[Descrithmanager connectedDevices], [descrithdevice name]

Similar to the previous example, a malicious JSPatch JavaScript script allows an application to load arbitrary private frameworks, such as javasthmanager. framework, and further calls the private API to change the device status. IOS private framework is designed to be used only by apps provided by Apple. Although there is no official document on the use of private frameworks, it is well known that most of them can provide private rights to function close to the underlying system, this may also allow an application to bypass the security control set by the operating system. App store has strict policies to prohibit third-party apps from using any private framework. However, it is important to note that the operating system does not distinguish the private framework usage of Apple applications from that of third-party applications. It is only Apple app store's policy to prohibit third-party use.

When we use JSPatch, these constraints become unquestionable, because JavaScript files are not under the review scope of Apple APP store. The code displayed is to read and change the Bluetooth status of the host device by loading thmanager. framework and using APIs. The next figure shows the matching console output.

Example 3: Using private APIs to change system attributes

A.Framework on which the sample depends:

/System/Library/Frameworks/CoreTelephony. framework

B.The private API used by the sample framework is as follows:

[CTTelephonyNetworkInfoupdateRadioAccessTechnology:]

Consider a target application created using the public framework (CoreTelephony. framework. According to Apple's documentation, this framework allows you to obtain information about a user's home mobile phone service provider. It exposes several public APIs for developers to obtain these information, but [CTTelephonyNetworkInfo updateRadioAccessTechnology:] is not one of them. However, as shown in, we can successfully use this private API without Apple's consent to update the mobile phone service status of the target device.

Example 4: Obtain private album data through the public API

A.Sample-loaded framework:

/System/Library/Frameworks/Photos. framework

B.Public apis:

[PHAsset fetchAssetsWithMediaType: options:]

Mobile phone users are concerned with privacy violations. Any behavior performed on a device that involves accessing and using user privacy data (including contacts, information, photos, audios, notebooks, call records, etc) it should be proven to be within the scope of the services provided by the application. However, as shown in, we can use the private API to access users' albums and collect the metadata of photos from the built-in Photo. framework. With more code, attackers can export photo data without your knowledge.

Example 5: Obtain the Clipboard data in real time

A.Framework example:/System/Library/Frameworks/UIKit. framework

B.API: [UIPasteboard strings], [UIPasteboard items], [UIPasteboard string]

The IOS clipboard is one of the mechanisms that allow data transmission between applications. Some security researchers have raised security concerns because the clipboard can be used to transmit private data, such as accounts and certificates. A simple JavaScript demo function is displayed. When running on the JSPatch framework, all the string content is obtained from the clipboard and displayed on the console.

We have shown five examples of using JSPatch as an attack path, and there will be more attack possibilities.

0x03 future attack methods

Most local functions of IOS depend on C functions (such as dlopen () and UIGetImageScreen ()). Since the C function cannot be called by reflection, JSPatch does not support direct objecing between Objective C and JavaScript. To use C functions in JavaScript, an application must support JSExtension. JSExtension packages C functions to related interfaces and exports them to JavaScript.

Relying on the additional Objective C code to use the C function to restrict malicious attackers (for example, intercepting background screens, intercepting text messages without being discovered, and stealing photo privacy data, or background recording ). However, these constraints can be easily bypassed. In fact, the author of JSPatch can provide more available and convenient interfaces for application developers in the future to ensure there are enough commands. In this case, all the above operations won't be felt by Apple.

0x04 security impact

As we all know, IOS devices are safer than mobile phones running other operating systems. However, we must realize that there are many factors to maintain this situation. The core of Apple's security control is to provide and maintain a secure ecological environment for IOS users and developers. It is an "walled garden"-app store. Apps distributed through app store will be more difficult to exploit in a meaningful attack process. Today, two major attack channels constitute all previously disclosed attacks against the IOS platform:

Because the signature check function is disabled, the jailbreak IOS device allows unsigned or incorrectly signed applications to be installed. In some cases, Sandbox constraints are removed, which allows applications to run outside the sandbox. On a non-jailbreaking device, applications can use the enterprise certificate for side loading. FireEye released a series of detailed attack reports on the use of this attack, and recent reports continue to focus on this known attack path.

As we have emphasized in this report, JSPatch provides an attack path that does not require side loading or a jailbreaking device as an essential element of the attack. It is hard to conclude that the JavaScript content in JSPatch may be the Achilles' heel of the application development framework. Because there are almost no security measures to ensure the security of this file, the following attacks may occur:

● Prerequisites: 1) the application is embedded with the JSPatch platform; 2) the application developer has malicious attempts.

○ Impact: application developers can use all the private APIs provided by the loaded framework to perform behaviors that are not known to Apple or users. Because developers have control over JavaScript code, malicious behaviors may be temporary, dynamic, confidential, and evasive. Once such an attack occurs, it brings huge risks to all stakeholders.

○ Describes an attack scenario of this type:

● Prerequisites: 1) The third-party ad SDK is embedded on the JSPatch platform; 2) the Host application uses the ad SDK; 3) the ad SDK has malicious attempts on the host application.

○ Impact: 1) the advertisement SDK may leak data from the application sandbox; 2) the advertisement SDK may change the behavior of the Host application; 3) the advertisement SDK can perform various operations on the operating system in the name of the Host application.

○ Describes an attack scenario of this type:

FireEye's discovery of iBackdoor in 2015 is an example of a trusted replacement attack in the IOS development community and can be used as a good example of this neglected threat.

● Prerequisites: 1) the application is embedded on the JSPatch platform; 2) the application developer is legal; 3) the application does not secure JavaScript content communication from the client to the server; 4) A malicious attacker attacks man-in-the-middle to tamper with JavaScript content.

○ Impact: Man-in-the-middle attacks can leak the Content of applications in the sandbox. Man-in-the-middle attacks can use host applications as proxies through private APIs to implement various malicious behaviors.

○ Describes an attack scenario of this type:

0x05

JSPatch originated in China. Since its release in 2015, it has been successful in China. According to JSPatch, many popular Chinese applications have adopted this technology. The FireEye application scan found 1220 JSPatch applications in the app store.

We also found that developers outside of China have adopted this framework. On the one hand, this also shows that JSPatch is a very useful and satisfactory technology in the IOS development environment. On the other hand, this also marks that these users have a great threat that may be attacked-especially if no preventive measures are taken to ensure the security of all parties involved. Despite some security risks exposed by JSPatch, FireEye did not find any of the above applications malicious.