in 2014, Masque Attack allowed hackers to replace a genuine app from the App Store with a malformed, enterprise-signed app that had the same Bundle Identifier (Bundle ID). Apple subsequently patched
the vulnerabilities (CVE-2015-3772
), but while it closed a door, scammers seemed to have opened a window. Haima’s repackaged, adware-laden apps
and its native helper application
prove that App Store scammers are still at it.
This is in light of the significant amount of malicious and potentially unwanted iOS apps we found signed with enterprise certificates and had the same Bundle IDs as their official versions on the App Store. Delving into them, we found that Haima and other third-party app stores were pulling off their scams by abusing a feature in iOS’s code signing process to achieve data inheritance. We worked with Apple and had these issues addressed on iOS 10, which now prevents legitimate apps from overriding their fake versions. However, devices running on iOS 9.3.5 or earlier can still be affected, so users are recommended to update to iOS’s latest version.
More than just creating fake versions, the vulnerabilities pose serious risks in that bad guys can target legitimate apps to distribute their malware. Scammers only need to create malicious content bearing the same Bundle ID as the genuine app’s, then ride on its popularity to entice users into installing their malware. Homegrown apps used by enterprises can also be spoofed, re-signed and repackaged via the same Bundle ID.
They can also modify the data values to forge URLs and route the legitimate app to a malicious service to phish for personally identifiable information, or even directly steal the user’s online bank accounts. They can also modify an app’s function, such as replacing URLs opened by the app to download malware (which is run after users ‘trust’ the certificate). The legitimate app’s advertisement ID can also be modified so the revenue generated from its monetized ads is sent to the scammers instead.
Figure 1. Fake social media app (below) showing the same Bundle ID used by the official/genuine version (above)
Figure 2. Snapshot showing developers can no longer apply an existing Bundle ID, as per how the previous Masque Attacks were addressed by Apple
Abusing the Code Signing Process to Get Similar Bundle IDs
Repackaged versions of Pokemon Go
, Facebook, and several other gaming apps are just some of the apps we found bearing the same Bundle IDs as their legitimate counterparts on the App Store. Although Apple has deployed an additional logic in XCode (Figure 2) to mitigate this, the Codesign tool in the command line can still be used to directly sign apps instead of XCode.
Scammers need only prepare a relatively modest toolkit to re-sign the app, including:
- An enterprise certificate (used to distribute the app without Apple’s vetting process)
- A distribution certificate, to get the app deployed on iOS devices; or development certificate, to test the app’s functionality (normally done by researchers and app developers)
- A provisioning profile, generated on Apple’s Developer site
- Entitlements.plist file, exported from the apps
- A clutch tool to decrypt the genuine app’s Mach-O file, a format of native executables, libraries, and object codes used for the iOS system that Apple encrypts by default
The process entails:
- Downloading the provisioning profile and plist file
- Replacing the Mach-O file within the legitimate app with a version decrypted by the clutch tool
- Re-signing the Mach-O file with the certificates
- Repackaging the app via command line
Figure 3. Decrypting a legitimate app with a Mach-O clutch tool
Figure 4. Sample Entitlements.plist file (above) and provisioning profile (below) used to re-sign and repackage an app
The process—especially the use of provisioning profile and Entitlements.plist
file—can be employed to re-sign other legitimate apps on the App Store. Although iOS 10 has pulled the plug on App Store/legitimate apps updating and overriding their copycats, they can still be re-signed, installed, and run on iOS devices as long as they tote the same Bundle IDs.
The whole signing process has not violated any checks. Likewise, Apple’s trusted source for code signature and entitlement verification is the application identifier, which is linked to Team ID. Scammers need only confirm if the provision profile and entitlements.plist
files were obtained from the same app. Since the re-signed apps have a valid certificate, they can be run on the iOS system.
A Flawed Data Inheritance
iOS enforces a rule preventing enterprise-signed apps from replacing their legitimate versions with similar Bundle IDs. However, we found it doesn’t work if implemented vice versa. Upon installation of an enterprise-signed app, the App Store—if set to automatically update—will notify the user that an update is available. If an app with an identical Bundle ID and newer version exists in the App Store, it overrides and inherits all history/data from the enterprise-signed app.
We reproduced this issue on a gaming app running iOS 9.3.5 and earlier. The genuine app that overrode the fake, enterprise-signed app was able to bypass the in-app purchase process by inheriting the latter’s data, including unlimited in-game currency.
Figure 5. Snapshots showing how the enterprise-signed app (from left to right) is installed, run, updated and overrode by the legitimate version, which also inherited unlimited in-game currency
Other capabilities can also be inherited, such as circumventing iOS’s privacy protection mechanism. How does Bundle ID figure into the equation? A newly installed app typically goes through a series of permission requests when accessing device resources, such as contact information. If it is uninstalled and another app with an identical Bundle ID is installed, the latter inherits the permissions vector granted to the previous app. It may be that granted permissions are generated and stored together with Bundle IDs as key-value pairs when apps are run for the first time but are not deleted if the app is uninstalled.
We were able to replicate this issue with a social media app. The legitimate version prods users with notifications when requesting access to the device’s location and contact list. If deleted and its repackaged version is installed, the latter inherits the granted permission vector, giving it free reign over the device’s user data; even the notifications were stripped off. If the repackaged app is installed first, however, users will be prompted with a series of dialogs requiring their input.
App developers who incorporate functions such as in-app purchases are advised to follow Apple’s official guidelines, particularly how to validate receipts with the App Store
, as well as employ mechanisms that can deter scammers from reverse-engineering the app. Businesses that employ/support iOS devices are recommended to balance mobility and productivity with privacy and security-conscious policies, especially when adopting BYOD
. Aside from keeping the OS up-to-date, the risks serve as a reminder for end users to beware of downloading apps from dubious third-party marketplaces.
Trend Micro detects these fake and potentially unwanted apps as IOS_Landmine.A. We have reported and demonstrated the vulnerabilities to Apple on July 21, 2016. They were assigned with CVE identifiers: CVE-2016-4659 for the app overriding issue, and CVE-2016-4606 for the Privacy Setting (permissions) flaw. Apple has patched these vulnerabilities on iOS 10.0. Some of the apps we found repackaged via these vulnerabilities can be found in this appendix