Image: Martyn Williams/IDGNS
An increasing number of iOS application developers use a technique that allows them to remotely modify the code in their apps without going through Apple’s normal review process, potentially opening the door to abuse and security risks for users.
The technique is a variation of hot patching, which is a way of dynamically updating a system or application without restarting it. In this case, an iOS application is updated without the developer having to submit a new version to the official iOS app store and then wait for Apple’s review of the changes, which can be a lengthy process.
An implementation of this hot patching method comes from an open-source project called JSPatch, which provides an engine that app developers can integrate into their apps and which bridges JavaScript code to Objective-C, the programming language used by iOS apps.
For example, after adding the JSPatch engine to their application, which requires just 7 lines of code, developers can configure the app to always load JavaScript code from a remote server they control. This code is then interpreted by the JSPatch engine and converted into Objective-C.
“JSPatch is a boon to iOS developers,” security researchers from FireEye said in a blog post. “In the right hands, it can be used to quickly and effectively deploy patches and code updates. But in a non-utopian world like ours, we need to assume that bad actors will leverage this technology for unintended purposes.”
The problem is that hot patching is at odds with the iOS security model, which partially draws its strength from Apple’s walled garden, its carefully controlled app store.
There are some security-related restrictions that Apple imposes on third-party apps and which are solely enforced through the app store review process. JSPatch allows developers to bypass such policies.
For example by using this method, an app could access some iOS APIs without having declared them when it was first submitted and accepted into the app store. It can also access restricted APIs that only Apple applications are allowed to use.
An app could change system settings, enumerate account types on the device, collect the metadata of pictures in the photo album or access information stored in the pasteboard, the FireEye researchers said. There are currently some limitations to what attackers can do, but these limitations can easily disappear if the JSPatch developers choose to expose additional C functions or if app creators make some changes to the engine themselves, they said.
There are a few possible scenarios for JSPatch abuse. The most straightforward one would involve a developer who is intentionally malicious and leverages JSPatch to avoid his rogue code being detected by Apple.
Another one would be though an advertising network that implements JSPatch into its SDK (software development kit). If app developers would then include such an advertising SDK into their apps, it would give the advertising network the ability to abuse iOS APIs through their apps.
A third scenario would involve a JSPatch-enabled app downloading the remote JavaScript code over an unencrypted connection. This would allow an attacker who is in a position to intercept the app’s traffic—like on an open wireless network or through a hacked router—to modify the JavaScript code en route.
“The JSPatch technology potentially allows an individual to effectively circumvent the protection imposed by the App Store review process and perform arbitrary and powerful actions on the device without consent from the users,” the FireEye researchers concluded. “The dynamic nature of the code makes it extremely difficult to catch a malicious actor in action.”
