iOS App Patching Problem

Wednesday, February 3, 2016 @ 09:02 AM gHale

There is a problem in the way iOS developers patch their applications using a third-party library called JSPatch, researchers said.

Usually, whenever an application bug ends up discovered, a developer would put together a bugfix and submit it to Apple’s App Store for review, before being pushed to all the devices that have that app installed.

Revised App Tightens OS X Security
Apple Releases 28 Security Fixes
Malware Targeting iOS, OS X gets Stronger
DDoS Attacks Hit MySQL Servers

While this approach has kept the App Store secure, it has annoyed many iOS developers, mainly because it can take days or even more than a week for a bugfix to reach users.

What is at issue is the time delay makes developers face the risk of losing their business thanks to Apple’s complicated update procedures.

To address this very same issue, a developer created JSPatch. This library is a small JavaScript-to-ObjectiveC engine which developers can embed in their iOS apps.

Once the engine loads inside their app, they’ll also have to load a JavaScript file, but one hosted on a remote server, under their command.

Whenever developers need to push an urgent update for their iOS app, instead of going through Apple’s lengthy update routine, they can just add some JavaScript code to the file hosted on their server, which gets loaded in all the devices that have the app, and fixes the issue.

Quick, but Insecure
While that can be a quick and effective tool to issue an update, what is at issue is if a developer loads this library via an unencrypted channel, an attacker using a MitM technique can intercept this library and alter its content to perform a malicious action, said researchers at FireEye.

In testing the tool, FireEye researchers were able to use JSPatch to deliver malicious instructions to a test application, such as loading sensitive local iOS APIs and using them to reach into data stores of personal information.

Since all the JavaScript code translates into Objective-C by the JSPatch engine, any type of iOS exploit can end up carried out. And the best thing (for attackers) is the JSPatch attack vector works even if the device wasn’t jailbroken.

JSPatch also makes it possible for attackers to carry out assaults in different ways. The attacker can perform MitM attacks and alter the JS code sent out from the developer’s server, as mentioned above, or can he wait on a local network, scanning for updates and modifying them before reaching a user, in more targeted attacks.

The attacker can also be the developer of the app himself, or even worse, the owner of a third-party library that embedded the JSPatch engine, which in turn ends up used in other apps.

Quicker Fix
FireEye researchers concluded:

“Many applaud Apple’s App Store for helping to keep iOS malware at bay. While it is undeniably true that the App Store plays a critical role in winning this acclaim, it is at the cost of app developers’ time and resources.

“One of the manifestations of such a cost is the app hot patching process, where a simple bug fix has to go through an app review process that subjects the developers to an average waiting time of seven days before updated code is approved. Thus, it is not surprising to see developers seeking various solutions that attempt to bypass this wait period, but which lead to unintended security risks that may catch Apple off guard.

“JSPatch is one of several different offerings that provide a low-cost and streamlined patching process for iOS developers. All of these offerings expose a similar attack vector that allows patching scripts to alter the app behavior at runtime, without the constraints imposed by the App Store’s vetting process. Our demonstration of abusing JSPatch capabilities for malicious gain, as well as our presentation of different attack scenarios, highlights an urgent problem and an imperative need for a better solution – notably due to a growing number of app developers in China and beyond having adopted JSPatch.

“Many developers have doubts that the App Store would accept technologies leveraging scripts such as JavaScript. According to Apple’s App Store Review Guidelines, apps that download code in any way or form will be rejected. However, the JSPatch community argues it is in compliance with Apple’s iOS Developer Program Information, which makes an exception to scripts and code downloaded and run by Apple’s built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the application by providing features or functionality that are inconsistent with the intended and advertised purpose of the application as submitted to the App Store.

“The use of malicious JavaScript (which presumably changes the primary purpose of the application) is clearly prohibited by the App Store policy. JSPatch is walking a fine line, but it is not alone. In our coming reports, we intend to similarly examine more solutions in order to find a better solution that satisfies Apple and the developer community without jeopardizing the users security experience.”