Researchers at FireEye recently posted a report about JSPatch, an open source platform which, when incorporated in an iOS app, enables dynamic code updates to the app. In simple terms, JSPatch is a backdoor that can allow a developer to make an expedited bug fix. Unfortunately, it can also allow threat actors to silently modify an app in a way that exposes an organization or enterprise to significant risks, including, but not limited to data leakage and privacy. Further, app updates pushed out through the back-door method are never inspected by Apple’s security team that reviews apps prior to allowing them in the App Store.
To be sure, the rationale for JSPatch is noble–faster delivery of app improvements. In fact, JSPatch uses functionality provided by iOS. That’s why the apps incorporating it had no issues getting through Apple’s App Store vetting process. But good intentions don’t always lead to good results.
The first iOS apps with JSPatch started appearing in the iTunes App Store mid-June 2015. We found a total of 3 apps for the month of June 2015; that number grew steadily month over month, peaking at 235 for the month of January 2016 as shown below. Overall, 962 apps infected with JSPatch were found on enterprise customer devices and the official iTunes App Store.
Figure 1: JSPatch infections in the Apple App Store – Jun 2015 – Jan 2016
Appthority has also evaluated the use of JSPatch on enterprise devices. We’ve found that 0.65%, or 1 out of every 153 enterprise mobile devices, had at least one app containing the JSPatch framework. As a result, virtually all Appthority customers have JSPatch in their environment.
What should be done?
Appthority consistently advises customers that the best approach to iOS app security is to detect and block jailbroken devices from their environment, and ensure all apps come from the official App Store, or from an enterprise app store if you have one. JSPatch effectively violates the prohibition against apps not from the App Store, since JSPatch can circumvent the App Store vetting process.
Thus, we recommend remediation against these apps, since their backdoors can allow malicious code to be added to the app unbeknownst to the user–or to the enterprise. The Appthority engine rules for detecting JSPatch is available now and we recommend taking immediate action. Appthority customers should create an app list with the “Uses JSPatch for hot patching” behavior or simply add that behavior to an existing app list that captures security vulnerabilities or high risk behaviors (Apps with JSPatch in the above example).
Figure 2: Leveraging App Lists to identify JSPatch infected apps