iOS App Development Patching Reveals A Security Hole
The way by which iOS developers patched their apps using a JSPatch (3rd party library), the research team of FireEye's mobile threat uncovered the problem with the same way.
Before pushing the bug affected devices into the Apple's App Store for review, a developer would put together a bugfix. And this approach keeps the App store safe and sound over the years but along with that it has annoyed many iOS developers, because it took lot of days or even more than a week for crucial a bugfix to reach users, it may be any either security related to one that crashes apps by making it unusable. Due to this, so many developers are there who can lose their business but thanks to Apple's complicated update procedure.
Some unknown developer has created JSPatch, which is a small JavaScript-to-Objective C engine which can be embed in the 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.
If any developers want an urgent update for their iOS app, then they can easily do it by adding some JavaScript code to the hosted file on the server and fix the issue without going through the Apple's long-winded update routine.
Here's where things can go bad. What happen 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 to approved.
 |
| Threat model for JSPatch used by a third-party library provide |
JSPatch engine transferred all the JavaScript code into Objective-C so that any iOS exploit can carry out. The most and the best part is that JSPatch attack vector works even if the device wasn't jailbroken.
By using JSPatch, malicious actors can carry out a different way of attacks. Developer's server send out a JS code which can easily alter the attacker, and they can also perform MitM attacks, or in more targeted attacks attacker wait for either on the local network or scanning to updates and modifying them before they reach to the user.
An attacker may be anyone might be the developer of app himself or other, the owner of a third-party library that embedded the JSPatch engine, which in turn is used to tens or hundreds of other apps.
In October 2015 also, something happened which is similar to that scenario, that time malicious SDK was in the Apple's 256 iOS apps that collect user details.
As for JSPatch's legality, Apple's review process says that apps that download third-party code will be automatically rejected.
Only JSPatch users can download JavaScript code through Apple's WebKit or JavascriptCore engines. But Apple also banned that app that uses malicious JavaScript code. To detect "anything" malicious, you have to review manually "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.
 |
| Threat model for JSPatch used by an app targeted by MitM |
ليست هناك تعليقات:
إرسال تعليق