iOS developers: review your IAP handling code!
Yesterday morning, while testing iMazing 1.3’s new app backup/restore feature, we realised that quite a few popular apps contain severe weaknesses in their in-app purchase (IAP) handling code, resulting in vulnerabilities which can easily be exploited to manipulate IAPs.
For example, we tweaked Rovio’s Angry Birds 2 to easily allow starting the game with $10’000 worth of IAPs – see the 999’999’999 gems in the screenshot below.
These weaknesses could previously be exploited by editing and restoring an iOS backup containing the target app’s data, but a full restore can be time consuming, and iOS backups can hardly be shared among users. This is probably why these exploits aren’t public knowledge yet.
But our new app state backup/restore feature removes that friction: the app’s state can be exported as a .imazingapp file, which can be restored to any iOS 9 device in barely a minute.
We never intended to hack or facilitate hacking of IAPs. We developed iMazing’s app backup/restore primarily to enable:
- backing up selected apps quickly in order to make space on a device
- archiving safe copies of user documents stored in non-sharing enabled applications
- storing and sharing game saves
Which apps are vulnerable?
We’ve only investigated a small number of apps. Considering the high percentage of apps that we found to be vulnerable, we strongly recommend that all developers review their IAP handling code.
Apps that we’ve tested fall in three categories:
-
Transferrable purchases
Tetris Free (EA)
Angry Birds 2
A single user can purchase in game currency or unlocks, and transfer the application’s state to an unlimited number of other users. EA’s Tetris Free, for example, can be patched to remove adds at no cost ( normally a $5 IAP ). -
Tweakable in game currency
Angry Birds 2
Temple Run 2 ( not shareable )
This is the worst case scenario. In-game currency can be artificially pumped up to ridiculously high levels ( see our Angry Birds 2 screenshot ) by editing unencrypted files in a backup. This does not always result in shareable patches – it depends on how safely IAPs are implemented. - Not vulnerable
Clash of Clans
Candy Crush Saga
Not all apps are vulnerable. King’s controversial (ab)use of IAPs is well implemented for example.
Not Apple’s fault
The vulnerability is not in iOS, but in the affected applications’ IAP handling code. Purchased items should be stored in the keychain, or at least encrypted. The affected apps do neither, nor do they follow Apple’s recommendation to exclude purchased items from backups ( Apple IAP Guide )
Why do we release this information publicly?
Because we believe it’s only a matter of days before someone else figures it out, and because it’s the only way to alert all app developers of the issue.
Why not delay the release of iMazing’s app backup restore feature?
We have been promising our users this feature for months, and were planning to release in time for iOS 9. We are already a full week late, and under pressure to release a fully iOS 9 compatible version of iMazing.
We have taken steps to prevent direct manipulation of iMazing’s exported app files (.imazingapp extension), but we cannot prevent modification of the backup from which app data is extracted.
Other similar software provide backup browsers with limited editing capabilities: removing this feature from iMazing would in any case not prevent tampering with application data.