14 DAY TRIAL // FireEye's mobile threat research team has uncovered a problem with the way iOS developers are patching their applications using a third-party library called JSPatch.
In normal circumstances, whenever a bug in his app would be 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.
While this approach has kept the App Store safe and sound over the years, it has annoyed many iOS developers, mainly because it can take days or even more than a week for a crucial bugfix to reach users.
Either it's a security bug or one that crashes apps and makes then unusable, developers face the risk of losing their business thanks to Apple's complicated update procedures.
Enter JSPatch to save the day!
To address this very same issue, an unknown developer has 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 long-winded update routine, they can just add some JavaScript code to the file hosted on their server, which gets loaded in all the devices where the app is installed, and fixes the issue.
JSPatch, a force of evil, a force of good
Here's where things can go bad. What if the app's developer loads this library via an unencrypted channel, and an attacker using a simple MitM technique can intercept this library and alter its content to perform a malicious action?
It's not such a far-fetched scenario. In their tests, 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 which the app wasn't initially approved for.
Since all the JavaScript code is translated into Objective-C by the JSPatch engine, any type of iOS exploit can be carried out. And the best thing (for attackers) is that the JSPatch attack vector works even if the device wasn't jailbroken.
JSPatch opens new attack vectors
JSPatch also makes it possible for malicious actors to carry out attacks 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 is used in tens or hundreds of other apps.
Something similar to this scenario happened in October 2015, when Apple removed 256 iOS apps that contained a malicious SDK that was collecting user details unknown to the original app's developer.
As for JSPatch's legality, Apple's review process says that apps that download third-party code will be automatically rejected.
The only exception to this rule is for JavaScript code downloaded through Apple's WebKit or JavascriptCore engines, which JSPatch uses. But Apple also said it would ban any app for usage of malicious JavaScript code. To detect "anything" malicious, you have to manually review "everything." So, in the end, it will be up to the company to decide if it wants to revamp its app update process to make it speedier, or to allow a potential attack vector to creep inside most of its apps.
